ThinkPHP配置“假缓存”本质是OPcache锁住旧字节码，需双清OPcache与框架配置缓存并验证：执行opcache_reset()、reload php-fpm、php think config:clear && config:cache，再交叉检查接口值、opcache状态及runtime/config.php更新时间。
ThinkPHP 中 OPcache 导致配置“假缓存”——即改了 config/app.php 或 .env，config('app.app_name') 仍返回旧值——本质是 PHP 字节码层锁住了旧配置逻辑，框架缓存清了也没用。重载关键在双清+验证：既要清 OPcache 内存，也要确保框架配置已重建。
确认是否真被 OPcache 锁住
先排除框架缓存干扰：
- 在控制器里执行
var_dump(config('app.debug')); - 若输出
true，说明调试模式开启，框架本应直读源文件；此时仍不生效，大概率是 OPcache 没刷新或.php文件被它缓存了 - 若输出
false，则框架已启用配置缓存（runtime/config.php），但 OPcache 可能还在运行旧的config.php字节码
手动重载 OPcache 的可靠方式
别依赖重启服务，用命令直接触发重置（更快、更准）：
- 查当前 PHP 路径（宝塔用户可在「软件商店 → PHP 设置 → PHP版本路径」复制，如
/www/server/php/82/bin/php） - 执行：
/www/server/php/82/bin/php -r "opcache_reset();"
- 返回空结果即成功；若报错
Call to undefined function opcache_reset()，说明 OPcache 未启用或 CLI 下被禁用（需检查opcache.enable_cli=1）
⚠️ 注意：
opcache_reset()只重置当前 PHP-FPM worker 进程的缓存。多进程环境下，建议补一步：立即学习“PHP免费学习笔记（深入）”；
systemctl reload php-fpm # 或 lnmp php-fpm reload（宝塔）这样所有 worker 都会加载新字节码，避免部分请求仍走旧逻辑。
同步清理 ThinkPHP 配置缓存
OPcache 清了，但 runtime/config.php 若还是旧内容，config() 仍可能读错：
- 进入项目根目录，执行：
php think config:clear # 清空 runtime/config.php 及 config/ 子目录 php think config:cache # 重新生成 config.php（要求 app_debug=false）
- 检查
runtime/config.php文件大小，正常应在 30KB 以上；若为空或只有<?php return [];，说明生成失败（常见于runtime/不可写或.env中APP_DEBUG=true覆盖）
验证是否真正生效
三步交叉确认：
- 访问一个输出
config('app.app_name')的接口，看值是否更新 - 执行
php -i | grep "opcache"，确认opcache.enable => On且Cached scripts数量非零 - 查看
runtime/config.php修改时间，应与你执行config:cache的时间一致
基本上就这些。
