OPcache未提速主因是缓存未真正生效：opcache.enable=1仅对Web有效，CLI需额外设opcache.enable_cli=1；PHP-FPM与CLI配置文件常不同，须分别确认路径并重启对应服务；memory_consumption过小会导致缓存抖动，建议中大型项目设128～256MB，max_accelerated_files同步调至20000以上；validate_timestamps=0后须配合部署执行opcache_reset()或reload php-fpm。
OPcache 开启后没提速？大概率是缓存根本没生效，或者配置在“假开”状态。
opcache.enable=1 为什么还是不生效？
常见现象是 phpinfo() 显示 OPcache 已加载，但 opcache_get_status()['opcache_enabled'] 返回 false。根本原因不是扩展没装，而是两个开关被关着：
-
opcache.enable控制 Web 请求（PHP-FPM / Apache）是否启用字节码缓存，必须设为1 -
opcache.enable_cli控制命令行（如php artisan、phpunit）是否启用，CLI 场景下默认是0，不设它，opcache_reset()都调不动
更关键的是：PHP-FPM 和 CLI 使用的 php.ini 文件往往不同。运行 php --ini 看 CLI 路径，再在 Web 页面里查 phpinfo() 中 “Loaded Configuration File”，确认两者是否一致。改完必须重启对应服务：systemctl restart php-fpm 或 systemctl restart apache2。
opcache.memory_consumption 设太小会怎样？
默认 64（MB）在 Laravel、Symfony 或 Composer 类多的项目里几乎必满。一旦 opcache_get_status()['memory_usage']['used_memory'] 接近或等于 memory_consumption，就会触发缓存抖动——旧脚本被强制踢出，新请求又得重新编译，CPU 瞬间飙升。
立即学习“PHP免费学习笔记（深入）”；
- 中等项目建议起步
128，大型框架或微服务建议256～512 - 别只看配置值，用
opcache_get_status()['memory_usage']实时观察峰值占用 -
opcache.max_accelerated_files也得同步调高，4000默认值连vendor/里的类都装不下，推荐20000起，Composer 项目可设到100000
validate_timestamps=0 后代码不更新怎么办？
设 opcache.validate_timestamps=0 是生产环境提效最直接的手段，但它会让 PHP 彻底跳过 stat() 系统调用——也就意味着你改了代码，服务器完全不知道。
- 必须配合部署流程：每次上线后执行
opcache_reset()（需确保该函数未被禁用），或systemctl reload php-fpm - 开发环境千万别设为
0；建议用opcache.revalidate_freq=2，改完秒级可见 - 若用 CI/CD 自动部署，把
curl -s http://localhost/opcache-reset.php加进发布后钩子，比手动清更可靠
opcache_compile_file() 适合什么场景？
这个函数不是用来“手动预热”的万能解药。它只编译单个文件并写入共享内存，不解析依赖、不注册类/函数，对 Composer 自动加载器或 require_once 链路无效。
- 真正有用的是预加载（PHP 7.4+ 的
opcache.preload），它能把框架核心类一次性载入，且支持依赖解析 -
opcache_compile_file()仅适用于极少数静态工具脚本，比如 CLI 下长期驻留的守护进程入口 - 误用它还可能造成内存泄漏：反复调用不会自动去重，相同文件会重复占内存
真正卡点不在参数多寡，而在「哪套配置管哪个环境」「改完有没有真生效」「缓存失效策略和部署节奏能不能咬合」——这三个地方一松动，OPcache 就从加速器变成定时延迟器。
