rbac权限判断不生效主因是缓存未刷新、角色/权限未真正入库、accesscontrol配置错误及前端未同步控制；dbmanager需手动invalidatecache()，权限名须合法，用户id须为int，status须为1，rules中roles必须含'@'，视图须用can()包裹敏感操作。
RBAC 角色权限判断不生效，通常不是逻辑写错了，而是几个关键环节被忽略或配置错位。核心问题集中在缓存、数据状态、规则写法和执行时机这四点上。
缓存未刷新导致 can() 一直返回 false
AuthManager 默认启用缓存（DbManager 使用数据库缓存，PhpManager 写入 PHP 文件），但 assign()、addChild() 等操作只写入数据，不自动更新运行时权限图谱。
- DbManager 下必须手动调用
Yii::$app->authManager->invalidateCache()，否则新分配的权限对当前请求无效 - 开发期可临时关闭缓存：在
config/web.php中 authManager 配置里加'cache' => null - 若使用 Redis 或 APCu 缓存，确认
'cache' => 'cache'指向的是正确组件名，且该组件已启用
角色/权限未真正入库或状态异常
权限名非法、ID 类型错误、status 字段为 0，都会让 can() 静默失败——不报错，也不生效。
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
-
$role->name和$permission->name只允许字母、数字、下划线_、连字符-；含点号（post.update）、斜杠（post/index）、中文或空格均被跳过，无提示 - 用户 ID 必须是整数（
int），传字符串'1'会导致auth_assignment.user_id写入为 0 - DbManager 中角色默认
status = 0（禁用），需显式设为 1 才参与校验：$role->status = 1; $auth->add($role); - 调用
createPermission()后，必须接addPermission()（或$auth->add()）才入库；仅create不生效
AccessControl rules 配置常见失效原因
行为过滤器看似配了，却没拦住请求，多数是规则顺序、登录前提或动作 ID 写法不对。
-
roles数组中必须含'@'表示“已登录”，漏掉就永远不匹配；若自定义 User 组件且identityClass::findIdentity()返回null，@也会失效 -
actions里填的是动作 ID（小写、无action前缀），例如['index', 'delete']，不是['actionIndex', 'actionDelete'] - 多个 rules 按顺序匹配，“首个成功项”即终止；把
['allow' => false]放最前，后面所有规则都被跳过 - RESTful 接口 403 很可能不是 RBAC 导致，而是
AccessControl的verbs未放行 POST/PUT/DELETE，或 Web 服务器（Nginx/Apache）本身拦截了非 GET 方法
前端元素未同步控制，造成“纸糊权限”
只靠 AccessControl 拦控制器入口，但按钮、链接、Gridview 操作列仍渲染出来，用户可直接发请求绕过——这不是 bug，是设计疏漏。
- 视图中所有敏感操作都必须用
Yii::$app->user->can('post/delete')包裹显隐逻辑 - GridView 的
columns中需嵌套判断，例如：['class' => 'yii\grid\ActionColumn', 'template' => '{update}{delete}', 'buttons' => ['delete' => function ($url, $model) { return Yii::$app->user->can('post/delete') ? Html::a('删', $url) : ''; }]] - 高频页面建议批量预查：用
AuthManager::checkAccess()一次查多个权限，避免反复调用can()触发多次缓存/DB 查询
