opcache.preload配置后无效果的根源在于OPcache未启用、preload.php路径非绝对或权限不足、依赖顺序错误及混合使用require_once与opcache_compile_file()引发冲突；须严格验证配置、权限、脚本健壮性，并重启PHP-FPM生效。
opcache.preload 是 PHP 7.4+ 中唯一能在进程启动阶段就把类/函数字节码常驻共享内存的机制，它不依赖请求触发，也不走常规 require 流程——这意味着首次请求就「零加载延迟」。但直接配了就生效？远没那么简单。
为什么 opcache.preload 配置后没效果？
常见现象是 PHP-FPM 启动后，opcache_get_status() 显示 preload_statistics 为空，或预加载的类在运行时仍报 Class not found。
-
opcache.preload必须指向一个**绝对路径**的 PHP 文件，相对路径、符号链接未解析、权限不足都会静默失败（无错误日志） - 该文件由 PHP 主进程（如 PHP-FPM master）以
opcache.preload_user指定用户执行，不是 Web 请求用户；若设为www-data，但文件属主是root且权限为600，则读取失败 -
opcache.enable=1和opcache.memory_consumption（建议 ≥256）必须启用且足够，否则预加载脚本本身都无法缓存 - Windows 系统不支持预加载，这点容易被忽略
require_once vs opcache_compile_file() 在 preload.php 中怎么选？
两者都能把文件编译进 OPcache，但行为差异极大，直接影响能否正确加载带条件逻辑或依赖顺序的代码。
- 用
require_once：会**实际执行**文件内容，支持if (class_exists(...)) { function foo() {} }这类运行时判断，但要求依赖顺序严格——比如先require_once 'A.php'再require_once 'B.php'，否则B继承A会报错 - 用
opcache_compile_file()：只编译不执行，**无视执行顺序**，适合框架类批量加载；但它跳过所有运行时逻辑，define('FOO', 1)、function_exists()判断、全局变量赋值等全部失效 - 混合使用常见：用
opcache_compile_file()加载纯类定义，用require_once加载含常量/配置/引导逻辑的入口文件（如vendor/autoload.php）
Laravel 或 Symfony 项目中哪些文件值得预加载？
不是越多越好。预加载对象是字节码，但类的静态属性、全局状态会在所有请求间共享，这是最大隐患点。
- 优先加载：框架核心类（
Symfony\Component\HttpFoundation\Response）、应用 Kernel、高频控制器基类、Eloquent Model 基类——这些类结构稳定、无副作用 - 谨慎加载：含静态可变状态的类（如自定义单例、带
static $cache = []的工具类），它们可能造成跨请求数据污染 - 不要加载：含
echo、file_get_contents(__DIR__.'/config.json')、new PDO(...)等运行时副作用的文件——预加载阶段执行会阻塞进程启动，甚至失败 - 验证是否真被加载：
opcache_is_script_cached('/path/to/SomeClass.php')返回true才算成功
部署时如何安全更新预加载内容？
预加载内容不会随文件修改自动刷新，改完代码不重启 PHP-FPM，新类定义永远不会生效——这点和普通 OPcache 缓存不同。
立即学习“PHP免费学习笔记（深入）”；
-
opcache_reset()对预加载无效，它只清普通缓存；必须 **重启 PHP-FPM 主进程**（systemctl reload php8.2-fpm）才能重新执行preload.php - CI/CD 中建议加检查步骤：部署后调用
curl -I http://localhost/healthz并验证响应头含X-Preload-Ready: 1（由 preload.php 写入$_SERVER或临时文件标记） - 避免在 preload.php 中写死版本号或时间戳，否则每次变更都需手动改脚本——可用
glob(__DIR__.'/app/Http/Controllers/*.php')动态扫描，但注意控制数量防爆内存
