PHP-FPM与OPcache是分层互补加速机制：FPM调度进程执行脚本，OPcache在执行前缓存字节码；需确保FPM配置启用OPcache、扩展已加载、生产环境禁用时间戳验证，并调优内存、文件数等参数以提升命中率。
PHP-FPM 与 OPcache 配合，本质是分层加速：PHP-FPM 负责进程调度与脚本执行，OPcache 则在执行前把 PHP 源码编译成字节码（opcode）并缓存住，避免每次请求都重复解析和编译。两者不冲突，而是天然互补——FPM 的每个 worker 进程都能共享同一份 OPcache 缓存（前提是启用共享内存且配置正确）。
确保 OPcache 在 PHP-FPM 环境中真正生效
很多部署失败是因为 OPcache 被禁用、未加载，或仅对 CLI 生效而对 FPM 无效。需确认以下三点：
- 检查 php-fpm.ini 或主 php.ini（不是 CLI 的 php.ini）中已启用：
opcache.enable=1，且 opcache.enable_cli=0（CLI 不需要，但别误开） - 确认扩展已加载：运行 php-fpm -m | grep opcache 或查看 phpinfo() 页面中的 OPcache 模块状态
- 生产环境必须设为：opcache.validate_timestamps=0；否则每次请求仍会检查文件修改时间，失去缓存意义
关键配置参数要匹配实际负载
默认 OPcache 内存（64MB）和文件数限制（2000）在中大型项目中极易打满，导致频繁淘汰缓存、命中率骤降：
- opcache.memory_consumption=256（单位 MB）：建议 128–512，视项目规模和服务器内存调整
- opcache.max_accelerated_files=20000：应大于项目中所有 PHP 文件总数（含 vendor），可用 find /path/to/app -name "*.php" | wc -l 估算
- opcache.interned_strings_buffer=16：提升字符串常量复用效率，尤其在大量类/命名空间场景下有效
- 若使用 Composer 自动加载，建议开启：opcache.save_comments=1 和 opcache.load_comments=1，避免 Doctrine/Symfony 等框架反射失败
配合 PHP-FPM 进程模型避免缓存失效抖动
OPcache 是进程内共享的，但 PHP-FPM 的进程重启（如 pm.max_requests 触发）会导致该 worker 的缓存清空。高频重启 = 高频冷启动 = 响应时间毛刺：
立即学习“PHP免费学习笔记（深入）”；
- 设置合理的 pm.max_requests=500（而非默认 0 或过小的 100），平衡内存泄漏风险与缓存稳定性
- 动态模式（pm=dynamic）下，避免 pm.start_servers 过低，否则新进程冷启动集中发生
- 可配合 opcache.revalidate_freq=60（开发环境）或保持 0（生产），控制缓存校验节奏
验证是否真正起效
不能只看 phpinfo() 显示“enabled”，要观测真实行为：
- 访问 opcache_get_status() 返回数组，重点关注：
opcache_statistics['opcache_hit_rate']（建议 >95%）、
opcache_statistics['memory_usage']['used_memory']（是否持续占用，而非反复归零） - 用 ab 或 wrk 压测前后对比响应时间：典型优化后，简单脚本平均耗时可下降 30–50%，复杂框架（如 Laravel）首字节时间（TTFB）改善更明显
- 注意 Nginx 层不要误配 fastcgi_cache 与 OPcache 叠加——前者缓存整个 HTTP 响应，后者缓存脚本执行层，二者定位不同，一般不混用
