PHP OPcache 文件更新后未生效怎么办

PHP 文件已经更新却仍执行旧逻辑时，先确认实际请求落到哪套代码、哪个 PHP 服务环境，再看 OPcache 的时间戳设置。validate_timestamps 关闭时不能靠等待 revalidate_freq 秒恢复；此时文件更新应配合受控的缓存失效或服务重启策略。

官方配置说明：https://www.php.net/manual/en/opcache.configuration.php。本文只讨论普通脚本的时间戳检查与发布责任，不把预加载、长驻应用或其他缓存层混成同一个问题。

我会先区分自动检查与发布失效

假设一个站点把同路径的业务 PHP 文件替换后，用户仍看到旧逻辑。我不会仅凭这个现象断定“OPcache坏了”，而会先区分两种更新模式：由请求触发时间戳检查，或者由发布系统负责主动失效。这里是条件化的排查思路，不是一次已经发生并复现的线上事故。

前一种方式降低人工漏处理的风险，代价是需要按照配置检查文件更新；后一种方式把缓存更新纳入部署契约，但也把漏操作的后果交给发布系统。对我来说，真正重要的是谁负责让新代码被采用，而不是直接照抄“生产环境统一关闭检查”的建议。

先从服务请求看到真正生效的配置

下面是未运行的独立只读示例，建议仅集成到已有访问控制的内部诊断入口，使用后移除。它会显示配置文件位置等环境信息，不应公开发布到互联网。no-store 只是响应缓存提示，不替代鉴权，也不控制 OPcache。

Web 请求所在的 PHP 环境读取生效配置，OPcache 使用该环境中的更新策略；CLI 则是另一个需要单独识别的运行入口。php_ini_loaded_file 返回主配置文件路径，但不代表它列出了所有附加配置或覆盖来源。官方函数说明：https://www.php.net/manual/en/function.php-ini-loaded-file.php。

我会把诊断返回的运行环境与部署对象一起记录。命令行显示的值，不能直接证明处理 HTTP 请求的服务也采用同一配置。若有多台机器或多个副本，一次响应也不能代表所有实例都已经更新。

时间戳开关和检查间隔怎样配合

validate_timestamps 决定是否自动检查脚本更新时间；启用后，revalidate_freq 控制检查间隔，单位是秒，值为0表示每次请求检查。关闭前者时，后者被忽略。这里的间隔不是一个后台倒计时任务，也不是“文件发布后最多这么久所有响应必然更新”的服务保证。

; 独立测试环境的自动检查示例，不是适合所有生产站点的性能建议。
opcache.validate_timestamps=1
; 0代表每次请求检查脚本更新，不代表关闭缓存。
opcache.revalidate_freq=0

这段配置仅用于独立测试环境理解语义，不是本文实际执行过的修复。若调整的是配置文件，还需由环境管理员按服务方式使配置生效，再从对应服务请求确认实际值；不能因为保存了某个 php.ini，就认定目标进程已经重新加载。

我更倾向于先恢复可解释的更新机制，再考虑是否承担关闭时间戳检查的发布责任。单独把间隔改成0而仍保留 validate_timestamps=0，不会得到自动检查效果。

需要主动失效时，操作范围要明确

opcache_invalidate 面向一个指定脚本。默认 force=false 时，依据修改时间判断是否失效；force=true 则不以是否需要失效为条件。官方当前手册还说明，在启用文件缓存时会处理对应文件缓存项。它适用于明确掌握脚本路径的受控发布步骤，而不应接收普通用户提供的任意路径。说明：https://www.php.net/manual/en/function.opcache-invalidate.php。

opcache_reset 面向整个内存中的操作码缓存，后续命中脚本需要重新载入和解析，但它不重置文件缓存。其返回值也不是“全站每台机器都在运行新代码”的证明。API作用范围见：https://www.php.net/manual/en/function.opcache-reset.php。

在这个发布模型中，发布系统负责把文件失效或内存缓存重置作用到目标 PHP 服务副本；文件失效关联指定脚本，内存缓存重置关联内存操作码缓存。不同实例的覆盖情况应由部署编排记录。不要把清理 API 做成无需身份验证的公共“修复按钮”，也不要在每个普通请求中反复清空整个缓存。

若采用重启更新方式，应使用已经明确的服务单元和滚动部署方案，考虑容量、在途请求及回退，而不是复制一条不知道会影响哪个服务的重启命令。本文不提供或执行生产环境重启命令。

用一份判断清单结束排查

CLI里返回成功，Web就会更新吗？

不能据此推定。应明确操作对应哪套运行环境和缓存实例，再判断它是否覆盖实际服务请求。

revalidate_freq=0等于关闭OPcache吗？

不等于。它是启用时间戳检查时的检查频率，不是字节码缓存总开关。

清空OPcache会清掉所有应用数据缓存吗？

不会。操作码缓存与业务数据、框架生成文件或响应缓存是不同对象，不能用一个API的返回值替代各层判断。

我的结论是：先确定实际执行环境，再选择自动检查或发布主动失效，并把每个服务副本纳入同一发布责任。它比“看到旧页面就重置所有缓存”更容易解释，也更容易保留清晰的回退范围。本文没有读取任何生产配置、执行修复或测量性能。