---
url: /v6.2/permission-faq.md
---
# 权限模型

权限相关问题最容易在“我以为会这样”与“系统实际按另一套规则工作”之间产生误解。这页专门回答几类高频问题：公开链接、数据权限模式、行权限建模，以及平台/租户之间的授权边界。

## 为什么“使用者”模式不能开公开链接？

因为公开链接的前提是“任何拿到链接的人都能直接看”，而**使用者模式**的前提是“按当前登录用户身份决定可见数据”。

一旦访问者无需登录，系统就无法知道“当前用户是谁”，也就无法按使用者身份去裁剪数据。因此：

* **应用作者 / 数据集作者** 这类结果固定的模式，可以支持公开链接
* **使用者** 这种依赖登录身份的模式，不支持公开链接

相关说明可参考：

* [公开链接](app-public-link.md)
* [权限控制](app-data-auth.md)

## 应该怎么选“应用作者 / 数据集作者 / 使用者”三种模式？

可以先按这个判断：

|模式|适合场景|不适合场景|
|-|-|-|
|应用作者|希望所有访问者看到完全一致的数据结果|访问结果必须跟当前登录人变化|
|数据集作者|最常见，也最稳妥；适合共享分析结果|需要严格按当前人权限动态裁剪|
|使用者|必须按当前登录用户权限返回数据|需要公开链接，或需要开启加速引擎|

如果多人协同分析，通常更推荐 **数据集作者**，因为结果更稳定，也更容易排查“为什么你我看到的不一样”。

## 为什么“使用者”模式下不能开启加速引擎？

因为加速引擎适合把结果固化下来复用，而**使用者模式**要求“不同登录人查到的结果可能不同”。

这两件事天然冲突：一旦结果需要按当前登录人动态变化，就不适合直接固化成统一的引擎结果。因此如果业务必须实时按用户裁剪数据，通常要在直连查询、连接权限、行权限建模等方向上设计，而不是指望加速引擎同时满足。

## 有独立权限表时，行权限应该怎么做？

这是客服和实施场景里非常高频的问题。常见做法有三类：

1. **建立 Fusion 数据集**：把事实表和权限表一起建模，再把权限规则配在 Fusion 上
2. **把权限表作为模型从表**：事实表关联权限表时，通常要注意关联方向与“始终关联”这类生效机制
3. **在建事实表时通过过滤条件引入权限表**：适合某些不希望直接建模型、或多对多关系容易数据膨胀的情况

如果权限关系本身比较复杂，建议优先从“权限表和事实表的关系是一对一、一对多还是多对多”开始判断，而不是先选实现姿势。

## 为什么平台方已经把数据包授权给租户，租户普通用户还是看不到？

默认设计是**严格权限控制**：

* 平台方先把资源授权给“租户”
* 租户管理员再决定是否把它继续授权给租户内普通用户

所以“平台租户能看到”和“租户内所有用户都能看到”不是一回事。

如果你需要更宽松的默认行为，可以评估是否启用 `PLATFORM_FOLDER_AUTH=read`。但这类配置会改变整个平台/租户之间的默认可见边界，应先明确它是否符合你的治理策略，再执行配置并重启。

进一步阅读：

* [租户管理](tenant.md)
* [权限管理](permissions.md)