基本可断定是框架配置缓存与PHP OPcache双重锁定；需先确认config('app.debug')是否为false，再执行php think config:cache，最后清理OPcache（如opcache_reset()或重启php-fpm）。
配置改了但 config() 仍返回旧值，基本可以断定是框架配置缓存 + PHP OPcache 双重锁定，不是代码没保存、不是浏览器缓存、也不是服务器没重启——得按顺序破这两层锁。
确认是不是框架配置缓存在作怪
先看 app_debug 实际值：在控制器里加 var_dump(config('app.debug'));。输出 true 说明调试模式生效，框架每次都会重新加载配置文件；此时若仍读不到新值，问题大概率在 OPcache 或文件权限上。输出 false 则说明缓存已启用，必须走清理流程。
-
runtime/config.php文件存在且非空？它只在app_debug = false时由php think config:cache生成；若为空数组或含 PHP 8.1+ 语法（而 CLI PHP 是 8.0），框架会静默 fallback，但可能漏读部分配置 - 运行
php think optimize:config，它不写文件，只校验配置合并逻辑；若输出Using cache store: redis却本该用file，说明.env里CACHE_STORE被意外覆盖
清除配置缓存的三种可靠方式
别只删 runtime/config.php —— 那只是表象，config:clear 才会重置容器内缓存实例。
-
命令行重建（生产环境首选）：确保
config/app.php和.env中app_debug均为false，再执行php think config:cache；成功后runtime/config.php大小应在 30KB 以上；若静默失败，检查runtime/是否可写（chmod -R 755 runtime/） -
开发阶段临时绕过：把
config/app.php的'app_debug' => true，框架就跳过所有缓存；但上线前必须改回false，否则性能崩盘 -
手动删 + 命令清双保险：先
rm -f runtime/config.php，再执行php think config:clear；它会连带清空runtime/config/子目录，并触发容器 reset，比单删文件彻底得多
OPcache 导致“假缓存”的排查与处理
即使 runtime/config.php 已更新、config:cache 已重跑，config() 还是旧值——十有八九是 OPcache 把刚改过的 config/app.php 或 runtime/config.php 缓存住了。
立即学习“PHP免费学习笔记（深入）”；
- 检查
php.ini中opcache.revalidate_freq是否为0（TP6+ 注解路由热更新必需，也影响配置重载） - 宝塔用户可在「PHP 设置 → 配置修改」里搜
opcache，把opcache.enable临时设为Off测试；确认是 OPcache 后，改回On并执行php think clear+ 重载 PHP-FPM - Linux 下可用
sudo pkill -f "php-fpm"强制刷新进程级 OPcache，比单纯 reload 更彻底
最易被忽略的是：改完 .env 后没清 config:cache，或者清了但 runtime/ 权限不对导致命令静默失败；OPcache 层面的缓存又常被当成“框架问题”跳过，结果反复折腾配置文件本身。
