📚 课程目录第1章权限系统概述

一、权限系统概述：什么是行级权限

聊权限系统之前，我先问个问题：你做过后台管理系统吗？

如果做过，你一定遇到过这种场景——同一个列表页，不同用户登录后看到的数据不一样。销售经理能看到全公司的客户，普通销售只能看到自己跟进的客户。这就是行级权限最典型的例子。

行级权限，也叫 Row-Level Security（RLS）。说白了，就是控制「用户能看到数据库里的哪些行」。

举个例子。一张订单表有 100 万行数据，普通用户只能看到其中 100 行——这 100 行就是「行级权限」过滤后的结果。系统在查询时自动追加一个 WHERE 条件，把不该看的行挡在外面。

核心定义：行级权限 = 在数据行粒度上，根据用户身份/角色/属性，动态过滤可见数据。

我刚开始做权限系统时，觉得这玩意儿很简单。不就是加个 WHERE user_id = 当前用户吗？后来发现，真实场景远比这复杂。嗯，这里要注意——行级权限不是简单的「用户只能看自己的数据」，它背后是一整套规则引擎。

你可能会问：没有行级权限会怎样？

我见过一个真实案例。某 SaaS 平台上线第一周，租户 A 的财务总监登录后，看到了租户 B 的工资单。原因很简单——开发人员只在代码里做了「菜单级权限控制」，但查询接口没加租户过滤。这就是典型的「权限漏洞」。

行级权限解决的核心问题有三个：

避坑提醒：我曾经接手过一个项目，权限只做了页面级控制。结果审计时发现，用户虽然看不到「全部订单」菜单，但只要知道 API 地址，直接 curl 就能拉走所有数据。行级权限是最后一道防线，不能省。

很多初学者容易把这两个概念搞混。我画个表格帮你理清楚：

实际项目中，两者经常配合使用。比如：销售经理能看到所有客户的行，但客户的「联系方式」列只有直属销售可见。这就是行级 + 列级的组合控制。

行级权限不是理论概念，它在实际系统中无处不在。我挑三个最常见的场景聊聊。

这是行级权限最经典的应用。一个数据库里存着所有租户的数据，每个租户只能看到自己的。

-- 没有行级权限的查询
SELECT * FROM orders;

-- 有行级权限的查询（自动追加）
SELECT * FROM orders WHERE tenant_id = '租户A';

我在做某电商 SaaS 时，遇到过一个问题：租户 ID 写死在代码里，结果有个接口忘了传租户参数，数据全乱了。后来我们统一在 ORM 层做了行级权限拦截，所有查询自动带上租户过滤。这才算彻底解决。

同一个公司内部，不同部门、不同层级的人，数据可见范围不一样。

这种场景下，行级权限的规则通常是「组织架构 + 角色」的组合。我建议用策略模式来实现，把权限规则抽象成一个个策略，灵活组合。

有些数据不是完全不可见，而是「部分可见」。比如：客服能看到用户姓名，但手机号中间四位用 **** 代替。这种其实也属于行级权限的变种——同一行数据，不同人看到的内容不同。

个人经验：行级权限最容易踩的坑是「性能」。我曾经在一个千万级数据量的表上，直接套了个复杂的权限子查询，结果接口响应时间从 50ms 飙到 5s。后来加了物化视图和缓存策略才救回来。记住：权限过滤条件一定要走索引。

说了这么多，我们来张图总结一下行级权限的整体架构。这张图我画了很多遍，每次给团队新人讲权限系统，都从这张图开始。

这张图展示了行级权限的完整链路。从用户请求开始，经过策略引擎解析，再到 SQL 层拦截过滤，最后返回用户可见的数据。每个环节都有对应的技术选型，后面章节我会逐一展开。

行级权限不是什么高深的技术，但它是一个系统从「能用」到「好用」的关键分水岭。没有行级权限的系统，就像一栋没有门锁的大楼——表面上看起来完整，实际上谁都能进。

我个人习惯把行级权限分为三个层次来理解：