Knowledge 最容易被误解成“像网盘目录一样继承权限，再加个全文搜索”。但源码真正呈现的是一套更精细的组合：正文索引负责可搜，权限树负责可见，desync 负责局部例外。
主要参考：
enterprise/knowledge/models/knowledge_article.py
一、搜索不是额外功能，而是正文模型的一部分
knowledge.article 在模型层直接为正文建立索引相关逻辑，甚至会显式创建加速 @@ 匹配的数据库索引。官方显然没有把搜索当“后置插件”，而是把它当作文章模型的基础能力。
这意味着 Knowledge 里的“搜得到”与“文章内容如何存储、如何被拆词、如何被更新”天然耦合在一起。
二、继承权限不是每层都重新算，而是沿祖先链寻找边界点
inherited_permission 的计算不是简单取父节点值。源码会沿祖先链向上找，直到根文章或某个显式 desync 的节点为止。那个节点才是当前文章的继承起点。
所以 Knowledge 的权限树更像“带断点的继承链”，而不是每一级都完全等价地往下传。
三、desync 不是 bug，而是产品特意提供的局部例外机制
很多人看到 is_desynchronized 会觉得这是同步失败后的补丁状态，实际上不是。它是官方明确支持的权限分叉点：
- 子文章想降级或提升局部权限
- 成员要与父级不同
- 文章迁移后不再完全继承原树
这些都会触发或依赖 desync。它的存在，正是为了让 Knowledge 的树状内容既能继承，又能允许少量“偏离父级”的业务现实。
四、成员权限与内部权限是两条并行轨道
internal_permission 解决的是面向“默认内部可见度”的公共规则，而 article_member_ids 解决的是具体 partner 级别的精确授权。两者组合后，系统再推导：
- 当前文章对所有内部用户是什么级别
- 特定成员是否应被提升/保留访问
- 在 desync 场景里哪些成员应从父级复制、哪些应被剔除
这也是为什么 Knowledge 看似只是知识库，但底层权限实现已经接近协作系统。
五、搜索结果能不能出现，本质上也受权限树影响
很多系统是“先搜到，再前端拦截打不开”。Knowledge 更倾向于在模型层就把权限条件压进去。正文索引再快，也要在“你有资格看到哪些文章”这个前提里工作。
因此索引与权限树并不是两个平行模块，而是搜索性能层与访问边界层的叠加。
六、实战建议
Knowledge 相关定制，最需要克制的就是手写一套“自己的权限继承”。官方已经把：
- 祖先链继承
- desync 断点
- 成员复制/剔除
- 全文索引下的可见集合
这几件事绑在一起了。你若只改其中一层，很容易出现“搜得到却打不开”或者“权限对了但成员树脏了”的问题。
Knowledge 之所以可靠，不在于它权限规则少，而在于它把文章树、成员树、索引树叠成了同一套可解释的边界系统。
DISCUSSION
评论区