OPcache 通过缓存编译后的 opcode 提升 php 性能，但需确保 opcache.enable=1 生效、配置针对 Web SAPI、重启服务，并注意 validate_timestamps、内存大小、命中率等关键参数与失效场景。
PHP 开启 Zend OPcache 后，脚本编译后的 opcode 会被缓存到共享内存，避免每次请求都重复解析和编译，对性能提升明显——但前提是它真的在运行且配置得当。很多“开了没效果”的情况，其实是 opcache.enable 没生效，或被 CLI 模式、不同 SAPI 配置干扰。
确认 PHP 是否已编译并加载 Zend OPcache 扩展
OPcache 是 PHP 5.5+ 内置扩展，但默认可能未启用（尤其是某些 linux 发行版的包管理安装版本）。先检查是否已加载：
php -m | grep opcache如果无输出，说明扩展未启用；若输出 opcache，再验证是否实际生效：
php -i | grep "opcache.enable"注意：CLI 和 Web SAPI（如 apache 的 mod_php 或 FPM）可能使用不同的 php.ini，务必确认你改的是当前 Web 环境所用的配置文件。可通过 phpinfo() 页面中的 Loaded Configuration File 行定位准确路径。
立即学习“PHP免费学习笔记（深入）”；
修改 php.ini 启用并调优关键参数
在正确的 php.ini 中添加或修改以下最小必要配置（不建议直接复制整段，应逐项理解）：
; 启用 OPcache（必须设为 1） opcache.enable=1 ; Web 请求下启用（CLI 默认关闭，无需改） opcache.enable_cli=0 ; 内存大小，至少 64M，高流量站点建议 128M 或 256M opcache.memory_consumption=128 ; 最多缓存多少个脚本文件（影响命中率） opcache.max_accelerated_files=10000 ; 开启文件时间戳验证（开发环境可关，生产必须开） opcache.validate_timestamps=1 ; 检查脚本变更的间隔秒数（设为 0 表示每次请求都检查，性能差；生产建议 60–180） opcache.revalidate_freq=60 ; 启用优化（推荐全开） opcache.optimization_level=0xffffffff改完后必须重启 Web 服务（systemctl restart php-fpm 或 systemctl restart apache2），仅 reload 不生效。
常见失效场景与排查要点
即使配置正确，OPcache 也可能“看似开启实则不工作”，典型原因包括：
-
opcache.validate_timestamps=0且未手动opcache_reset()—— 文件更新后永远返回旧代码 - FPM pool 配置中设置了
php_admin_value[opcache.enable] = 0，覆盖了全局配置 - 使用了
require_once动态拼接路径（如require_once $dir.'/file.php'），导致 OPcache 无法静态分析依赖 - 脚本里调用了
eval()或create_function()，这类动态代码不会被缓存 - OPcache 共享内存满（
opcache_get_status()['memory_usage']['used_memory']接近total_memory），旧脚本被强制淘汰
可用 opcache_get_status() 函数在页面中查看实时状态，重点关注 opcache.hit_rate 和 scripts 数量，低于 80% 命中率需进一步分析。
最易被忽略的一点：OPcache 缓存的是编译后的 opcode，不是执行结果。它不替代 redis 或 APCu 这类数据缓存，也不能加速数据库查询或外部 http 请求。它的作用边界非常明确——只管“PHP 文件怎么更快变成可执行指令”。混淆这点，容易误判优化效果。