把成员设成“只读”后，他仍然能编辑，先不要继续改权限名称。更稳的做法是把主体、文件、动作和授权来源固定下来，逐项撤掉来源，观察哪一个变化真正改变了结果。这样可以区分“最后一次设置覆盖了前面设置”和“还有另一条授权仍在生效”。
先把问题拆成四个固定变量
记录同一个测试成员、同一个文件、同一个动作和同一个入口。动作至少分开查看、编辑、下载和分享；入口也要固定为文件页、空间列表或直接链接。不同产品对角色、文件夹、空间和链接的权限命名并不相同，不能把别家的“只读”直接当成通用语义。
先建立一份基线：成员属于哪些组织或群组，文件位于哪个空间，是否继承上层设置，是否有直接分享链接，以及测试时使用的是哪个账号。权限问题的证据是“主体通过哪条来源获得了这个动作”，不是设置页面上最后一次出现的文字。
用六个状态做一次授权来源消融
假设有两条可能的授权来源：A 是空间或群组授权，B 是文件直接授权。保持成员、文件和入口不变，只改变一条来源，按下面顺序记录结果。
| 状态 | 保留的来源 | 要观察的结果 |
|---|---|---|
| 基线 | A+B | 查看、编辑、下载、分享分别是什么结果 |
| 只留 A | A | 撤掉 B 后，编辑能力是否仍在 |
| 只留 B | B | 撤掉 A 后，直接授权能否独立生效 |
| 两者都撤 | 无 | 所有动作是否回到预期的拒绝或申请状态 |
| 只改入口 | 固定来源，换文件页/列表/链接 | 是否是链接或入口自身带来不同结果 |
| 重登复测 | 使用同一最终配置 | 刷新、退出重登后结果是否一致 |
每次只改一个来源，保存变更时间、操作者、测试动作和页面结果。若“只留 A”仍可编辑，问题在 A 的实际授权或其继承链；若“只留 B”仍可编辑，问题在直接授权；若“两者都撤”仍可编辑，再去查链接、缓存、测试账号是否混用。不要把最后修改的那一项直接认定为最终规则。
把查看、编辑和下载分开验证
权限动作不是一条连续的开关。腾讯云企业网盘的公开说明将查看列表、预览、下载和修改分开描述；Microsoft 的权限文档也提醒，某些“不能下载”或“可审阅”设置不会覆盖既有编辑权限。这些规则只说明为什么要逐动作验收，不能推导石墨办公的具体优先级。
验收时分别执行：打开文件、修改一处无害文本、下载副本、创建分享链接。每项都记录允许、拒绝或要求申请；下载副本还要记录副本是否仍带有后续权限。禁止用“页面能打开”代替编辑、下载和分享的结论。
权限结果不一致时，优先查三类证据
- 继承链：文件是否继承空间或上层目录设置，是否曾被单独授权。独立权限可能中断继承，也可能继续叠加，需以产品实际页面和日志为准。
- 主体来源：测试账号是否同时属于多个部门、群组或协作空间。换一个账号重试会改变问题，不能作为同一组对照。
- 时间与入口：撤权后是否刷新并重新登录，使用的链接是否仍指向旧副本。把操作时间、入口 URL 和文件稳定 ID 一起保存，才能回放。
如果仍无法解释，保留“两者都撤”后的完整操作记录，向产品或交付团队询问该版本的权限叠加和缓存失效规则。不要通过新建账号、复制文件或反复点击设置来掩盖未知状态。
把方法带进文档平台验收
石墨办公套件私有部署公开说明了管理角色与具体文件、空间操作权限需要叠加判断，并提供操作审计能力；页面没有承诺一套适用于所有版本的优先级公式。项目验收可把上面的 A/B 矩阵改成实际的空间、部门、文件和链接来源，要求交付方对每个动作给出可回放的结果和日志。
准备测试成员、文件稳定 ID、四类动作和预期结果，再预约演示，让接入团队确认权限来源、撤权生效时间和审计记录字段。未知的优先级保持未知，直到目标版本完成实测。