按钮级权限需定义统一权限码（如article:delete）并缓存至redis，控制器中调用checkpermission校验，前端通过data-permission隐藏按钮但不可替代后端校验，权限变更时须清理对应缓存。
ThinkPHP 接口权限怎么按按钮/操作粒度控制
不能只靠 Auth 或 rbac 中间件做模块级拦截——按钮级权限必须落到具体接口（比如 admin/article/delete）和当前用户能执行的动作（如“删除”“导出”“审核”），且前端按钮显隐、后端接口校验要同步。
如何在控制器方法里快速判断当前用户是否有某按钮权限
ThinkPHP 本身不内置“按钮权限码”概念，得自己定义一套可映射到接口行为的权限标识，比如 article:delete、order:export，再与用户角色绑定的权限列表比对。
- 推荐在中间件或基类控制器里统一调用
checkPermission($permissionCode)方法，传入类似'article:delete'这样的字符串 - 权限数据建议缓存（如 Redis），避免每次请求都查库；缓存 key 可设为
'user_permissions_' . $userId - 注意：
$this->request->action()返回的是方法名（如delete），不是完整路由，不能直接当权限码用；应由路由定义反推权限码，或在路由分组/注释里显式声明 - 示例：在
ArticleController::delete()开头加if (!$this->checkPermission('article:delete')) { throw new HttpException(403); }
为什么用数据库字段存权限码比用配置文件更靠谱
按钮权限是动态业务属性，运营随时可能新增“批量下架”“复制链接”等按钮，硬编码到配置或常量里会导致每次上线都要改代码、发版、重启服务。
- 权限码字段（如
auth_rule.rule_code）应支持唯一索引 + 业务描述字段（title），方便后台管理界面展示 - 前端按钮需带
data-permission="order:export"，JS 初始化时批量校验并隐藏无权限按钮，但**不能省略后端校验**——仅前端控制等于没控制 - 兼容性提醒：TP6.0+ 的
think-auth扩展默认不处理这类细粒度码，得自己扩展AuthRule模型的查询逻辑
常见踩坑：权限缓存没更新导致按钮一直不可见
用户刚被分配新权限，前端刷新后按钮仍灰掉，后端接口也 403，大概率是权限缓存没失效。
- 给权限增删改操作（如后台分配角色权限）加上缓存清理：删掉
cache('user_permissions_' . $userId)和通用规则缓存cache('auth_rules_all') - 别用
Swoole或Workerman长连接场景下的本地内存缓存（如static $cache = []），进程间不共享，会导致部分请求权限判断错乱 - 调试时可在
checkPermission()里临时加日志，输出实际查到的权限数组，确认是不是缓存旧数据或数据库漏写
按钮级权限真正的复杂点不在校验逻辑，而在权限码的定义一致性——前后端、数据库、路由、文档必须用同一套命名规范，否则一个 user:edit 写成 user:update 就会卡住整个流程。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
