OPcache预加载文件越多，内存占用越不可控；预加载文件常驻共享内存，不计入memory_limit，也不受PHP GC管理，preload内存消耗需严格匹配opcache.memory_consumption，否则引发重编译和性能抖动。
opcache.preload 加载的文件越多，内存占用越不可控
FrankenPHP 启用 opcache.preload 后，预加载的 PHP 文件（如框架核心、Composer autoloader、预编译类）会常驻在共享内存中，不再随请求释放。这不是“多占一点”，而是直接吃掉固定内存块——且这部分内存不计入 memory_limit，也不受 PHP GC 管理。
常见错误现象：top 显示 FrankenPHP 进程 RSS 持续高于 800MB，但 memory_get_peak_usage(true) 却只报 200MB；php -r "echo opcache_get_status()['preload_statistics']['memory_consumption'];" 返回值远超预期（比如 350MB），说明 preload 已成内存主力消耗源。
- 每预加载 1 万个类（含 trait/interface），实测增加 OPcache 共享内存约 40–70MB（取决于类复杂度和字符串常量数量）
- Symfony 全量 preload（
vendor/autoload.php+src/Kernel.php+ 所有 bundle 的Bundle.php）通常吃掉 200–300MB，比 Laravel 预加载同规模代码多出 60%+，主因是 Symfony 的 DI 容器编译后生成大量闭包和反射对象 -
opcache.memory_consumption必须 ≥ preload 实际占用，否则 OPcache 会频繁失效重编译，反而引发内存抖动和 CPU 尖峰 - preload 文件里若含
new PDO()、fopen()或cURL句柄，进程启动即失败——preload 阶段不允许资源型操作
preload 和 worker 模式叠加时，内存不是线性叠加，而是乘性放大
Worker 模式下，每个 PHP 线程都会读取同一份 preload 内存，但 autoload 类定义、静态属性初始化、OPcache 字符串表这些结构，在每个线程私有堆里仍要复制一份运行时副本。也就是说：preload 吃的是共享内存，而 worker 线程数越多，私有堆里被“镜像”的部分就越多。
例如：preload 占用 250MB OPcache 共享内存，启用 8 个 worker 线程后，实际总内存增长 ≈ 250MB（共享） + 8 × (每个线程私有堆新增 15–25MB) ≈ 370–450MB，而非简单 250 × 8。
立即学习“PHP免费学习笔记（深入）”；
- 禁用
opcache.enable_cli=1（FrankenPHP 默认开启）会导致 preload 失效，worker 回退到每次请求重加载，性能断崖下跌 - 不要在 preload 脚本里调用
date_default_timezone_set()或setlocale()—— 这些函数影响全局状态，多线程下可能互相覆盖 - 用
opcache_get_status()['scripts']检查哪些文件真被 preload 了；未出现在列表里的，说明路径错、权限不足或包含语法错误 - 对 Composer 项目，优先 preload
vendor/composer/autoload_classmap.php，而非autoload_files.php，前者是静态映射，后者会执行任意 PHP 代码，风险高、内存开销大
怎么判断 preload 是否过度？
最直接的方式是对比两个指标差值：opcache_get_status()['memory_usage']['used_memory']（当前 OPcache 已用）减去 opcache_get_status()['preload_statistics']['memory_consumption']（preload 占用）。如果差值
- 压测时观察
opcache_get_status()['opcache_statistics']['misses']是否随 QPS 上升而跳涨——这是 OPcache 空间不足的明确信号 - FrankenPHP 日志里出现
PHP Warning: file_put_contents(): Unable to create or write to file ...，但磁盘空间充足？大概率是 OPcache 抢占了 mmap 区域，导致系统无法分配新内存页 - 容器部署时，
mem_limit必须 ≥opcache.memory_consumption+ (num_threads× 单请求私有堆保守估值)，不能只看memory_limit
