FrankenPHP官方镜像已预装opcache.so但需手动启用：取消php.ini中opcache.enable=1注释、确保zend_extension=opcache.so未注释且位置正确、设置opcache.enable_cli=1，三者缺一不可，修改后必须重启容器。
FrankenPHP 官方镜像已预装 opcache.so，无需手动编译或 pecl install；但默认未启用，且常见错误是只改了 opcache.enable=1 却漏掉 zend_extension 加载或参数冲突，导致缓存始终不生效。
确认容器是否使用官方 FrankenPHP 镜像
非 dunglas/frankenphp 镜像（如自建 alpine、scratch 或静态构建镜像）几乎肯定不带 opcache.so，也无法通过运行时配置启用 —— 换镜像是唯一可靠路径。
执行以下命令验证：
docker inspect your-frankenphp-container | grep "dunglas/frankenphp"
若无输出，别折腾 php.ini，直接切换回官方镜像。否则后续所有配置都无效。
立即学习“PHP免费学习笔记（深入）”；
启用 OPcache 的最小必要配置
FrankenPHP 默认加载 /usr/local/etc/php/php.ini（即 php.ini-production），该文件中关键行被注释，必须同时满足三项才真正启用：
- 取消
;opcache.enable=1的分号注释 - 确保
zend_extension=opcache.so行存在且未被注释（位置需在[opcache]段落之前） -
opcache.enable_cli=1必须显式设为 1（FrankenPHP CLI 模式需参与缓存，否则部分预热逻辑失败）
缺任一条件，php -m | grep opcache 可能显示模块名，但 opcache_get_status() 会返回空或 opcache_enabled=false。
生产环境关键参数避坑点
以下参数看似常规，但组合错误会导致缓存频繁失效或内存溢出：
-
opcache.validate_timestamps=0和opcache.revalidate_freq=0不可共存：后者仅在前者为 1 时生效；设为 0 且validate_timestamps=0时，revalidate_freq被忽略 —— 正确做法是明确设validate_timestamps=0，靠发布后调用opcache_reset()刷新 -
opcache.memory_consumption建议 ≥256（单位 MB）：FrankenPHP + PHP 8.4 启用 JIT 后实际内存占用更高，128MB 容易触发oom_count > 0 -
opcache.max_accelerated_files必须 ≥ 项目实际 PHP 文件数：低于此值会引发哈希冲突，缓存命中率断崖下跌；Laravel/WordPress 类项目建议 ≥20000
修改后必须 docker restart 容器，reload 或信号重载对 FrankenPHP 无效。
验证是否真生效而非“假启用”
仅看 phpinfo() 显示 “Enabled” 不够，要确认缓存行为真实发生：
- 执行
php -r "var_dump(opcache_get_status()['opcache_statistics']['oom_count'] === 0);"，返回bool(true)且used_memory随请求增长，才算内存分配成功 - 检查
opcache_get_status()['opcache_statistics']['hits']是否远高于misses（比如 10:1），否则说明脚本根本没进缓存 - 若用宝塔等面板管理，注意其 PHP 管理页可能读取的是系统全局
php.ini，而非 FrankenPHP 容器内路径，验证务必进容器执行
最易被忽略的是：FrankenPHP 的 OPcache 生效依赖于整个请求生命周期走的是其内置 SAPI，若反向代理层（如 Nginx）错误地将部分请求绕过 FrankenPHP 直连 PHP-FPM，那这部分流量完全不会经过 OPcache。
