tp5.1开启opcache后代码不生效，主因是opcache未感知文件变化或丢弃phpdoc注释导致框架功能异常；需确认真实php.ini路径、启用opcache.so及opcache.enable=1、设opcache.save_comments=1、调整validate_timestamps与revalidate_freq，并重启php-fpm及清理runtime缓存。
TP5.1 开启 OPcache 后改了代码却没生效，不是代码没传上去，而是 PHP 进程还在执行缓存里的旧字节码。核心问题在于 OPcache 没感知到文件变化，或丢弃了关键注释导致框架功能异常。
确认 OPcache 是否真正启用并加载了正确配置
别只看宝塔面板显示的“PHP配置文件”链接——它常指向备份副本，实际生效的可能是另一份。进入终端执行：
- php --ini 查出真实加载的 php.ini 路径
-
cat /usr/local/php/etc/php.ini | grep -E "(opcache|zend_extension)" 检查三处关键项是否启用且未被注释：
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=0（CLI 环境通常应关闭） - 若发现配置被分号注释或值为 0，手动编辑该 php.ini 并保存；必须执行 lnmp php-fpm restart（或 systemctl restart php*-fpm），仅 reload 不会重载扩展
检查 opcache.save_comments 是否为 1
TP5.1 的模板标签（如 {present}、{empty}）、路由参数自动绑定、验证规则解析等，全部依赖反射读取 PHPDoc 注释。OPcache 默认可能丢弃注释，导致这些功能静默失效。
- 在 php.ini 中确认：
opcache.save_comments=1
opcache.load_comments=1（默认开启，但建议显式写出） - 改完必须重启 PHP-FPM，同时清空 ThinkPHP 的 runtime/cache/ 目录——否则框架仍用旧编译结果
- 紧急上线时可临时设 config/app.php 中 'app_debug' => true，跳过部分缓存逻辑，但不可长期使用
验证 validate_timestamps 和 revalidate_freq 是否匹配发布方式
这个组合决定 OPcache 是否主动检查文件更新：
- opcache.validate_timestamps=1：每次请求前检查文件修改时间（开发环境必备）
- opcache.revalidate_freq=0：每次请求都校验（最敏感，适合调试）；设为 2~5 秒是生产折中方案
- 若生产环境设为 opcache.validate_timestamps=0（提升性能），则必须在发布后主动刷新缓存：
调用 opcache_reset() 全量清空
或对变更文件逐个执行 opcache_invalidate($file, true) - 验证方法：在接口里临时输出 git commit ID 或文件 filemtime()，对比服务器上真实文件时间戳
排除双重缓存干扰
ThinkPHP 自身有模板编译缓存、路由缓存、配置缓存；OPcache 是另一层字节码缓存。两者不联动，需分别清理：
- 清 runtime/ 下对应子目录：
runtime/cache/（通用缓存）
runtime/view/（模板编译结果）
runtime/log/（有时残留错误缓存也会影响行为） - 确认没有误用 composer clear-cache —— 它只清下载缓存，和 OPcache 完全无关
- 多机部署时，逐台检查并操作，避免只刷了一台就以为全量生效
