ThinkPHP配置不实时生效是因runtime/config.php缓存与OPcache双重锁定；需先删该文件、执行php think config:cache重建，再重启PHP-FPM刷新进程级缓存。
ThinkPHP 配置不随文件修改实时生效，是因为 runtime/config.php 缓存锁定
ThinkPHP（尤其是 6.0+ 和 8.0）在 app_debug = false 时，会把所有配置合并写入 runtime/config.php，后续所有 config() 调用都直接 require 这个文件——它和源配置文件（config/app.php、.env）完全解耦。改完源文件不删这个缓存文件，PHP-FPM 进程 reload 后仍加载旧的 runtime/config.php，所以你看到的永远是“重启后才生效”。
这不是 ThinkPHP 的 bug，而是明确设计的性能优化：避免每次请求都解析 YAML/PHP/ENV 文件。但代价是开发者必须主动干预缓存链路。
- 验证是否命中缓存：临时设
app_debug = true，再调config('app.app_name')，若立刻变新值，说明就是缓存问题 -
runtime/config.php是单文件全量缓存，不是按 key 分片；删它不等于清空整个 runtime 目录，但必须删它 - 仅执行
php think config:cache不够——它只生成新文件，旧进程仍在读旧文件；必须让 PHP-FPM 加载新内容，所以需重启
PHP-FPM 重启才刷新配置，本质是 OPcache + 进程级文件缓存双重固化
即使你手动删了 runtime/config.php 并运行 php think config:cache，如果 PHP-FPM 工作进程没重启，依然可能返回旧值。原因有二：
- OPcache 缓存了已加载的
runtime/config.php字节码，opcache_invalidate()对 require 文件无效，必须重载 PHP-FPM 子进程 - PHP 的 realpath cache（由
realpath_cache_size控制）会缓存runtime/config.php的 inode 和路径映射，子进程生命周期内不会重新 stat
所以「改配置 → 删缓存 → 生成新缓存 → 重启 PHP-FPM」是一条不可跳过的完整链路。跳过任意一环，都会卡在某个缓存层。
为什么 Nginx reload 不行，而必须 PHP-FPM restart？
Nginx reload 只影响请求转发逻辑，不触碰 PHP 进程内存空间。ThinkPHP 的配置加载发生在 PHP 请求处理阶段，由 PHP-FPM 子进程完成。每个子进程启动时加载一次 runtime/config.php，之后全程复用内存副本。
- Linux 下：用
systemctl restart php-fpm或kill -USR2 $(cat /var/run/php/php8.2-fpm.pid)（平滑重启） - Windows 下：服务管理器里「重新启动」PHP-FPM 服务，或命令行执行
net stop "PHP-FPM 8.2" && net start "PHP-FPM 8.2" - 宝塔/AMH 等面板：必须点「重启 PHP 服务」，而非「重载配置」——后者只 reload nginx/apache
顺带一提：php-fpm -R（reload）在某些版本中只是平滑重启，不一定清 OPcache；最稳妥仍是 full restart。
想免重启热更新？得绕开框架默认缓存机制
真要实现配置热更新（比如数据库连接池切换），不能依赖 config() + runtime/config.php 这套。可行路径只有两条：
- 用外部存储：把关键配置（如 DB host/user）存在 Redis 或数据库里，每次请求前
Cache::get('db_config')，并设置合理 TTL - 自定义加载器：在
app/common/DatabaseConfig.php中绕过config()，直接 file_get_contents(.env) + parse_ini_string()，但要注意权限和并发读取安全
注意：config() 本身不支持运行时热重载——它的设计目标就是“一次加载，全程复用”。强行 hack 它，反而容易引发内存泄漏或竞态条件。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
