opcache.validate_timestamps=0在生产环境必开，因其关闭文件时间戳检查可避免高并发下频繁stat()系统调用导致I/O飙升；代价是需手动调用opcache_reset()或部署脚本清缓存，否则新代码不生效。
OPcache 在高并发 PHP 场景下不是“开了就快”，而是必须配对使用场景、部署模式和代码更新节奏——否则反而会卡住请求或让新代码不生效。
opcache.validate_timestamps=0 为什么在生产环境几乎必开
高并发时，每个请求都去 fstat() 检查 PHP 文件修改时间（opcache.validate_timestamps=1 且 opcache.revalidate_freq > 0）会引发大量系统调用争抢 inode 缓存，I/O 延迟飙升，尤其在 NFS 或容器挂载卷上更明显。
-
opcache.validate_timestamps=0关闭自动校验，所有文件命中缓存后直接执行字节码，无额外系统调用 - 代价是：代码更新后必须手动清空 OPcache，否则用户看到的仍是旧逻辑
- 清空方式不是重启 PHP-FPM，而是调用
opcache_reset()或写个简单脚本访问opcache_get_status()后触发重置
opcache.max_accelerated_files 设错会导致缓存命中率暴跌
这个值不是“越大越好”，它决定 OPcache 内部哈希表大小；设小了，文件名哈希冲突激增，大量脚本反复被踢出缓存，等效于没开。
- 真实生效值取质数集合中「第一个大于设定值」的数：
{223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987} - 别靠猜：进项目根目录运行
find . -name "*.php" | wc -l，结果向上取最近质数（比如 28000 → 32531） - 检查命中率是否健康：
opcache_get_status()['opcache_statistics']['hits'] / (opcache_get_status()['opcache_statistics']['hits'] + opcache_get_status()['opcache_statistics']['misses'])，低于 95% 就该调大
opcache.memory_consumption 和 interned_strings_buffer 不是独立调的
这两个内存池共享同一块共享内存段（由 opcache.memory_consumption 划定），但分配策略不同：前者存字节码，后者存重复字符串（类名、方法名、常量名等）。设得不协调，会导致一方吃光内存，另一方频繁淘汰。
立即学习“PHP免费学习笔记（深入）”；
- 中型 Laravel/Symfony 应用建议起手值：
opcache.memory_consumption=512，opcache.interned_strings_buffer=64 - 如果
opcache_get_status()['interned_strings_usage']['buffer_size']接近opcache.interned_strings_buffer * 1024 * 1024，说明字符串池快满，需同步加大两者 - 注意：
opcache.interned_strings_buffer单位是 MB，但实际占用按字符串数量动态增长，设太小会触发内部 realloc，产生碎片
最易被忽略的是：OPcache 的共享内存段在 PHP-FPM master 进程启动时一次性分配，子进程只读共享。这意味着哪怕你调高了 memory_consumption，若 FPM master 没重启，新配置根本不加载——改完 php.ini 后，必须 systemctl reload php-fpm 或杀掉 master 进程强制重载，不能只 reload nginx。
