ThinkPHP配置加载顺序为：惯例配置→应用配置→模块配置→扩展配置→动态配置；.env不参与配置加载，仅提供环境变量。
配置文件“写了但不生效”，90% 是加载顺序被覆盖或缓存没清，不是写错了。
ThinkPHP 配置加载顺序到底怎么算？
ThinkPHP 的配置不是“谁后写谁赢”，而是按固定优先级逐层合并覆盖：
-
惯例配置（thinkphp/convention.php）：最底层，框架默认值，禁止修改 -
应用配置（config/app.php及config/下其他 PHP 文件）：项目级主配置，日常修改都在这里 -
模块配置（app/模块名/config.php）：仅对该模块生效，比如app/pay/config.php不影响 user 模块 -
扩展配置（config/extra/*.php）：自动加载，如config/extra/upload.php，调用时用Config::get('upload.max_size') -
动态配置（Config::set()或\think\facade\Config::set()）：运行时写入，优先级最高，但只在当前请求生命周期有效
注意：.env 文件不在此链中——它只提供环境变量，需通过 Env::get() 显式读取，不会自动注入到 Config 系统里。
为什么 config/app.php 改了却没反应？
常见原因不是代码问题，而是运行时状态干扰：
立即学习“PHP免费学习笔记（深入）”；
- 关闭了
APP_DEBUG：配置缓存被启用，改完文件必须手动清缓存，否则读的是runtime/config/下的缓存文件 - 清缓存方式不对：只删
runtime/cache/没用，要删整个runtime/config/目录，或执行php think clear --config - 用了
Config::set()临时覆盖：后续代码又调用了Config::get()，拿到的是动态值而非文件值，容易误判“配置失效” - 多环境混淆：
config/app.php里写了'app_debug' => Env::get('APP_DEBUG', false)，但.env里没设APP_DEBUG，结果 fallback 成false，调试模式实际关着
为什么 .env 里的 APP_DEBUG=true 不起作用？
.env 不是配置文件，它是环境变量源头，生效依赖两个前提：
-
入口文件（如public/index.php）里必须有Dotenv::createUnsafeImmutable(__DIR__.'/../')->load();这行加载逻辑（TP6 默认已内置，但自定义入口可能删了） -
APP_DEBUG在配置系统中不直通：它只影响think\facade\App::debug()的返回值，而config/app.php中的'app_debug'项仍需显式读取，例如写成'app_debug' => Env::get('APP_DEBUG', false) - 权限或路径错误：
.env必须在项目根目录（与composer.json同级），且 Web 服务器用户要有读取权限；Windows 下若从 zip 解压，文件可能带“只读”属性，需手动取消 - 验证是否加载：运行
php think status，看输出里Debug一栏是否为true，不是就说明.env根本没被读到
多级配置冲突时怎么快速定位？
别靠猜，用框架自带工具直接看最终合并结果：
- 在控制器里加一行：
dump(\think\facade\Config::get());，输出全部已加载配置，搜你要查的键名（如database、default_lang） - 如果值和你预期不符，再查
runtime/log/下最新日志，搜索Config load，能看到每一步加载了哪些文件 - 特别注意
default_lang类配置：它常被Lang::detect()覆盖，即使config/app.php写了也无效，得重写Lang类或在中间件里提前设语言
真正麻烦的从来不是“怎么写配置”，而是“哪一层悄悄把它改掉了”。每次怀疑失效，先 dump，再查 log，最后清缓存——绕过这三步，99% 的排查都是白费时间。
