opcache.preload是php 7.4引入的核心性能特性，它在php-fpm master进程启动时预编译并固化类文件到共享内存，跳过每次请求的文件检查与加载，实测提升ttfb达30%–50%，但需配合opcache.enable=1、足够内存及严格编写preload.php。
直接说结论：如果你的项目依赖大型框架（如 Laravel、Symfony、ZF），且 PHP 进程长期运行（如 PHP-FPM 模式），从 7.2 升级到 7.4 最值得拿来说的收益就是 opcache.preload —— 它不是“让代码快一点”，而是把类加载和 opcode 链接环节从每次请求中彻底剥离，实测提升 30%–50% 的首字节响应时间（TTFB）。
opcache.preload 不是 opcache.enable 的增强版，而是另一套机制
很多人误以为开了 opcache.enable=1 就够了，其实它只缓存单文件的 opcode；而 opcache.preload 是在 PHP-FPM master 进程启动时，就把指定文件（及它们 require/include 的所有依赖）一次性编译、链接、固化进共享内存。之后 worker 进程 fork 出来时，这些 opcode 已就位，连“检查文件是否改动”这步都跳过了。
-
opcache.preload必须配合opcache.enable=1和opcache.memory_consumption足够大（建议 ≥256M）才能生效 - 预加载的文件不能含运行时逻辑（比如
new SomeClass()或 DB 连接），否则会在 master 进程里执行，导致崩溃或资源抢占 - 所有被
opcache_compile_file()加载的文件，其常量、函数、类定义会全局可见，但静态变量、全局变量不会共享
preload.php 文件怎么写才不踩坑
它本质是一个普通 PHP 脚本，但执行时机极早——PHP 模块刚初始化完、还没处理任何 HTTP 请求。常见错误是直接 require 框架 autoload.php，结果因路径未初始化或 __DIR__ 解析错乱而失败。
- 绝对路径优先：
opcache_compile_file('/var/www/app/vendor/autoload.php')，别用相对路径或dirname(__FILE__) - 按依赖顺序显式加载：先加载接口/基类，再加载实现类；
opcache_compile_file()不自动解析use或自动加载器 - 跳过带副作用的文件：含
echo、file_put_contents、sleep()的文件会阻塞 master 启动，甚至让 PHP-FPM 启动失败 - 可以用
if (file_exists($path)) { opcache_compile_file($path); }做防御性判断，避免部署不全时报错
升级后必须重启 PHP-FPM，且修改 preload.php 后不自动热更
这是最容易忽略的一点：预加载内容在 PHP 进程生命周期内不可变。哪怕你改了 preload.php 并重载配置，旧的 opcode 仍留在内存里，新逻辑完全不生效。
- 每次修改
preload.php或它加载的任何文件，必须执行systemctl restart php-fpm（或对应服务名） - 开发环境建议关掉
opcache.preload，用常规 autoloader；上线再开，否则改一行代码要等几秒重启，效率极低 - 如果用宝塔面板，注意它“重载配置” ≠ “重启服务”，必须点“重启 PHP 服务”按钮，否则白配
-
opcache_get_status()['preloaded_scripts']可查已预加载的脚本列表，但仅当opcache.enable_cli=1且 CLI 模式下运行才有效
真正难的不是配置那几行 ini，而是厘清整个项目的类依赖图、排除动态行为、确保 preload.php 的幂等性和稳定性。很多团队卡在“为什么开了没效果”，最后发现是 preload.php 里某处 require_once 报了警告但被静默吞掉，或者路径拼错了斜杠。动手前，先用 php -l preload.php 和 php -d opcache.enable=0 preload.php 过一遍逻辑更稳妥。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
