启用OPcache并合理配置PHP-FPM与Nginx可将PHP执行时间压至20–30ms：需设opcache.memory_consumption=256、max_accelerated_files=20000、validate_timestamps=0、interned_strings_buffer=8，PHP 8.0+建议启用JIT；PHP-FPM采用dynamic模式，pm.max_requests=500，listen.backlog=1024；Nginx须正确fastcgi_pass、禁用干扰机制，并验证Hits率＞95%。
直接启用 OPcache 并配合合理的 PHP-FPM 和 Nginx 配置，能显著减少脚本重复解析开销，把 PHP 执行时间从百毫秒级压到 20–30ms 级别。关键不在“装了没”，而在“配得对不对”。
OPcache 必须启用且参数要调准
仅开启 opcache.enable=1 远不够。生产环境需同步设置以下几项：
-
分配足够共享内存：
opcache.memory_consumption=256（单位 MB），小项目可设 128，中大型建议 256 或更高； -
缓存足够多文件：
opcache.max_accelerated_files=20000，避免因哈希冲突频繁淘汰缓存； -
禁用运行时检查：
opcache.validate_timestamps=0，否则每次请求都去读文件修改时间，等于白开； -
启用字符串驻留优化：
opcache.interned_strings_buffer=8，减少内存重复分配； -
PHP 8.0+ 可加 JIT：
opcache.jit_buffer_size=64M+opcache.jit=1235，对计算密集型逻辑有额外加速。
PHP-FPM 进程池要匹配 OPcache 的稳定性
OPcache 是进程级共享的，但 PHP-FPM 每个子进程都有独立的 OPcache 实例。若进程频繁重启，缓存就总在冷启动——所以要控制进程生命周期：
- 设
pm = dynamic，避免 static 模式下内存浪费或 ondemand 模式下响应延迟； - 调高
pm.max_requests=500，让每个进程处理一定请求数后优雅退出，防内存泄漏又不打断缓存热身； - 根据服务器资源设合理进程数，比如 8 核机器可设
pm.start_servers=20、pm.max_children=300，确保有足够进程承载已热缓存的脚本； - 确认
listen.backlog=1024（而非默认 511），防止高并发时连接被丢弃，间接导致 FPM 进程排队阻塞。
Nginx 层要避免干扰 OPcache 效果
Nginx 本身不参与 OPcache，但错误配置会绕过或削弱其作用：
立即学习“PHP免费学习笔记（深入）”；
- 确保
fastcgi_pass正确指向 PHP-FPM（如127.0.0.1:9000或 unix socket），转发失败会导致 502，此时根本没走到 OPcache； - 不要在 Nginx 中用
add_header X-PHP-OPcache "Off"类指令误导调试，生产环境无需暴露此信息； - 禁用可能导致脚本重载的机制，例如开发中常用的
opcache.revalidate_freq=2，上线必须为 0； - 静态资源（CSS/JS/图片）由 Nginx 直接服务，不走 PHP-FPM，这样既减轻 FPM 压力，也避免无关请求干扰 OPcache 内存占用。
验证 OPcache 是否真生效
光改配置不验证，等于没做。推荐两个快速方法：
- 访问
http://your-site/opcache-status.php（需放行该文件），看 Hits / Misses 比例是否稳定在 95%+； - 命令行执行
php -i | grep opcache，确认所有关键项显示On，且opcache.enabled为1； - 观察慢日志中同一脚本的执行时间是否明显下降，特别是反复访问首页、API 入口等高频路径。
