猫拽智库
结论先行：字段级权限不是把输入框藏起来。四种做法对应四类风险：界面显隐只管观感，字段 ACL 才管读写，行级加列级解决数据范围，动态脱敏解决外泄。判断平台是否真做了字段权限，只看三件事：接口是否二次校验、导出是否走同一套规则、流程节点与字段权限冲突时谁优先。
一、四种实现方式，解决的不是同一个问题
很多平台把“字段权限”实现成表单设计器里的一个显隐开关，用户看不见就以为安全了。真实需求往往同时包含“他能看哪些行”“他能改哪些列”“他能不能导出去”，三个问题必须分开答。
| 实现方式 | 作用层 | 解决的问题 | 典型失效场景 |
|---|---|---|---|
| 视图与表单字段显隐 | 界面层 | 少干扰、按角色简化表单 | 直接调接口或改参数即可绕过 |
| 字段级 ACL | 服务端 | 读、写、导出分别授权 | 只做了读，写与导出漏配 |
| 行级范围加列级字段 | 数据层 | 先限行，再限列 | 行过滤写死，换了组织就串数据 |
| 动态脱敏与掩码 | 输出层 | 让他看到，但看不全 | 只在页面掩码，接口仍下发明文 |
视图显隐属于体验设计，不是安全边界。它的价值在于让不同角色看到不同表单，减少误操作；把它当权限手段，等于给保险柜贴了张“请勿打开”的纸条。
字段级 ACL（Access Control List）是把每个字段的读、写、导出拆成三个独立动作分别授权。这是唯一能在服务端闭环的做法。核对时要问：权限表是挂在字段上，还是挂在表单模板上？挂模板的做法，同一字段出现在第二张表单时就要重配一遍。
行级范围加列级字段是最贴近业务的做法：先用组织、归属、本人等范围把行筛掉，再在可见行里按角色开放列。顺序不能反，先列后行等于让用户先看到一批他本不该知道存在的数据。
动态脱敏解决的是“必须让他用，但不能让他看全”的场景，比如客服要核验手机号尾号、财务要核对卡号后四位。它的实现要点在后端输出，不在前端样式。角色与权限模型的基础可参考用户权限管理系统怎么设计？RBAC 模型详解。
二、界面隐藏不等于安全，接口必须二次校验
前端隐藏字段只改变渲染结果，接口返回的 JSON 里该有的值一个不少。会看浏览器开发者工具的人，三十秒就能拿到完整数据。
正确的链路是：请求进来先做身份认证，再按数据范围过滤行，最后按字段 ACL 裁剪返回体。三层都在服务端，前端只负责把拿到的结果显示出来。
几个容易被忽略的入口：
- 列表接口：只裁了详情页，列表却返回全字段，等于白做。
- 关联查询：主表隐藏了手机号，关联子表又带出来一份。
- 批量接口：批量更新时未校验被改字段是否在授权范围内，可越权改薪资。
- 排序与筛选参数：用不可见字段做排序条件，能从结果顺序反推出隐藏值。
- 变更日志与消息通知：日志里带出完整旧值与新值，绕过所有字段权限。
自托管平台在这一点上有天然优势：猫拽低代码（CatPull）采用可视化设计器加 DSL Schema 的路线，数据接口由平台服务端统一生成，字段裁剪与行过滤可以收在服务端一处，而不是散落在每个页面脚本里；导出工程后仍可按同一套规则改。
三、导出是字段权限最大的漏洞
页面做得再严，一个“导出 Excel”按钮就能把全部字段带走。导出必须满足三个条件才叫受控。
- 导出走同一套字段 ACL：导出不是独立功能，它读的应该是同一份权限配置，而不是另一份导出模板。
- 导出范围继承当前筛选：用户筛出的是一百行，导出就不能是一万行。
- 导出留痕并可追溯：谁、何时、导了哪些字段、多少行，都要落到审计日志，敏感字段导出建议加审批。
还有一类隐性导出：打印、截图、复制到剪贴板、分享链接、邮件模板。凡是能把数据搬出系统的动作，都要在权限设计时列进清单，否则前面所有工作会在一次“另存为”里归零。
四、流程节点权限与字段权限冲突时以谁为准
这是实施阶段最常见的争议：字段 ACL 说销售不能改合同金额，流程节点又说审批人可以修改金额。
判断规则建议按下面三条排序，写进配置说明，不要让开发临时拍板。
- 取交集，不取并集：节点权限只能在字段权限允许的范围内收窄，不能扩大。默认拒绝，显式放开。
- 节点可编辑字段单独登记：每个审批节点列出“本节点可改字段”，与字段 ACL 求交后生效，界面上灰掉不可改项。
- 越权修改必须留审计：确需临时放开（如财务复核改金额），走单独授权并记录修改人、原值、新值、理由。
反过来的坑同样存在：流程结束后回写业务表，如果回写逻辑绕过了字段权限，就会出现“审批人没权限，但系统替他改了”的情况。回写必须调用同一套服务端校验。
五、权限矩阵模板
下面这张表可以直接拿去当配置底稿，把“角色 × 字段 × 动作”三个维度摊开，冲突一眼可见。
| 字段 | 销售 | 主管 | 财务 | 管理员 |
|---|---|---|---|---|
| 客户名称 | 查看 / 编辑 | 查看 / 编辑 | 查看 | 查看 / 编辑 / 导出 |
| 合同金额 | 查看 | 查看 / 编辑 | 查看 / 导出 | 查看 / 编辑 / 导出 |
| 成本价 | 不可见 | 查看 | 查看 / 导出 | 查看 / 编辑 / 导出 |
| 客户手机号 | 查看（掩码） | 查看（掩码） | 查看（全量） | 查看 / 导出（脱敏） |
| 回款账户 | 不可见 | 不可见 | 查看 / 编辑 | 查看 / 编辑 |
填表时坚持两条：一是不写“全部”这类词，必须落到具体动作；二是每个“不可见”都要能被一条测试用例验证，而不是靠人回忆。
六、实施优先级
字段权限一次做完不现实，按风险从高到低排，三步走更稳。
- 第一步：行级范围。先把“能看到谁的数据”定清楚，按组织、归属人、项目成员三类维度配置，配错的影响面最大，也最容易验证。
- 第二步：敏感字段的写权限。金额、折扣、成本、账户、审批状态这类字段先锁写，防止越权篡改，读权限暂时放开可接受。
- 第三步：字段读权限与导出审批。在行范围稳定后再收窄列，同时把导出纳入审批与审计，避免上线初期大面积报“看不到数据”。
跨部门协作时，权限变更必须走申请与复核，不能由业务方直接改配置。最小权限与变更留痕这两条原则，可以直接套用。
FAQs
Q1：字段权限配在表单上还是配在数据模型上？
A：配在数据模型上。同一字段会出现在列表、详情、导出、接口多个出口，只有挂在模型层才能一次生效；配在表单上，新增一个页面就要重配一遍，漏配就是漏洞。
Q2：移动端和 PC 端要配两套字段权限吗？
A：不要。权限规则只应有一套，端差异交给布局与组件做适配。两端各配一套的结果是永远对不齐，审计时也无法解释为什么手机上能看到 PC 上看不到的字段。
Q3：历史数据里的敏感字段，权限收紧后还能查吗？
A：能查，但要按新规则查。权限收紧不影响存储，只影响出口；建议同时做一次存量排查，确认旧报表、旧导出模板、旧接口是否仍在返回全量字段，这三处最容易漏。
