解读

国内一线互联网公司在面试中常把 OPcache 当成“性能试金石”。validate_timestamps 直接决定“文件更新后多久生效”与“每次请求是否要多一次 stat 系统调用”。答得太保守会被质疑性能意识不足；答得太激进又会被追问“上线热更新怎么办”。因此，必须给出“可灰度、可观测、可回滚”的完整方案，而不是简单一句“关”或“开”。

知识点

1. OPcache 原理：PHP 7 以后字节码缓存在共享内存，validate_timestamps=1 时，每次请求都会对比文件 mtime 与缓存时间戳，若不一致则重新编译。
2. stat 调用开销：高并发场景下，哪怕每次节约 0.1 ms，10 w QPS 就是 10 s CPU/秒，可直接换算成机器预算。
3. 国内发布流程：蓝绿、金丝雀、滚动三种模式均要求“代码原子切换”，不允许“旧进程加载新文件”导致 500。
4. 运维可观测：需要把 opcache_hit_rate、opcache_memory_usage、restart_pending 指标落到 Prometheus，方便 SRE 报警。
5. 重启方式：apache graceful、php-fpm USR2、Kubernetes 滚动重建 Pod、Swoole/Worker 热重载，各自对应不同的 timestamp 策略。
6. 安全合规：金融、政务云要求“变更可审计”，直接关 timestamp 必须配套“版本号目录”或“容器镜像”才能过审。

答案

生产环境建议“关”：opcache.validate_timestamps=0。
理由：

1. 国内大厂 90% 以上流量集中在 8 小时窗口，stat 调用带来的 CPU 浪费可直接折算成数百台物理机；
2. 关闭后 OPcache 命中率稳定 99%+，避免突发流量下因大量 recompile 导致 CPU 尖刺；
3. 配合“版本号目录”或“容器镜像”实现原子发布：
   – 蓝绿发布：新代码放到 /data/release/20240618-143052/，切换 nginx upstream；
   – K8s 滚动：镜像 tag 带 GitCommit，Pod 重建即天然重启；
   – php-fpm：USR2 平滑重起 master，老 worker 处理完存量请求后退出，零中断。
4. 灰度观测：上线前 5% 节点保留 validate_timestamps=1，通过 Prometheus 对比 hit_rate 与 RT，确认无异常后全量关闭；
5. 紧急回滚：若发现逻辑错误，直接回滚上游流量或旧镜像，30 秒内完成，无需等待 opcache 失效。

拓展思考

1. 如果业务是 SaaS 多租户、需要“单租户热更新”，可拆分为“租户维度路由 + 独立 OPcache 共享内存池”，用 validate_timestamps=1 仅对实验租户生效，避免影响全局性能。
2. 在边缘节点（CDN 回源机）内存紧张时，可开启 validate_timestamps=1 但把 revalidate_freq 调到 300 s，兼顾“低内存占用”与“偶尔更新”场景。
3. 使用 Swoole RoadRunner 等常驻进程时，opcode 缓存在 Worker 内部，关闭 timestamp 后需自定义 reload 信号，或结合 inotify 手动 opcache_invalidate，避免“代码不生效”尴尬。