Yii RBAC细粒度控制取决于权限建模：采用业务语义化三段式命名（如data:patient:read:own）、利用父子继承构建组合权限、结合动态Rule实现运行时校验。
Yii 的 RBAC 权限控制本身不细，但可以做到极细——关键不在框架默认能力，而在你如何建模权限项（Permission）和组织角色继承关系。
Yii 自带的 yii\rbac\DbManager 只提供“角色→权限→用户”的骨架，它不预设任何业务语义。所谓“细粒度”，完全取决于你定义的 auth_item.name 是否能精确到操作+资源+上下文三级。
权限命名必须自己设计三段式结构
Yii 不强制你用什么格式命名权限，但若直接用 user/update 这种控制器/动作名，就注定粗放——它无法区分“更新自己资料”和“更新他人资料”，更无法控制“能否更新手机号”还是“仅能更新头像”。
✅ 推荐实践是采用业务语义化命名：
data:patient:read:own data:patient:read:department model:llama-3-8b:download:private training:fine-tune:lora:gpu-a100 deployment:staging:restart
这样每条权限都是一个独立原子单元，可单独赋给角色。Yii 完全支持这种长字符串作为 name，底层只是存进 auth_item 表的 name 字段，无长度或格式限制（MySQL 默认 64 字符，需手动改 VARCHAR(255)）。
⚠️ 常见坑：没改表结构就写超长权限名，导致截断或插入失败，且无报错提示。
父子权限继承让细粒度真正可维护
单纯堆权限项会爆炸式增长。Yii 的 auth_item_child 表支持权限嵌套，这才是细粒度落地的关键杠杆。
例如：
- 定义基础权限：
data:report:view:basic、data:report:view:advanced、data:report:export:pdf - 再创建组合权限：
data:report:full-access，并用$auth->addChild($full, $basic)等方式挂载子项
这样，“审计员”角色只需分配 data:report:full-access，后续新增 :export:excel 权限时，只要把它加进 full-access 的子集，所有已分配该角色的用户自动获得新能力。
❌ 错误做法：把所有权限平铺直给角色，后期每次增删都要遍历所有角色手动调整。
动态 Rule + beforeAction 是细粒度的临门一脚
Yii 的 Rule 类允许你在权限校验时注入运行时逻辑。比如：
-
data:patient:read:own对应的 Rule 检查$params['patient_id'] === Yii::$app->user->identity->id -
deployment:prod:approve要求当前用户属于“发布审批组”，且目标模型版本已通过 QA 流程
这类判断无法靠静态权限名表达，必须靠 Rule 实现。而校验入口通常放在 Controller::beforeAction() 或自定义 Behavior 中调用 Yii::$app->user->can('xxx', $params)。
⚠️ 注意：Rule 执行在每次请求中，避免在 execute() 里做重查询（如查数据库判断部门归属），应提前缓存或走关联字段。
细粒度不是 Yii 给你的功能，是你用它的扩展点（命名自由、父子继承、Rule 机制）一层层搭出来的控制力。一旦跳过权限建模这步，直接套用控制器方法名，RBAC 就退化成 ACL，再好的框架也救不了。
