ThinkPHP 的 config() 函数返回旧值，主要因配置缓存未清除、运行时被覆盖或配置文件加载顺序错误；需检查缓存状态、调用时机、.env 与多模块配置优先级，并用 dump(Config::get()) 验证实际加载内容。
ThinkPHP 的 config() 函数返回旧值，通常不是缓存没清就是配置没真正生效。重点先看是否启用了配置缓存、是否在运行时被覆盖、以及配置文件加载顺序是否正确。
检查是否启用了配置缓存
ThinkPHP 5.1+ 默认开启配置缓存（尤其在生产环境），修改 config/app.php 等文件后，如果不手动清除缓存，config() 仍会读取缓存文件而非源文件。
- 执行命令清除配置缓存：
php think clear --config（TP6）或php think cache:clear（部分版本） - 手动删除
runtime/config/目录下的所有文件（确保 runtime 可写） - 临时关闭配置缓存：在
app.php中设置'config_cache' => false（仅调试用）
确认 config() 调用时机和作用域
config() 是运行时函数，但它的行为受调用位置影响：
- 在应用初始化完成前（如入口文件、公共函数中）调用，可能读不到完整配置
- 若在中间件、控制器方法中多次调用
config('key', 'value')写入，后续config('key')会返回新值——这可能是“你以为改了文件，其实代码里又覆盖了” - 检查是否有类似
Config::set()或config(['app_debug' => true])在启动流程中硬编码覆盖
验证配置文件是否被正确加载
ThinkPHP 按固定顺序合并配置：基础配置 → 模块配置 → 环境配置（.env）→ 动态设置。容易忽略的是：
立即学习“PHP免费学习笔记（深入）”；
- .env 文件中的
APP_DEBUG=true会触发额外的环境配置加载（如config/app_dev.php），可能覆盖你改的app.php - 多模块项目中，模块级配置（
app/module/config/app.php）优先级高于应用级 - 使用
config_path()打印当前配置路径，确认实际加载的是哪个文件：echo config_path();
调试技巧：直接 dump 加载结果
别只信 config('xxx')，要看到底加载了什么：
- 在控制器中加一句：
dump(\think\Config::get());查看全部已加载配置 - 单独测试某项：
dump(config('app.app_name'));和dump(\think\Config::get('app.app_name'));对比是否一致 - 检查 key 是否拼错（如大小写、下划线 vs 驼峰）、是否在数组深层（如
database.default而非database）
