KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
权限与多租户：从若依模型到注解式鉴权 — keel 龙骨
权限是后端系统里最容易写错、又最难被测出来的一层：错了不会报错，只会让某个人看到别人的数据。这门课从国内最常见的若依式模型（菜单 + 按钮 + 接口 + 数据范围）出发，一路讲到多租户的身份体系、RBAC 与 ACL 的分工、以及注解式声明鉴权的正确落地方式。全程使用一套可运行的配套项目，每个结论都有真实输出和可跑的越权用例。
权限是后端系统里最容易写错、又最难被测出来的一层：错了不会报错，只会让某个人看到别人的数据。这门课从国内最常见的若依式模型（菜单 + 按钮 + 接口 + 数据范围）出发，一路讲到多租户的身份体系、RBAC 与 ACL 的分工、以及注解式声明鉴权的正确落地方式。全程使用一套可运行的配套项目，每个结论都有真实输出和可跑的越权用例。
章节目录
- 00 · 全景地图：认证、授权、数据隔离是三件事 — 权限相关的需求经常被混成一句"加个权限校验"。这一章先把它们拆开：认证回答"你是谁"，授权回答"你能做什么"，数据隔离回答"你能看到哪些行"。三者各用不同的机制，任何一层缺失都会形成真实漏洞。
- 01 · 若依式权限从零手搓：五张表与三层授权 — 若依（RuoYi）及其同类框架把国内后台系统的权限模型固化成了几乎统一的形状。这一章不依赖框架，从零把它手搓一遍：表怎么设计、权限点怎么命名、三层授权各自查哪张表，以及"菜单可见 ≠ 接口可调"这个最经典的漏洞是怎么产生的。
- 02 · 数据权限：四种 scope 与「把权限塞进 SQL」的两种做法 — 前一章的接口权限回答"能不能调这个接口"，但它拦不住"能调列表接口的人看见全部行"。这一章讲数据权限：四种数据范围、两种落地做法，以及一个关键判断——数据权限不阻止任何人访问，它只给查询追加一个条件，所以它的失效永远是静默的。
- 03 · 落地形态：函数内判定、依赖注入与注解 — 同一套判定逻辑，写在三个地方，可靠性完全不同。这一章用配套项目的三份实现做对照：guards.py 里的函数内判定、api.py 里的依赖注入、guards.require_perm 装饰器。结论先给：依赖注入是 Web 入口的正解，装饰器是非 Web 入口的正解，函数内判定只适合兜底。而"中间件"这种形态在真实项目里常被证伪——本章给出一个实测过的反例。
- 04 · 多租户身份体系：user / member / tenant 三级 id 的分工 — 单租户系统里，"用户"就是一个人。多租户系统里不是：同一个人在不同租户里是不同的身份，角色、数据范围、可见资源全都不同。这一章讲清三级 id 各自的职责，以及"客户端传来的租户 id 为什么只能当上下文选择器"这条最容易被误解的规则。
- 05 · 隔离与泄密面：越权、403 与 404 的取舍 — 前四章把正常的链路搭起来了。这一章专门讲哪里会漏：五类越权尝试、状态码本身泄露的信息、以及那些"看起来隔离了其实没有"的写法。判断标准很简单——任何一条路径，如果它的作者忘了加租户条件，隔离就失效了，那它就是漏的。
- 06 · RBAC 的边界与 ACL：为什么「能改」不能是布尔值 — RBAC 很好用，直到你遇到这三个问题：角色开始爆炸、同一个岗位在不同空间要不同权限、有人需要"能看不能改"。这一章讲清 RBAC 在哪里到头，以及资源级 ACL 怎么补上——尤其是访问级别带权重这个设计，它决定了 ACL 能不能长期维护。
- 07 · 缓存与一致：权限改了多久生效 — 权限判定几乎必然要缓存（每次请求查三张表是不可接受的），但权限是低频写、高频读的数据，而且它的变更后果不对称：生效慢了是体验问题，失效早了是安全事故。这一章讲缓存什么、key 怎么设计、怎么失效，以及权限系统自身需要哪些可观测性。