config()返回旧值是因runtime/config.php未更新、opcache未刷新或app_debug被覆盖；需先var_dump(config('app.app_debug'))确认调试模式，再清缓存、重生成并刷新opcache。
配置缓存没清干净，config() 还返回旧值，不是你改错了，而是 runtime/config.php 没更新、OpCache 没刷新、或者 app_debug 配置被覆盖了。
确认是不是框架配置缓存在作怪
先别急着删文件。直接在控制器里加一行：
var_dump(config('app.app_debug'));
如果输出 true，说明当前是调试模式，框架根本不会读 runtime/config.php，而是每次 require 原始配置文件——这时 config 不生效，问题大概率出在 .env 覆盖、文件权限或 OpCache 上。
如果输出 false，再检查 runtime/config.php 是否存在且内容完整（大小通常 >30KB）。若为空或语法报错，框架会静默 fallback，但可能漏读部分配置。
命令行重建配置缓存（生产环境首选）
确保 config/app.php 中 'app_debug' => false，且 .env 里没有 APP_DEBUG=true 覆盖。然后执行：
php think config:cache
该命令会重新合并所有配置（含 .env），生成新的 runtime/config.php。注意：
-
runtime/目录必须可写，否则命令静默失败 - 若用 Docker 或部署平台，需确认 CLI PHP 和 Web PHP 使用同一份 OpCache 配置
- 执行后建议立刻访问一个调用
config()的接口验证，别只看命令是否“成功”
手动清理 + 强制重载（开发/排查阶段）
三步到位，比单删文件更彻底：
- 执行
rm -f runtime/config.php - 运行
php think config:clear（它不仅删文件，还会重置容器内配置实例） - 最后执行
php think optimize:config校验配置合并逻辑是否正常，输出中应显示Using cache store: file或对应驱动名
这一步能暴露 CACHE_STORE 被误设为 redis 等隐藏配置冲突。
绕过缓存快速验证（线上不敢动时）
不想删任何东西又想确认是不是配置缓存的问题？临时改配置驱动：
- 把
config/cache.php中的default改成'null' - 或临时把 Redis host 改成一个无效地址（如
'host' => '127.0.0.99'）
框架会自动降级，不报错也不阻塞，改完立刻测接口。比等缓存过期（有些设了 7 天）靠谱得多。
真正容易被忽略的是：即使 runtime/config.php 更新了，PHP OpCache 仍可能缓存着旧的 config/app.php 字节码。此时必须重启 PHP-FPM 或执行 opcache_reset()，否则 config() 永远不会变。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
