Facade在子应用中读不到服务，根本原因是子应用上下文未加载对应服务提供者或绑定名与getFacadeAccessor()返回值不一致；需检查子应用config/app.php是否配置了正确的providers、services及app_namespace，并确保路由正确导入和缓存已清除。
多应用模式下 Facade 读不到服务，不是 Facade 写错了，而是当前应用上下文没加载对应服务提供者，或绑定名与 getFacadeAccessor() 返回值不一致。
为什么 Facade 在子应用里调用报 “Target class does not exist”
ThinkPHP 多应用不会自动为每个子应用重复注册全局服务提供者。即使你在 config/app.php 的 'providers' 里加了 \think\facade\Db::class，它只影响默认应用；子应用（如 app/admin）若没显式启用对应 Facade，Db::table() 就会因容器里找不到 db 实例而失败。
- 检查子应用自己的
config/app.php（例如app/admin/config/app.php）是否也包含该 Facade 对应的服务提供者，比如\think\service\DbService::class - 确认子应用的
config/app.php中'app_namespace'值和实际目录结构严格匹配（如设为'app'，则app/admin/controller下控制器必须在app\admin\controller命名空间下） -
Db、Cache等核心 Facade 依赖think\service下的对应 Service 类，这些类必须被正确加载 —— 若子应用的config/app.php里漏掉了'services'配置项或路径错误，就会静默跳过注册
Facade 根类未设置或绑定名错位
Facade 是代理，真正干活的是容器里绑定的实例。报错 “A facade root has not been set” 或 “Target class [xxx] does not exist”，大概率是 getFacadeAccessor() 返回的字符串和容器绑定键名对不上。
- 打开你用的 Facade 类（如
think\facade\Db），看它的getFacadeAccessor()方法返回什么（通常是'db'） - 再查对应 Service 类（如
think\service\DbService）的register()方法，确认它是否执行了$this->app->bind('db', ...)—— 键名必须完全一致，大小写敏感 - 子应用若重写了 Service 类或用了自定义绑定（如
$this->app->bind('database', ...)），但 Facade 还是返回'db'，那就必然断裂
子应用路由未加载导致 Facade 初始化时机异常
多应用中 Facade 所依赖的服务（如数据库连接、缓存驱动）往往在路由调度前由中间件或服务提供者初始化。如果子应用的路由根本没加载，boot() 阶段就不会触发，服务也就不会绑定。
- 确认
app/admin/route/app.php已被显式导入：在根app/route/app.php中有Route::import('admin', 'admin');，且第二个参数与子目录名完全一致（admin≠Admin） - 删掉
runtime/route/和runtime/container/目录，再运行php think clear:all，避免旧缓存掩盖新绑定 - 临时在
app/admin/route/app.php开头加dump('admin route loaded');，访问/admin/xxx看是否输出 —— 不输出说明路由根本没进子应用上下文
最易忽略的一点：子应用的 config/app.php 必须完整继承父级配置逻辑，尤其是 'providers' 和 'services'，不能只抄一半。缺一个 \think\service\CacheService::class，Cache::get() 就会静默失效，而不是报错。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
