提成或佣金数据如何做到仅特定账号可见？

结论：不要靠前端隐藏提成数据。应由服务端同时控制“能看谁、能看哪些字段、能做什么、能否导出”，并固定每次结算使用的规则版本和数据快照；任何越权请求都必须在接口层被拒绝。

佣金通常同时暴露个人收入、团队业绩、客户回款和公司激励规则，敏感程度高于普通销售报表。前端把金额列设为不可见，只改变了页面外观；浏览器网络请求、导出接口或被猜到的记录编号仍可能返回完整数据。滚水科技在销售、渠道和绩效系统中，会先画出人员与数据关系，再把限制落到统一鉴权层，而不是让每个页面临时写判断。

在约定交付物、接管方式与责任边界时，还可以对照 为什么不建议让主系统与提成小账长期双向联动？ 和 你们如何保证系统的安全性？包括数据安全、接口安全、服务器安全？；这些内容补充了需要放在同一项决策中考虑的上下文。

一张可验收的权限矩阵可以这样表达，实际项目还应按组织层级和岗位拆细：

账号类型	可见数据范围	可见字段	允许操作	默认导出权限
销售本人	仅本人且已发布的结算记录	计提基数、比例、本人金额、状态	查看、发起异议	无
团队负责人	授权团队及有效管理周期内记录	成员明细与团队汇总，不显示无关团队	查看、复核	按审批临时开通
财务结算岗	待结算批次及历史财务记录	税前税后、付款状态、调整项	锁定批次、付款登记、冲正	有，文件加水印并留痕
系统管理员	配置账号与权限，不因管理员身份自动获得收入明细	默认脱敏	授权、停用、审计配置	无

实现时可把角色权限与属性条件组合。角色回答“销售、经理、财务能做什么”，属性继续判断记录所属人、部门、区域、在职时间、结算状态和当前环境。NIST 的 ABAC 指南 SP 800-162 将主体、对象、操作和环境属性共同纳入授权判断，这比无限增加“华东二部经理”一类固定角色更容易维护。无论采用 RBAC 还是 ABAC，最终过滤必须发生在受信任的服务端；查询列表、查看详情、统计数字和下载文件要走同一口径。

行级权限决定能看哪些记录，字段级权限决定接口能返回哪些值。普通销售请求他人记录时应直接返回拒绝，而不是返回数据后由前端打码。手机号、银行卡、税务身份等字段应按业务必要性继续脱敏或不返回。导出、打印、批量查询属于独立高风险动作，应设置更短的授权期限、单次范围上限、审批原因和账号加时间水印。依据 个人信息保护法 的目的明确与最小必要要求，“负责人可能用得到”并不足以支持无限查看。

金额正确还依赖可追溯的计算。每次规则调整都生成新版本，注明生效时间、适用人员、公式和审批人；结算时保存订单数据切片、规则版本、计算结果与异常调整，结算完成后不再用最新规则覆盖历史。退款、改价或人工奖励应生成冲正或补差记录，而不是直接改掉原流水。这样才能回答“某员工上月为何是这个金额”，并让财务总账与佣金小账对上。

审计日志至少记录账号、时间、目标记录、操作类型、授权结果、导出条件和文件标识，并限制普通管理员修改。日志不是越多越好：查看行为可记录对象范围和查询条件，不应再次复制完整敏感数据。异常监控可以关注短时间大量翻页、跨团队连续拒绝、非工作时段批量导出和权限刚提升即下载等信号。

上线前不能只测“有权限的人能打开”。应为每类账号建立正向与反向用例，包括修改 URL 查询他人 ID、切换部门后访问旧数据、离职账号继续请求、撤销权限后复用旧令牌、导出接口绕过页面以及统计接口泄露汇总金额。可参考 OWASP ASVS 访问控制验证要求 设计测试，并用测试账号而非真实高管账号演练。

滚水科技通常把权限矩阵、规则版本、结算快照和越权测试报告列为同一批验收物。验收通过的标准不是“页面看不到”，而是未授权账号从所有入口都拿不到数据，授权变更及时生效，历史金额能够复算，导出能够追责。