FrankenPHP默认预装OPcache但未生效，需取消php.ini中;opcache.enable=1注释、确认zend_extension=opcache.so路径正确并重启容器，再用opcache_get_status()验证非空数组返回。
确认 OPcache 确实已加载并启用
FrankenPHP 镜像默认预装 opcache.so，但 opcache.enable=1 在 php.ini-production 中是被注释的——这意味着模块虽存在，实际并未工作。常见现象包括：opcache_get_status() 返回 false 或空数组、phpinfo() 页面显示 “Opcode Caching: Disabled”。必须进容器检查真实生效的配置路径（执行 php --ini），定位到实际加载的 php.ini（通常是 /usr/local/etc/php/php.ini），取消 ;opcache.enable=1 的注释，并确保 zend_extension=opcache.so 行未被注释且位于 [opcache] 段落之前。
worker 模式下必须设 opcache.enable=1 且调大内存
FrankenPHP 的 worker 模式让 PHP 进程常驻内存，OPcache 缓存复用率极高；一旦禁用或内存不足，每个请求都会重新编译全部文件，性能断崖式下跌。关键参数建议如下：
-
opcache.enable=1—— 必须显式开启，worker 下设为 0 会导致严重性能退化 -
opcache.memory_consumption=384—— WordPress/Laravel/Symfony 类文件多，256MB 容易触发oom_count > 0；高并发建议 384～512 -
opcache.max_accelerated_files=20000—— Composer 自动加载 + 框架代理类常超 15000，低于此值会频繁踢出缓存项 -
opcache.interned_strings_buffer=16—— 防止字符串 intern 冲突，≥12 即可，16 是稳妥值
opcache.validate_timestamps 和部署流程强绑定
worker 进程不重启就不会自动感知文件变更。若设 opcache.validate_timestamps=0（禁用时间戳校验），又没在发布后调用 opcache_reset()，新代码永远不生效——这是高并发场景下最隐蔽的“缓存不一致”根源。
- 生产镜像部署（COPY 构建）：设
opcache.validate_timestamps=0+opcache.revalidate_freq任意值（无效），但必须在每次docker restart或健康检查端点中执行opcache_reset() - 挂载 volume 或 rsync 热更：必须保持
opcache.validate_timestamps=1，并设opcache.revalidate_freq=60～180（避免每秒校验拖慢吞吐） - 绝对不要设
opcache.revalidate_freq=0—— 它只在validate_timestamps=1下生效，设 0 实际等于“每请求校验”，高并发下 I/O 压力陡增
验证是否真起效，别只看 phpinfo()
上线后仅确认 opcache.enabled 是 On 不够，要盯两个硬指标：
立即学习“PHP免费学习笔记（深入）”；
-
opcache_get_status()['opcache_statistics']['oom_count'] === 0—— 大于 0 说明缓存空间持续不足，需调大memory_consumption -
opcache_get_status()['opcache_statistics']['hits_per_second']显著高于misses_per_second—— 如果 miss 频繁，先查max_accelerated_files是否溢出，再确认文件是否被意外排除（如opcache.exclude_patterns误配）
worker 模式下，缓存状态只反映当前进程视角；多实例部署时，每个 worker 都得单独重置，不能只调一次 opcache_reset() 就以为全好了。
