opcache 缓存 php 字节码而非页面结果，跳过重复编译，实测 ttfb 降 30%~60%，cpu 峰值从 85% 降至 32%，100 次请求耗时压缩 67.9%；需通过模块加载验证和命中率 ≥95% 确认生效，生产环境推荐 validate_timestamps=0 配合手动刷新，并搭配 opcache.jit=1255 与 buffer_size≥128m 启用 jit 进一步提速。
OPcache 不是“缓存页面结果”，而是把 PHP 脚本编译后的字节码（opcode）存进共享内存，后续请求直接复用——跳过词法分析、语法解析和编译全过程。哪怕每次输出不同用户数据，只要代码文件没变，就能省掉这部分开销。实测显示：Laravel/WordPress 类站点开启后，首字节时间（TTFB）普遍下降 30%~60%，CPU 占用峰值可从 85% 降至 32%，100 次请求耗时从 2.8 秒压缩到 0.9 秒，提升幅度达 67.9%。
怎么确认 OPcache 已真正生效
仅看 phpinfo() 显示 “enabled: true” 不够。必须验证两件事：
- 运行 php -m | grep opcache，确认模块已加载；
- 检查 opcache.status() 或访问 phpinfo() 的 OPcache 部分，重点看 opcache.hits / (opcache.hits + opcache.misses) —— 命中率持续高于 95% 才算健康；
- 若命中率长期低于 80%，说明缓存容量不足或文件数超限，需调高 opcache.max_accelerated_files 或 opcache.memory_consumption。
关键参数配置要匹配实际场景
默认配置不适合生产环境，常见组合如下：
- 小站点（如单页 CMS）：memory_consumption=128，max_accelerated_files=10000，revalidate_freq=60；
- 中大型项目（Composer 依赖多）：memory_consumption=256+，max_accelerated_files=20000，interned_strings_buffer=16；
- 开发环境：validate_timestamps=1 + revalidate_freq=0，改代码立刻生效；
- 生产环境（rsync/镜像部署）：validate_timestamps=1 + revalidate_freq=5~60，兼顾性能与自动更新；若用只读文件系统，则 validate_timestamps=0，但发布后必须执行 opcache_reset() 或重启 PHP-FPM。
上线后代码不更新？多数是 OPcache 滞留旧字节码
典型现象：改完 class 名称或新增 use 语句，仍报 Class 'XXX' not found，或逻辑未变。这不是浏览器缓存，也不是服务器缓存，是 OPcache 还在跑旧 opcode。原因通常是：
- validate_timestamps=0 且没手动重置；
- 容器挂载或 NFS 导致文件时间戳异常，OPcache 误判文件未变更；
- 某些 PaaS 平台禁用 opcache_reset()，只能靠重启 PHP-FPM 或用 opcache_invalidate('file.php', true) 单文件刷新。
搭配 JIT 可进一步释放性能潜力
PHP 8.0+ 支持 OPcache JIT 编译，对数学密集型或深度嵌套逻辑提升明显。启用方式：
- 确保 opcache.enable=1；
- 添加：opcache.jit=1255（启用函数内联、循环优化、类型推断）；
- 设置：opcache.jit_buffer_size=256M（JIT 编译所需内存，建议不低于 128M）；
- 注意：JIT 对简单脚本增益有限，但在复杂计算或高频调用场景下，实测执行速度可再提 35% 左右。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
