生产环境 opcache.validate_timestamps 必须设为 0，否则每次请求触发 stat 调用导致延迟飙升、cpu 翻倍；设为 0 后需配合部署时调用 opcache_reset() 或重启 php-fpm 来生效更新。
生产环境 opcache.validate_timestamps 必须设为 0
不关掉时间戳验证，缓存就形同虚设。设为 1 意味着每次请求都可能触发文件系统 stat 调用，尤其在 NFS 或容器挂载卷上，延迟飙升、CPU 占用翻倍。设为 0 后，OPcache 完全跳过文件变更检测，命中率才能稳定在 95%+。
但代价是：代码更新后不会自动生效。必须配合部署流程强制清理：
- 发布时调用
opcache_reset()（需确保该函数未被禁用，且执行用户有权限） - 或重启
php-fpm进程（更彻底，但有短暂请求拒绝风险） - 严禁在 Web 请求中动态修改
opcache.validate_timestamps—— ini_set 不生效，只有 php.ini 生效
memory_consumption 和 max_accelerated_files 怎么定才不浪费也不溢出
opcache.memory_consumption 不是越大越好。设太高会挤占其他进程内存，设太低则频繁淘汰，命中率下跌。建议从 256 起步，再根据 opcache_get_status()['memory_usage']['used_memory'] 实际占用反推：
- 持续高于 80% → 增加
memory_consumption - 长期低于 40% → 可适当下调，释放内存
opcache.max_accelerated_files 必须是质数，且要大于项目真实 PHP 文件数。别信“设 10000 就够”——运行 find /path/to/app -name "*.php" | wc -l 算出准确值，再查 OPcache 内部质数表（如 32531、65407），选第一个比它大的质数。设小了会导致哈希冲突，缓存错乱甚至 cache_full === true 报警。
用 opcache_get_status() 监控命中率的三个关键字段
只看 opcache_get_status()['opcache_statistics']['hits'] 是误导。真正要盯的是：
-
opcache_statistics['hit_rate']：命中率，目标 ≥ 95%；低于 90% 就得查配置或文件数是否不足 -
opcache_statistics['oom_restarts']：内存耗尽重启次数，非零说明memory_consumption严重不足 -
opcache_statistics['cache_full']：布尔值，为true表示缓存已满，新脚本无法进入，必须调高max_accelerated_files
注意：opcache_get_status() 返回数组结构在 PHP 8.0+ 有变动，生产脚本里别直接取 ['memory_usage']['free_memory']，先做 isset 判断。临时调试可直接访问 /opcache-status.php（内容仅含 var_dump(opcache_get_status())），但切勿暴露在公网。
validate_timestamps=0 后，如何安全热更代码
关了时间戳检查，就不能靠“改完自动刷新”蒙混过关。必须把缓存失效变成部署环节的确定性动作：
- CI/CD 流水线末尾加一步：curl -X POST http://localhost/opcache-reset.php（该脚本仅允许本地回环访问，且含简单 token 校验）
- 避免用
opcache_invalidate()逐个清脚本——效率低、易漏、难追踪 - 若用容器部署，可在 entrypoint 中加
sleep 2 && php -r "opcache_reset();"，但注意多 worker 场景下只清了一个进程的 cache
最常被忽略的一点：opcache.preload 文件一旦加载，即使 opcache_reset() 也不会重新加载——preload 是进程启动时一次性行为，更新 preload 脚本必须重启 php-fpm。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
