现场是这样的。发布新版本后部分页面还是旧逻辑，确认文件已经更新，只有重启服务才生效。
排查方向其实有限，先把可能性排一排。缓存开启了较长有效期，文件变更检查被关闭；发布方式是覆盖文件，修改时间没有变化；多台机器只重启了其中一台。
先确认缓存配置
php -i | grep -E 'opcache.enable|validate_timestamps'再往下开启时间戳校验
grep -n opcache.validate_timestamps /etc/php.ini然后重载服务清空缓存
systemctl reload php-fpm等前面都确认过，再确认所有节点都已更新
php -r 'print_r(opcache_get_status()["opcache_statistics"]);'命令输出我都留了记录，免得改完记不清原来的值。
改之前先确认了最近有没有人动过配置，避免白查一遍。
这次没动代码，只在配置和运行环境上找原因。
恢复的判定其实很直接。发布后页面立即呈现新逻辑，各节点表现一致，无需重启机器。
容易忽略的是，关掉时间戳校验能提升性能，但发布流程必须显式重载；原子发布配合软链切换能避免这类问题。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。