PHP OPcache 预加载为什么不适合所有运行时对象

PHP OPcache 预加载适合提前放入运行时的是稳定的类、函数、接口和 trait 定义，不是“所有创建出来的对象”。如果一个对象依赖当前请求、当前租户、环境变量、数据库连接或可变缓存，就不应该因为创建成本高而塞进 preload.php。这类状态一旦跟随服务器进程常驻，收益通常抵不过版本切换、内存占用和状态污染的代价。

官方地址：https://www.php.net/manual/en/opcache.preloading.php

判断标准可以压缩成一句话：预加载“稳定的代码声明”，请求内创建“带生命周期的运行时对象”。

预加载解决的是启动成本，不是对象池

OPcache 本身会缓存编译后的脚本；预加载再向前一步，在 PHP-FPM 或 mod_php 启动时执行一个入口脚本，把其中引用到的文件解析进持久内存。之后请求可以直接看到已经存在的函数、类、接口和 trait。它减少的是重复加载、解析和类依赖链接的成本。

但“可见”不等于“把整个应用状态安全地共享了”。PHP 官方 RFC 特别说明，静态成员和静态变量的值不会因此跨越请求边界；预加载也不会把请求上下文变成一个可靠的全局状态容器。预加载更接近一个启动期的代码声明层，而不是对象池。

先按生命周期筛选，再决定是否预加载

可以把候选分成三层。第一层是无请求状态的代码声明，例如纯工具函数、已经确定依赖关系的值对象类、框架中不会按租户变化的基础类。第二层是启动期配置，它可以在 preload 阶段读取，但必须确认发布后不会在不重启的情况下动态变化。第三层是运行时对象，这一层通常应该留在请求内。

尤其不要把“单例”当成适合预加载的充分条件。单例只说明应用代码想限制实例数量，并没有说明它能跨请求、跨进程、跨版本安全复用。

用最小入口文件控制预加载范围

入口文件应该显式列出稳定依赖，先从少量基础类开始，而不是递归把整个项目目录全部塞进去。官方手册区分了 include 与 opcache_compile_file()：前者会执行文件，后者只编译并缓存文件。需要避免启动期副作用时，应优先使用编译方式，并把依赖顺序和失败处理写清楚。

对应的配置可以只放在生产 FPM 的 PHP 配置中：

; 入口脚本在 PHP-FPM 启动时执行
opcache.enable=1
opcache.preload=/var/www/app/preload.php
; 非特权用户运行预加载，避免把应用代码以 root 执行
opcache.preload_user=www-data

部署时必须把“替换代码”和“重启 PHP-FPM”视为一个动作。官方文档说明，预加载文件需要重启 PHP 进程才能清除；只替换磁盘文件、只调用一次 opcache_reset()，都不能当作新预加载已经生效的证明。

哪些信号说明应该放弃预加载

只要对象满足下面任意一项，就应优先放回请求内：构造函数连接数据库或网络服务；对象包含当前用户、请求头、语言、租户或权限；对象会根据时间、配置中心或数据库内容变化；对象持有文件、socket、锁或外部扩展资源；对象需要热更新而发布流程不能稳定重启 FPM。

在多应用共用进程或共用 FPM 池的场景还要更谨慎。RFC 提醒，不同应用或不同版本如果预加载了同名类，先加载的实现可能阻止另一份实现被加载。更稳妥的做法是按应用隔离 FPM 池，或者只预加载公共框架声明，不预加载应用层可变对象。

常见问题

CLI 里打开 OPcache 后要不要预加载？通常没有必要。预加载的主要价值来自一个持久进程服务多个请求；一次性 CLI 进程很快结束，启动成本可能反而更高。

预加载越多越快吗？不一定。预加载会增加基础内存，并把更新和重启绑定到部署流程。先选择稳定、频繁使用且依赖简单的声明，再根据真实基线决定是否扩大范围。

最终怎么做选择？把候选写成一张清单：是否无请求状态、是否持有外部资源、是否需要动态更新、是否能按版本重启。四项中只要有一项答案不利，就让请求生命周期负责创建和销毁。