PHP OPcache 怎样在部署后刷新旧脚本

PHP 部署后刷新旧脚本，要在实际处理业务请求的 PHP 运行实例里操作：少量文件可用 opcache_invalidate($path, true) 逐个失效；整批更新可考虑 opcache_reset() 或更新对应 PHP 进程。使用预加载时，需要重启 PHP 进程才能清除预加载脚本。多节点部署还必须逐实例处理。

PHP 官方地址：https://www.php.net/

从部署完成但响应仍旧的现象入手

设想一次商品展示服务发布：磁盘上的格式化类已经更新，但部分请求仍显示旧格式。这里用的是排查场景，不是实际故障记录。首先要确认响应来自哪个发布版本、哪个实例，再看该实例的 OPcache 配置。

当 opcache.validate_timestamps=1 时，OPcache 按 opcache.revalidate_freq 的间隔检查脚本时间戳；将前者关闭后，后者不再生效，文件变化需要显式失效、重置或重启相应服务处理。因而，反复修改检查间隔并不能解决关闭时间戳检查后的更新问题。

另一个常见误判是只查看命令行的 PHP 配置。部署脚本运行的 CLI 与站点使用的 FPM 可能加载不同配置，也可能处在不同容器中。应以实际请求的运行环境为准，不能把一次 CLI 调用成功视作 FPM 缓存已刷新。

少量变更按可信文件清单失效

已知只有几个普通脚本变化时，可以把发布清单交给部署管理逻辑逐个失效。下面的路径是项目示例，使用前替换为发布产物中的固定文件。代码应嵌入已有鉴权、限制访问的管理入口，并由目标运行环境执行，不要直接作为公开网页上传。

第二个参数为 true，表示不以“磁盘修改时间比缓存更新”为失效前提。函数返回 true 也可能意味着没有需要失效的条目，因此不能据此证明脚本原本已缓存，更不能证明业务响应已切换。

仅刷新入口文件不等于刷新它依赖的所有文件。发布清单需要覆盖实际变化的 PHP 脚本；若无法可靠枚举，按实例整体更新往往更容易维护。

大范围更新区分 reset 与进程重启

reset 后脚本在后续命中时重新加载、解析，不是在当前请求中重新执行已经加载的业务代码。函数可能因 OPcache 未启用或重启正在等待、进行而返回 false，部署记录应区分成功与失败，不要反复无条件调用。

如果配置了 opcache.preload，普通失效与内存重置不能替代预加载脚本所要求的 PHP 进程重启。服务名称、容器编排方式和优雅退出策略因环境而异，应沿用项目现有的进程替换机制；只重启前面的反向代理不等于替换后面的 FPM。

把刷新安排到流量切换之前

对多实例服务，建议按单实例发布：先摘流并让在途请求按既定策略结束，再准备完整的新版本及依赖；将该实例指向新版本后，在正确运行环境执行失效、重置或进程替换；随后预热并检查版本标识与关键业务，再把实例加入流量。每个实例完成后再处理下一个。

这套顺序避免在一半文件已覆盖、另一半仍旧时重编译出混合版本。原地覆盖期间单独清缓存并不能提供原子发布保证。使用版本目录也应明确实际解析路径，并为旧版本保留回滚条件。

回滚不是只恢复目录指向：还应在目标实例重新执行与回滚版本匹配的缓存或进程动作。旧请求已经加载的类与长时间运行的任务，需要各自的退出、重启安排，不能靠一次 OPcache API 调用追溯替换。

常见问题

每次业务请求都调用 reset 可以吗？

不适合。整批缓存频繁失效会让后续请求重复解析脚本。应把它作为受控发布动作，记录实例与发布版本。

函数返回 true，为什么仍有旧页面？

可能命中了其他实例、已有请求，或者应用与代理的响应缓存。先对应版本和实例，再确定是哪一层缓存。

刷新脚本为什么不能接收用户传来的路径？

路径应来自可信发布清单。PHP 官方文档明确提醒不要给失效函数传入不可信输入；管理入口也应受访问控制。

参考：单脚本失效、内存缓存重置、OPcache 配置、预加载生命周期。