细粒度权限控制的概念与意义

权限控制，听起来很基础对吧？但“分多细才算够”这件事，我见过太多团队踩坑了。今天咱们就聊聊这个——从粗粒度到细粒度的演进，以及为什么你现在就该重视它。

从粗粒度到细粒度的演进

先说粗粒度。早年做后台系统，最常见的做法是给角色配模块权限：运营角色能访问“订单管理”这个菜单，里面所有功能一把抓。要么全给，要么全不给。简单粗暴，但问题也不少。

举个例子。我记得在三年前的一个电商项目里，客服团队要求把“仅退款”和“退货退款”两个操作分开——前者客服自己就能批，后者需要主管审核。粗粒度模型下，客服角色只能看到订单详情页，要么能修改所有字段，要么什么都看不了。根本没法做到“能点确认退款，但不能点修改收货地址”。

后来我们引入了细粒度控制。把每个操作拆成独立的资源：order:apply_refund，order:approve_refund，order:edit_address。角色从绑定菜单变成绑定资源列表。这样客服可以拥有“发起退款”的权限，却没有“审批退款”的权限。

但这还不够。再往后，业务要求同一个操作在不同场景下行为不同。比如“查看订单”这个动作，运营经理要能看到全站订单，普通客服只能看到自己处理过的订单。这就从“资源级”演进到了“数据行级”。

嗯，这里要插一句：细粒度不是一蹴而就的。大部分系统都是从粗到细，逐步铺开。我自己的习惯是，先保证粗粒度不出大问题，再把最痛的点逐步细化。

为什么需要细粒度？

说白了，就三个字：安全 + 合规 + 业务灵活。

• 最小权限原则：用户只拥有完成工作所必需的最小权限。粗粒度容易造成过度授权——一个普通员工可能不小心看到财务数据，这风险可不小。
• 合规要求：GDPR、个人信息保护法等法规明确要求数据访问必须可控。拿不出细粒度的权限审计日志，合规检查几乎是过不去的。
• 业务复杂度：现代系统里，同一个API在不同角色眼里要返回不同字段。用户列表接口，HR看到薪酬字段，PM只能看到姓名和部门。没有细粒度，就得写N个接口，维护成本爆炸。

我曾经在做一个SaaS平台时吃过这个亏。初期偷懒只做了模块级权限，结果客户A要求他的管理员不能导出客户数据，客户B要求普通员工不能看到合同金额。被迫在业务代码里到处加if判断，最后改得面目全非。后来重构成资源+条件引擎，才彻底解耦。

粗粒度 vs 细粒度 对比

维度	粗粒度	细粒度
控制范围	模块/菜单	数据行、字段、API参数
授权粒度	全部或全无	条件驱动（角色、组织、时间等）
配置复杂度	低，菜单树勾选即可	高，需要策略引擎或表达式
安全风险	过度授权明显	可以精确到最小权限
审计能力	只能记录“谁进过哪个模块”	可以记录“谁访问了哪条数据”

细粒度权限的典型模型：ABAC（属性基访问控制）

你想想看，如果权限判断需要结合用户属性、资源属性、环境属性，那传统RBAC就扛不住了。ABAC是解决这个问题的常见方案。一个策略形如：

// 伪代码：允许用户查看自己所在部门的订单
{
  "effect": "Allow",
  "action": "order:read",
  "condition": {
    "department": "${user.department}",
    "relation": "EQ",
    "value": "${resource.department}"
  }
}

当然，ABAC也有性能开销。我的建议是：先评估一下你的真实需求。大部分场景下，RBAC + 行级数据过滤就能覆盖90%的情况。别一上来就上ABAC引擎，容易过度设计。

一个我踩过的坑

曾经有个项目，我们设计了一个非常漂亮的细粒度权限框架，支持字段级别的写保护。结果上线后客服部门反馈：“我们能改客户手机号，但每次都要去另一个系统改权限，太麻烦了！”原来我们忘了做权限自助申请和审批流程。细粒度是有了，运营效率却降了。所以记住：细粒度不等于好用，必须配套友好的授权管理界面和自动审批链路。