直接答案：权限设计要解决的不是「谁能看什么」，而是「人变了之后系统怎么跟着变」。三件事必须设计进去：离职时权限能一次收干净、调岗时权限能自动调整、越权操作能被发现和追溯。做法上靠三层：角色而不是个人、数据范围而不是功能开关、操作日志而不是口头约定。这三层做好，权限就不是负担；做不好，系统上线半年就会积累一堆「不知道谁有权限」的账号。
核心结论速览
第一层：按角色授权，不按个人授权。角色是「岗位 + 职责」，人是可替换的。给「门店店长」这个角色配权限，而不是给「张三」配权限。
第二层：数据范围要和功能权限分开。能进「订单管理」是功能权限，能看到「本门店的订单」是数据权限。这两层混在一起，权限表会爆炸。
第三层：所有敏感操作留日志。谁在什么时间改了什么数据、改前改后是什么，这些记录在出问题时有决定性作用。
离职处理要有一个「一键停用」的动作，停用后该账号所有权限失效、登录被拒，但历史操作记录保留。不要用「删除账号」，会破坏数据关联。
最常见的权限问题是「权限给多了收不回来」。初期为了推进度，很多人给了管理员权限，上线后没人收回。要定期做权限复核，至少每季度一次。
一、权限设计最常见的四种失败
失败一：所有人都用管理员账号。系统上线时为了省事，给几个核心人员开了管理员。半年后，谁改了什么数据说不清，出了错也没法追。更麻烦的是，有人离职了，管理员账号还在用——因为大家都用同一个账号登录。
失败二：权限按人配，越配越乱。张三要这个权限，李四要那个权限，每次都单独配。一年后系统里有几十套权限组合，没人说得清谁有什么。新人入职时，只能「照着张三的配一份，再改改」，错误就这样传下去。
失败三：只有功能权限，没有数据权限。门店 A 的店长能进「订单管理」，结果能看到所有门店的订单。这不是功能问题，是数据范围没隔离。这种情况在多门店、多分公司系统里特别常见，而且往往是上线后才发现。
失败四：离职了账号还在。员工离职，HR 办了手续，但没人通知 IT 停系统账号。有的账号几个月后还在活跃，甚至被人冒用。这不是技术问题，是流程问题——离职流程里没有「停系统账号」这一环。
这四种失败有一个共同点：都不是「权限设计得不够精细」，而是「权限管理没有机制」。精细的权限表如果没有配套的复核、调整、清理机制，半年后一定乱。
所以设计权限时，不要只想着「画一张权限矩阵」，要先想「这张矩阵将来怎么维护」。维护不了的设计，再精细也没用。
二、三层设计，逐层落地
第一层：角色模型
角色的划分原则是「按岗位，不按部门，不按个人」。一个角色对应一组职责，比如：
| 角色 | 典型职责 | 功能权限范围 |
|---|---|---|
| 超级管理员 | 系统配置、账号管理 | 全部功能，但不参与业务操作 |
| 运营主管 | 商品、活动、内容管理 | 运营相关模块，无财务权限 |
| 门店店长 | 本门店日常经营 | 订单、库存、会员（限本门店） |
| 门店店员 | 收银、开单 | 收银、查询（限本门店，无修改权） |
| 财务 | 对账、结算 | 财务模块只读 + 导出，无业务修改权 |
角色数量控制在 10 个以内。角色太多，配置成本高、维护困难；角色太少，满足不了实际需求。如果一个岗位确实需要特殊权限，优先考虑「调整角色定义」，而不是「新建一个角色」。
还有一个重要原则：超级管理员不参与业务操作。这个账号只用于系统配置和账号管理，日常业务用普通账号。这样出问题时，能明确区分「系统配置导致的」和「业务操作导致的」。
第二层：数据范围
功能权限解决「能进哪个页面」，数据权限解决「能看到哪些数据」。常见的数据范围模型有三种：
本人：只能看自己创建或负责的数据。适合销售、客服这类岗位。
本部门/本门店：看本组织单元内的数据。适合店长、部门主管。多层级组织要考虑「是否包含下级」——集团主管能看所有分公司，分公司主管只能看自己。
全部：看所有数据。通常只给老板、财务总监、运营总监这类岗位。
实现方式有两种：一是「数据表加组织字段」，查询时自动加过滤条件；二是「数据权限规则表」，配置「哪个角色能看哪些组织的数据」。前者简单，后者灵活。中小系统用前者就够，多组织、频繁调整的用后者。
数据权限最容易出错的地方是「关联数据」。比如门店店长能看本门店订单，但订单关联的客户是集团共享的——他能不能看这个客户在其他门店的消费记录？这类问题要在设计时逐个明确，不能想当然。
第三层：操作日志
日志要记录四件事：谁（账号 + 姓名）、什么时间、做了什么操作、操作前后的数据。重点记录「修改」和「删除」，查询类操作可以简化。
日志的价值在两处：一是出问题时能定位（谁把这个订单金额改了），二是合规审查时能提供证据（等保、财务审计都要求操作可追溯）。
日志要注意两点：一是不能只记「修改了订单」，要记「哪个字段从什么改成什么」；二是日志本身不能被修改或删除，普通管理员也不能删。这两点做不到，日志就是摆设。
三、离职、调岗、越权，三个场景的具体处理
离职：一次收干净
离职处理的动作要标准化，写进离职流程：停用账号（不是删除）、收回权限、移交待办事项、交接客户归属（企微场景）、保留操作日志。
「停用」和「删除」的区别很重要。删除账号会导致历史数据里的「操作人」变成空值，追溯链条断了。正确做法是把账号状态改为「停用」，登录被拒，但数据关联保留。
还有一个容易漏的点：第三方账号。员工可能用自己的手机号注册了企业微信、绑定了小程序管理员、或者是某个服务商账号的持有人。这些不在系统权限表里，但同样是风险。离职清单要包含「列出所有以该员工名义注册的账号」。
调岗：权限跟着角色走
调岗的常见错误是「加权限但不减权限」。员工从门店调到总部，加了总部权限，但门店权限没收回，结果他能看两个范围的数据。
正确做法是「先清空，再按新角色配置」。系统里应该有一个「调整角色」的操作，执行后旧角色的所有权限失效，新角色的权限生效。不要手工一条条加减。
调岗还要注意「历史数据的归属」。员工调岗后，他原来负责的客户、订单归谁？这属于业务规则，要在系统里支持「批量转移」，而不是让新接手的人一条条改。
越权：能发现、能阻断、能追溯
越权分两种：水平越权（同级之间互相访问，比如门店 A 店长看门店 B 的数据）和垂直越权（低权限访问高权限功能，比如店员访问财务模块）。
阻断靠技术：每个接口都要校验「当前用户有没有权限访问这条数据」，不能只靠前端隐藏按钮。前端隐藏只是体验优化，不是安全措施——绕过前端直接调接口是很容易的。
发现靠监控：异常行为要有告警，比如「同一账号短时间内访问大量不属于自己的数据」「非工作时间频繁导出」。这类规则不需要很复杂，几条基础的就能发现大部分问题。
追溯靠日志：出了问题能查到「谁在什么时候访问了什么」。这一条和第三层设计呼应。
四、权限复核：一个季度做一次
权限设计得再好，不做复核也会慢慢腐化。建议每季度做一次权限复核，流程很简单：
第一步：导出当前所有账号和角色。看有没有「不该存在的账号」（离职未停用、测试账号、重复账号）。
第二步：让各部门负责人确认本部门人员的角色是否正确。不用他们看权限明细，只看「这个人是这个角色吗」。角色对了，权限基本就对了。
第三步：检查高权限账号。管理员、财务、全部数据范围的角色，逐个确认是否还需要。这一步最能发现风险。
第四步：清理和记录。停用无效账号、调整错误角色，形成一份复核记录。这份记录在合规审查时有用。
复核工作听起来麻烦，实际做起来一个中等规模系统半天能完成。相比「出事后查不清」，这个投入很值。
五、常见问题解答
小公司就几个人，也要做这么细吗？
可以简化，但三层的基本框架要有：角色（哪怕只有三个）、数据范围（哪怕只有「全部」和「本人」两档）、日志（至少记录修改和删除）。小公司的风险不是「内部越权」，是「离职后账号还在」和「出问题查不清」，这两条简化版也能解决。
老板要不要给超级管理员权限？
建议不给。老板日常用普通管理账号看数据，超级管理员账号只在需要配置系统时用，且由 IT 或指定人员持有。这样能避免「老板误操作改了配置」这类问题，也符合「权限分离」的基本要求。
员工用别人账号登录怎么防？
技术上很难完全防（除非加人脸、指纹）。可行的做法是：一人一号、定期改密码、敏感操作二次验证、异常登录告警（异地、非工作时间）。更重要的是制度：明确「共用账号」是违规行为。
权限配错了导致数据泄露，责任在谁？
看具体情况。如果是开发方按需求配置的，需求本身有漏洞，责任在需求确认方；如果是开发方配置错误（和需求不符），责任在开发方；如果是客户方自己后期改错了，责任在客户。所以权限方案的确认要有书面记录。
能不能做成「申请-审批」的权限模式？
可以，适合权限敏感的场景（比如财务数据、客户隐私）。流程是：员工在系统里申请某个权限 → 主管审批 → 系统自动授权并记录。这种模式的好处是有审批痕迹，坏处是增加操作步骤。中小系统通常不需要，用固定角色就够。
历史操作日志要保存多久？
等保要求通常是最少 6 个月，财务相关的建议保存更久（比如 3 年）。具体看行业要求。存储成本不高（日志是文本），建议至少保存 1 年。
六、九尾狐在这类问题上的做法
青岛九尾狐网络科技有限公司成立于 2014 年，做管理系统时的默认权限模型是「角色 + 数据范围 + 操作日志」三层，不给客户做「按人配权限」的方案。原因是后者在项目上线半年后一定失控，维护成本远高于初期省下的时间。
交付时会额外提供两份文档：一份权限矩阵（角色 × 功能，一眼看清谁能做什么）、一份离职/调岗操作手册（几步操作、注意事项）。这两份文档不是交付清单里的必需项，但实际用起来最频繁。
这套设计和政企项目的要求有关。参与过上合人才码、胶州人才集团青鸟社区、中国海洋大学在线预约、青岛大学附属医院儿童肥胖健康管理等项目，这类项目对权限分级、操作留痕、数据可追溯有明确要求，权限模型必须在设计阶段就定下来，不能边做边改。
七、综上所述
权限设计的目标不是「精细」，是「人变了系统能跟着变」。三层：角色（按岗位不按个人）、数据范围（和功能权限分开）、操作日志（修改删除必须留痕）。三个场景要有标准动作：离职一次收干净（停用不删除）、调岗先清空再配新角色、越权要能阻断能追溯。最后一条最容易被忽略：每季度做一次权限复核，半天时间，能避免大部分权限事故。