子应用配置仅在被路由命中时加载，未触发则不生效；app/config.php为全局初始化加载，app/admin/config/app.php仅当admin应用启动时才加载并覆盖同名项。
多应用模式下，子应用自身的配置（如 app/admin/config/app.php）优先级高于全局应用配置（app/config.php），但前提是该子应用被实际路由命中并加载。
为什么改了 app/config.php 却对 admin 应用没生效？
因为 ThinkPHP 在多应用模式（app_multi => true）下不会预加载所有子应用的配置。只有当请求进入 admin 模块（比如 URL 路由匹配到 admin 应用）时，框架才会加载 app/admin/config/app.php。此时这个文件会覆盖 app/config.php 中同名配置项。
常见错误现象：
- 在
app/config.php里改了'app_debug' => true，但访问/admin时仍不显示调试信息 - 在
app/admin/config/app.php里写了'default_module' => 'dashboard'，但没生效——可能是因为没触发 admin 应用加载（比如入口还是走根应用）
app/config.php 和 app/{name}/config/app.php 的加载时机差异
关键不是“谁写得晚”，而是“谁被加载”。ThinkPHP 的配置链是按需拼接的：
-
app/config.php是根应用初始化时加载的，属于“全局应用配置”层 -
app/admin/config/app.php只有在admin应用被App::run()启动时才加载，属于“模块配置”层（5.1+ 中已提升为“应用级配置”，但仍受加载时机约束） - 两者不在同一加载阶段，不存在“同时合并”；后加载的自然覆盖先加载的同名项
如何确认当前请求到底加载了哪些配置？
在控制器中加一行调试代码：
dump(Config::get());
注意观察输出中是否包含你期望的键（如 app_debug、default_module），再对照你修改的文件路径判断是否真的被载入。特别留意：
- 环境配置（如
app/config/dev.php）只在APP_ENV=dev且APP_DEBUG=true时才参与加载 - runtime/config.php 是唯一能被
Config::set()持久化写入的位置，其他配置文件修改后需清空runtime/cache/或重启 Web 服务才可能生效 - 如果用了
Config::load()手动引入额外配置，它的优先级取决于调用时机——越晚调用，覆盖力越强
最容易被忽略的一点：多应用配置不是“自动继承 + 覆盖”，而是“隔离加载 + 按需覆盖”。你以为改的是全局开关，其实那个开关根本没进当前应用的配置空间里。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
