PHP 8.6 的 OPcache 预加载，常被误解为一次普通的运行时优化配置。实际上，它发生在 PHP 启动阶段，只有满足运行模式、脚本内容和配置方式这些前提，预加载才会真正生效；下面按环境确认、脚本编写、配置落地和结果验证四步说明。
先确认：当前环境能不能触发预加载
预加载（Preloading）从 PHP 7.4 就已经引入，到了 PHP 8.6 仍然完整支持。但它不是所有 PHP 运行方式都会执行，至少要先满足下面两个条件：
- OPcache 已启用并处于激活状态，即
opcache.enable=1 - PHP 运行在 FPM 或 Apache 模块模式下，CLI 模式不会触发预加载
这一点很关键。因为预加载是在主进程启动时执行一次，不属于某个请求的生命周期，所以如果你只是在命令行里验证脚本，通常看不到预加载效果。
preload.php 应该怎么写
启用预加载时，PHP 会在启动阶段执行一个专门的预加载脚本。这个脚本里通过 require_once 或 include_once 引入的文件，会被提前编译、优化并常驻共享内存。
一个典型示例是 /var/www/preload.php：
这里要注意，preload.php 不是普通业务脚本，写法应尽量静态、确定、可一次性执行：
- 可以使用固定路径的
require_once、include_once - 不要包含动态逻辑，例如
$_GET、拼接后的file_get_contents路径等 - 不要依赖运行时上下文，否则主进程启动时就可能失败
换句话说，预加载脚本更适合放那些基础类、接口、工具函数或稳定的自动加载入口，而不适合塞入请求相关逻辑。
在 php.ini 里启用 opcache.preload
确认 OPcache 已启用后，需要在 Web SAPI 实际加载的那份 php.ini 中加入预加载配置，而不是随手改一份 CLI 使用的配置文件。
opcache.preload=/var/www/preload.php
opcache.preload_user=www-dataopcache.preload_user=www-data 是可选项，通常用于 Linux，指定执行预加载的系统用户。
这一步有几个容易踩坑的点：
opcache.preload必须使用绝对路径- PHP 进程必须对该文件有读取权限
- 预加载脚本建议放在
webroot之外，避免被 Web 请求直接访问 - 如果脚本有语法错误，或者其中某个
require失败，PHP 启动时可能会静默跳过预加载
遇到这种“看起来配了、实际上没生效”的情况，可以结合 error_log 和 opcache_get_status() 一起排查，而不要只看配置文件本身。
重启后怎么验证是否真的生效
配置完成后，需要重启 PHP-FPM 或 Apache，因为预加载只会在主进程启动时执行一次。重启之后，再通过页面或代码检查结果。
最直接的办法，是访问包含 phpinfo() 的页面，在 “OPcache” 区块里确认这些信息：
- “Preloaded Scripts” 显示非零数字，例如
3 opcache_get_status()['precache']返回非空数组opcache_is_script_cached('/var/www/app/Helpers/StringUtils.php')返回true
可以直接使用下面这个判断方式继续核对缓存状态：
opcache_get_status()['precache']
opcache_is_script_cached('/var/www/app/Helpers/StringUtils.php')还有一个容易被忽略的机制：预加载只对主进程执行一次，后续 Worker 进程会继承已经编译好的结果，不需要重复编译。这也是它和普通运行时缓存行为的根本区别。
如果你的目标是让一批稳定、频繁使用的基础文件在服务启动后直接驻留内存，那么这项配置值得启用；但前提是预加载脚本必须足够稳定、静态，并且部署环境确实运行在 FPM 或 Apache 模块模式下。
