根本原因是域名绑定未真正切换应用上下文：tp5的domain_bind仅影响路由分发，不改变app_path和session上下文，导致auth::setuser()写入的权限缓存与admin.php请求时校验的上下文不匹配。
ThinkPHP5 绑定域名后模块权限报错，根本原因不是权限配置写错了，而是域名绑定没真正落到应用层——domain_bind 在 TP5 单应用模式下只影响路由分发，不改变当前应用上下文，而权限校验（如 Auth::check()）依赖的是当前应用的路由规则名和 session 缓存里的角色权限映射。一旦域名指向了非默认入口（比如 admin.php），但框架仍以 index.php 的上下文运行，Auth::setUser($uid) 写入的缓存就对不上号。
domain_bind 配置在 admin.php 入口里不生效
TP5 的 domain_bind 是在 config/app.php 里写的，但它只在 index.php 入口被加载时解析；如果你用 admin.php 作为独立后台入口，这个配置根本不会被读取。
- 检查
admin.php文件开头是否手动引入了配置：必须有require __DIR__.'/../thinkphp/start.php';或等效的自动加载逻辑，否则整个框架初始化链就断了 - 确认
admin.php中没有重复调用App::run()，否则会触发两次启动，第二次直接跳过配置加载 - 不要在
admin.php里再写一遍Config::set(['app.domain_bind' => [...]])—— 这个值不参与路由匹配，只是个静态快照，改了也没用
Auth::check() 总是返回 false
权限节点校验失败，90% 是因为 Auth::setUser($uid) 没在正确的时机、正确的上下文中执行。域名切换后，如果登录逻辑还在 index.php 对应的控制器里，那写进 session 的权限缓存就绑定在默认应用名下，而 admin.php 请求进来时查的是另一个应用上下文。
- 登录成功后，必须在
admin.php对应的应用里调用Auth::setUser($uid)，不能复用index.php的登录接口 - 检查
session_name()是否一致：不同入口若用了不同 session 名（比如PHPSESSIDvsADMINSESSID），Auth根本拿不到之前设置的用户 ID -
Auth::check()默认查的是session('auth')['rules']，但如果你在admin.php环境中没触发过Auth::setUser()，这个 key 就不存在，结果必为false
Nginx 配置导致 admin.php 实际没走通
很多“绑定域名后权限失效”的问题，其实是请求压根没进到 admin.php，而是被 Nginx 转给了 index.php，然后框架按默认路由去匹配，自然找不到 admin 模块。
- 确认 Nginx 的
location ~ \.php$块里，fastcgi_param SCRIPT_FILENAME指向的是$document_root$fastcgi_script_name，而不是硬编码成$document_root/index.php - 在
server块里加一条日志：access_log /var/log/nginx/admin_access.log main;，访问域名后看日志里记录的SCRIPT_NAME到底是/admin.php还是/index.php - 如果用了
try_files，确保它没把/admin/xxx这类路径 fallback 到/index.php；正确写法是：try_files $uri $uri/ /admin.php?s=$uri&$args;
最易忽略的一点：TP5 的 Auth 类本身不感知多入口，它只认当前运行时的 APP_PATH 和 SESSION。域名绑定了，但入口文件没切换上下文，权限系统就始终在“假后台”里跑。别急着改 auth_rule 表，先确认 $_SESSION 里有没有 auth 字段，以及它的 uid 和 rules 是不是你期望的那个应用的。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
