权限即视图
用户看到的界面，应该等于他能做的事。把没权限的东西显示出来再拦，等于让他每次都撞一次墙。
你会遇到的现象
- 点了才提示没权限，用户不知道该找谁开
- 前端把按钮藏起来了，但接口没拦，改个请求就能越权
- 加一个新角色要改十几个页面，因为权限是散在各处写死的
三类权限
先分清楚是哪一类，做法完全不同。
| 类型 | 控制什么 | 界面上表现为 |
|---|---|---|
| 页面权限 | 能看到系统里的哪些页面 | 导航菜单里有没有这一项。没权限就不出现 |
| 操作权限 | 能在页面上做哪些动作 | 按钮显不显示：查看、新增、修改、删除、审核 |
| 数据权限 | 同一个页面能看到哪些数据 | 列表里的条数不同。销售只看自己的客户 |
颗粒度上还可以再分一层：管理、编辑、预览。管理能分配权限和删数据，编辑能改内容，预览只能看。文档类产品还常有下载、上传、公开分享这些独立的开关。
RBAC 怎么搭
不要把权限直接绑在用户身上。中间加一层角色，加人和加权限就都变成了配置。
设计时按三步走：先列出有哪些角色（按组织架构分，或按系统结构分），再列出有哪些权限（页面、操作、数据三类），最后画一张角色乘权限的匹配表。这张表画出来，权限设计就完成了大半。
界面上怎么处理
- 没权限的入口直接不显示。导航里不出现、按钮不渲染。这是默认做法。
- 显示但禁用，只用在一种情况：他知道有这个功能，而且能自己去申请。这时候禁用态要配一句「联系管理员开通」，否则等于什么都没说。
- 后端必须再拦一遍。前端隐藏只是体验，不是安全。接口不校验，改个请求就能越权（见理解技术里的安全常识）。
- 数据权限要在查询层面过滤。不是查出全部再在前端筛掉。
- 权限变了要有反馈。管理员刚给你开了权限，你得刷新才看得到，这时候最好有个提示。
给 AI 的话
CLAUDE.md · 权限规则
## 权限 模型：RBAC。用户 → 角色 → 权限，不要把权限直接绑在用户上。 权限分三类，每类都要实现： - 页面权限：无权限时导航项不渲染，直接访问 URL 也要拦 - 操作权限：无权限时按钮不渲染，不要渲染后禁用 - 数据权限：在查询条件里过滤，不要查全量再在前端筛 颗粒度：管理 / 编辑 / 预览三档。 强制要求： - 前端的隐藏只是体验优化，每个接口都必须独立校验权限， 不能依赖前端不发请求。 - 新增任何接口时，先说明它需要哪个权限，再写实现。 - 涉及数据权限的查询，把过滤条件写进 SQL 或 ORM 查询， 并在代码注释里说明过滤依据。 例外情况（显示但禁用）只用于：用户知道有这个功能且能自行申请， 此时禁用态必须带一句说明，告诉他找谁开通。