OPcache必须通过PHP配置启用，不能靠.env或Artisan命令开启；需确认FPM下php.ini路径、opcache.enable=1、重启服务，并用opcache_get_status()验证命中率与内存使用。
OPcache 不是 Laravel 自己的功能，改 .env 或跑 php artisan 命令根本开不了它——必须动 PHP 配置、确认生效路径、重启服务。配错或漏查，项目照样慢，甚至随机 500。
怎么确认 OPcache 真启用了
别信“装了就开了”。Laravel 项目常跑在 FPM 模式下，而 php -i 默认查的是 CLI 配置，和 Web 请求用的根本不是同一份 php.ini。
- 用
phpinfo()页面看「Loaded Configuration File」路径，再打开那个文件搜opcache.enable - 重点确认三项：
opcache.enable => On、opcache.enable_cli => Off（正常）、opcache.revalidate_freq值是否符合环境（开发建议 2，生产建议 0） - FPM 下验证：写个简单路由返回
opcache_get_status()，看opcache_statistics.hits是否持续增长
memory_consumption 设多少才不爆
默认 64MB 对 Laravel 是严重不足的。中型项目一上线就触发 oom_restarts > 0，缓存频繁清空，TTFB 反而更抖。
- 保守起步设
opcache.memory_consumption=256，大型项目（含 Horizon/Telescope/多包）直接上512 - 别盲目堆到 1024 —— 如果
opcache.hit_rate长期低于 90%，大概率是opcache.validate_timestamps=1导致反复校验，不是内存小 - 压测后查
opcache_get_status()['memory_usage']：若used_memory_human接近total_memory_human，再加；否则先调其他参数
route:cache 和 opcache:compile 能一起用吗
能，但顺序和前提很关键。这两个动作解决不同层级的问题，乱序或忽略约束会报错或失效。
立即学习“PHP免费学习笔记（深入）”；
- 先跑
php artisan route:cache（仅限无闭包路由的项目），再执行php artisan opcache:compile -
opcache:compile依赖opcache.dups_fix=1，否则遇到重复类声明直接失败；没这个配置就加--force - 部署新代码后，必须清 OPcache：
php artisan opcache:clear或调opcache_reset()，光 reload PHP-FPM 不够
预加载（preload）值不值得上
PHP 7.4+ 才支持，对 Laravel 效果明显但有硬门槛：必须用 FPM（不能用 Apache mod_php），且 preload 脚本里不能有动态逻辑（比如 env()）。
- preload.php 必须用绝对路径，且由 PHP 进程启动时一次性
require_once，不能包含任何运行时判断 - 推荐只预加载框架核心和高频 Model/Controller，避免把
storage/logs或临时生成的文件也扫进去 - 改了 preload.php 后，必须
sudo systemctl reload php*-fpm，opcache_reset()完全无效
最易被忽略的一点：OPcache 配置在 FPM 和 CLI 下完全隔离，改完 /etc/php/8.2/fpm/php.ini 后，忘了 reload php8.2-fpm 服务，等于没配。线上出问题时，第一反应不该是 Laravel 日志，而是立刻看 opcache_get_status() 返回的 start_time 和 last_restart_time。
