Documents 很容易被误会成“给个分享链接，别人就能看”。但从 documents.document 与 documents.access 的实现看，企业版实际上搭了一套相当细的权限矩阵。
主要参考：
enterprise/documents/models/documents_document.pyenterprise/documents/models/documents_access.py
一、token 只是入口，不是最终权限结论
每个文档都有 document_token，并进一步组合成 access_token 与 access_url。这让系统可以给文档构造稳定链接，但有 token 不等于一定可读、可写。
真正的权限判断还要叠加：
access_via_linkaccess_internalaccess_ids中的成员角色- 文件夹/父级可见性
- 当前用户是否内部用户
- shortcut 指向源文档时是否具备源权限
二、access_via_link、access_internal、access_ids 分工不同
很多二开把这三者当成同义字段，实际上它们负责的是三层不同语义：
access_via_link：拿到链接的人默认拥有什么级别的能力access_internal：所有内部用户的底线权限access_ids：对特定 partner 的明确授权，可带过期时间
因此 Documents 的设计不是“公共 or 私有”二分，而是把匿名链接、内部员工、明确成员三种主体分开建模。
三、成员权限不是永久名单，而是可过期、可邀请、可清理的对象
documents.access 里最有意思的不是 role，而是 expiration_date 与邀请相关 token。系统甚至支持基于 access 记录生成 member signup token，让尚未有用户的 partner 通过受控链路进入系统。
再配合 autovacuum 清理过期 access，Documents 的成员授权就不是静态 ACL，而更像一层可回收的业务协作权限。
四、shortcut 最大的价值，是不复制权限事实
Documents 里 shortcut 并不是新文件，而是指向源文档的引用。这点非常重要：如果 shortcut 自己复制一份完整权限，很快就会和源文档漂移。
源码里大量 related / compute 都明确体现了这一点，例如 shortcut 会跟着源文档拿文件大小、所有者、受限状态等衍生信息。换句话说，shortcut 的边界是“便捷入口”，不是“新的权限主体”。
五、最容易误解的点：分享链接和父文件夹访问不是完全等价
is_access_via_link_hidden 这个字段专门处理一个微妙场景：即使文档挂在某个文件夹下，也不一定想让“能看父文件夹的人”自动通过链接看到它。它决定了链接权限是否继续向拥有父级访问的人开放。
这说明 Documents 在设计上非常在意“层级访问”和“显式分享”之间的差异，而不是粗暴地把两者混成一个权限来源。
六、实战建议
如果你做文档分享、门户下载、签署前置资料、项目文件夹自动建档等功能，最稳妥的方式是：
- 让 token 负责定位，不让 token 直接替代权限判断
- 对外部协作者优先用
documents.access承载明确授权 - 对 shortcut 只做引用层扩展，不做权限复制
Documents 权限体系之所以显得复杂，是因为它解决的是现实协作里的灰度问题：谁通过什么入口进来、能看多少、能改多久、父级关系是否继承。这比“有无权限”四个字复杂得多。
DISCUSSION
评论区