拒绝粗放管理，细粒度权限控制系统实战指南
别再给实习生开上帝视角了
做系统开发的，谁没踩过权限的坑？我就见过不少刚上线的项目，为了省事，直接给个“管理员”角色，结果呢？新来的实习生手一滑，把生产环境的数据给删了，那叫一个惨。这事儿吧，说到底就是权限控制太糙，完全没做到细粒度管理。你想想，要是把公司账本随便摊在桌上，谁都能翻，这老板能睡得着觉？
啥是细粒度权限？别整虚的
很多人一听“细粒度”就觉得头大，其实没那么玄乎。你把系统想象成一栋大楼，粗粒度就是给你一把大门钥匙，你能进楼，但想去哪层、哪个房间没人管。细粒度呢？就是不仅管你进不进楼，还得管你能不能进财务部，甚至能不能打开财务部第三个抽屉里的保险柜。
说白了，就是要把控制权下放到每一个具体的操作和数据上。不是能不能看“订单列表”的问题，而是能不能看“张三负责的、金额大于一万的、且状态是已完成的”订单。
光有RBAC还不够，得加料
以前咱们做权限，大部分时候都在搞RBAC（基于角色的访问控制）。给张三贴个“销售”标签，他就能看订单。这挺好，但有个大坑：张三能看到全公司的订单吗？显然不行。要是让他看到了隔壁组的业绩数据，那不得打起来？
这时候你就得引入数据权限的概念。这就像给销售发了个望远镜，但只能看自己负责的那片区域，隔壁老王的地盘你瞅一眼都得报错。这就是咱们常说的“行级权限”。更狠一点，有些敏感字段，比如手机号、身份证，还得做“字段级权限”，普通人员只能看到 1380000，这才是真·细粒度。
怎么落地？这几招得记好
要想把这套逻辑跑通，设计模型的时候心里得有数，别等代码写了一半才发现推倒重来。
- 功能权限兜底：这层是基础，菜单能不能点、按钮能不能见，先拦一波。但这只是面子工程，防君子不防小人。
- 数据权限过滤：这是核心。SQL层面或者代码逻辑层面，必须加上类似 `WHERE dept_id = current_user.dept_id` 的条件，别把数据查出来再在页端藏，那是掩耳盗铃，抓包一看全露馅。
- 字段级管控：利用序列化拦截，在数据返回给前端前，把没权限的字段直接置空或脱敏。
实战里的那点“骚操作”
写代码的时候，别硬编码，真的，维护起来想哭。咱们可以用拦截器或者AOP的方式，把权限校验抽离出来，让业务代码清爽点。
```java // 伪代码示例，感受一下这种清爽感 @RequiresPermission("order:view") @DataScope(tableAlias = "o", deptField = "dept_id") public List你看，上面这段代码，既检查了有没有看订单的资格，又在查数据时自动带上了部门ID。这就叫系统级的安全感，而不是靠前端隐藏按钮来赌运气。很多开发者为了赶进度，只在JS里做个 `v-if` 判断，这简直就是给黑客留后门，千万别这么干。
最后说句掏心窝子的话
权限这事儿，平时看着不起眼，真出事儿就是大事。别等到数据泄露了才后悔没做细粒度控制。花点时间把这套逻辑理顺，哪怕开发阶段慢点，晚上睡觉都能踏实点。毕竟，谁也不想半夜被电话叫起来修数据库，对吧？做系统，安全永远是那个“1”，后面的功能都是“0”，没那个1，啥都不是。
相关文章
