PHP OPcache 预加载文件的部署顺序

PHP OPcache 预加载部署应先准备完整版本和依赖，再让新的 PHP 服务进程以该版本的预加载配置启动，确认可用后接入流量。只覆盖磁盘文件或切换目录链接，不能据此认定常驻进程里的预加载声明已经更新。

官方文档：https://www.php.net/manual/en/opcache.preloading.php

我会先把文件更新和进程更新分开考虑

面对预加载，我更看重版本一致性，而不是先把所有文件塞进缓存。这里用一个设计场景说明取舍，不声称已经在生产压测：部署目录已经切到新版本，但服务进程仍持有原来的预加载声明，此时请求代码与常驻声明可能来自不同版本。

预加载在引擎启动时执行。官方说明清除预加载脚本需要重启 PHP 进程，因此普通按文件更新的发布习惯需要调整。它是内存与执行开销之间的取舍，不能预设一定带来明显提速。

先准备一个完整且可保留的版本目录

我的建议是把源码、依赖和预加载入口作为同一发布单元，使用独立版本目录，例如 /srv/demo/releases/build-a。这个路径是示例。文件未准备完整时不启动新进程，也不边覆盖线上目录边让启动脚本读取它。

预加载清单应只包含适合常驻的声明。不要直接加载会连接数据库、处理请求或依赖用户会话的入口。加载清单若采用 require，就要考虑父类和接口等依赖顺序；opcache_compile_file 不执行文件，与 require 的语义不同，不应机械互换。

把预加载入口绑定到服务启动配置

以下是示例 php.ini 片段；实际路径与系统账号要按部署环境替换，并确认服务进程读取的配置，而不是只看 CLI 的配置文件。

; 先完成整个版本目录，再让服务启动时读取此入口。
opcache.preload=/srv/demo/releases/build-a/preload.php
; 使用具备必要读取权限的非特权账号，名称仅为示例。
opcache.preload_user=www-data

前提是启用 OPcache，环境支持预加载。官方手册说明 Windows 不支持此功能。配置权限时，我倾向于明确读取范围，避免为了让启动通过就给服务账号任意写权限。

新进程可用后再接入流量，回滚也要对应进程

在有多实例或独立进程组的环境中，可让新组使用新版本目录启动，确认服务启动记录与内部版本信息符合预期后再切流量。旧组结束前保留它需要的版本文件；不要认为“发出重启指令”就等于所有旧进程已经退出。具体的排空、超时和进程管理操作应按实际平台制定。

回滚时同时恢复旧版本的文件引用和启动配置，再建立对应进程。若只把目录链接切回，已经常驻的新声明仍可能保留。数据库迁移是否兼容则属于另一项发布约束，不能靠预加载回滚自动解决。

哪些项目值得承担这项部署成本

我会优先考虑已经有稳定发布流程、常驻服务进程且能测量内存和请求性能的项目。频繁热改文件的开发环境更容易感到不便。先选择有限的预加载范围，再测量实际收益，比“全部预加载”更容易解释结果。

只改 preload.php 会立即生效吗？不能这样假定；它是启动阶段的输入，需要与服务进程更新配合。

切换软链接能代替重启吗？不能把它当作预加载声明更新机制。链接改变的是路径指向，进程生命周期仍需单独管理。

语义依据见PHP 官方预加载手册。本文目录隔离与进程组发布是工程建议，不是对某个服务管理命令行为的保证。