OPcache保存编译后的PHP代码，部署后的旧行为可能与缓存检查策略、运行进程、发布路径或其他应用缓存有关。应先确认实际执行的是哪份文件，再决定失效、重载或调整部署流程，不一见旧内容就重启服务器。
用可核验版本确认执行路径
记录发布文件的路径、版本标识和实际请求到达的节点，排除上传到错误站点、软链接旧目录或多节点只更新一台。页面缓存也可能返回旧HTML而没有执行新PHP，应把静态响应与代码执行分开观察，不公开输出敏感绝对路径。
读取OPcache的真实配置
核对目标FPM环境是否启用OPcache、时间戳检查和重新验证设置。不同部署策略可能有意关闭自动检查，此时必须配套可靠的刷新机制。不能只看CLI的OPcache状态，推断网站池中缓存已经失效；它们可能不是同一个运行上下文。
按部署范围选择更新方式
对明确文件可使用适用的失效机制，或按运维流程处理相关进程与服务。操作前确认权限和影响范围，不向公众暴露任意重置OPcache的HTTP入口。重置编译缓存也不等于清理对象缓存、CDN或页面缓存，需要按实际旧内容来源分别处理。
把验证纳入以后每次发布
刷新后请求真实端点，核对新版本行为、错误日志和关键业务路径。多节点、队列及常驻进程另有自己的更新责任，不靠一台服务器返回正常就宣布全部发布完成。保留旧版本和回退步骤，使缓存策略与代码版本始终对应。
关键区别
代码文件：已写入磁盘的版本；未必被当前请求执行。
OPcache：保存编译后代码；与页面缓存不同。
部署流程：配套缓存更新机制；不可依赖随意重启。
怎样确认处理到位
所有目标执行环境均使用确认的新代码，关键业务正常，旧版本不再非预期执行，缓存刷新与回退步骤能够重复使用。
容易误判的边界
不要把公开页面旧内容全部归因于OPcache；CDN、页面缓存、错误发布路径和多节点不同步也需要排除。
