权限即视图

没权限的功能不该显示出来再报错。

没权限的功能不该显示出来再报错。用户看到的界面，应该等于他能做的事。把没权限的东西显示出来再拦，等于让他每次都撞一次墙。

你会遇到的现象：

• 点了才提示没权限，用户不知道该找谁开
• 前端把按钮藏起来了，但接口没拦，改个请求就能越权
• 加一个新角色要改十几个页面，因为权限是散在各处写死的

三类权限

先分清楚是哪一类，做法完全不同。

第三类最容易漏。页面和按钮都控制了，但接口返回了全部数据，前端只是没显示——这是很多越权问题的来源。

颗粒度上还可以再分一层：管理、编辑、预览。管理能分配权限和删数据，编辑能改内容，预览只能看。文档类产品还常有下载、上传、公开分享这些独立的开关。

RBAC 怎么搭

不要把权限直接绑在用户身上。中间加一层角色，加人和加权限就都变成了配置。角色是权限的集合，用户通过角色拿权限，部门、用户组也可以作为角色的来源；这套模型就是基于角色的访问控制（RBAC），大型系统里管理成百上千个用户时，它比逐个绑定权限省力得多。rbac-wiki

设计时按三步走：先列出有哪些角色（按组织架构分，或按系统结构分），再列出有哪些权限（页面、操作、数据三类），最后画一张角色乘权限的匹配表。这张表画出来，权限设计就完成了大半。

另一种模型是 ACL：给每个对象单独维护一份可访问名单。它更精确灵活，但每个对象都要维护一份，管理成本高得多，适合文件、文档这类需要逐个授权的场景。

界面上怎么处理

• **没权限的入口直接不显示。**导航里不出现、按钮不渲染。这是默认做法。
• **显示但禁用，只用在一种情况：他知道有这个功能，而且能自己去申请。**这时候禁用态要配一句「联系管理员开通」，否则等于什么都没说。
• **后端必须再拦一遍。**前端隐藏只是体验，不是安全。接口不校验，改个请求就能越权（见理解技术里的安全常识）。
• **数据权限要在查询层面过滤。**不是查出全部再在前端筛掉。
• **权限变了要有反馈。**管理员刚给你开了权限，你得刷新才看得到，这时候最好有个提示。

给 AI 的话

把权限规则写进项目文件，每个接口、每块渲染都有据可依。

## 权限

模型：RBAC。用户 → 角色 → 权限，不要把权限直接绑在用户上。

权限分三类，每类都要实现：
- 页面权限：无权限时导航项不渲染，直接访问 URL 也要拦
- 操作权限：无权限时按钮不渲染，不要渲染后禁用
- 数据权限：在查询条件里过滤，不要查全量再在前端筛

颗粒度：管理 / 编辑 / 预览三档。

强制要求：
- 前端的隐藏只是体验优化，每个接口都必须独立校验权限，
  不能依赖前端不发请求。
- 新增任何接口时，先说明它需要哪个权限，再写实现。
- 涉及数据权限的查询，把过滤条件写进 SQL 或 ORM 查询，
  并在代码注释里说明过滤依据。

例外情况（显示但禁用）只用于：用户知道有这个功能且能自行申请，
此时禁用态必须带一句说明，告诉他找谁开通。