PHP需编译时加--enable-opcache，Windows需启用php_opcache.dll；opcache.enable和opcache.enable_cli必须同时设为1；生产环境禁用时间戳校验需配合opcache_reset()或重启服务；无共享内存时应配置opcache.file_cache。
确认 PHP 是否已编译支持 opcache
很多 Linux 发行版的预编译 PHP 包默认启用 opcache，但 Windows 下的官方二进制包（如 windows.php.net 下载的 ZIP 版）默认是禁用的。先运行
php -m | grep opcache，如果没输出，说明模块未加载；再执行
php -i | grep "opcache support"，若显示
opcache support => disabled，大概率是没启用或没编译进去。
常见原因包括：
– 编译 PHP 时未加 --enable-opcache
– Windows 下未在 php.ini 中取消 zend_extension=php_opcache.dll 的注释
– 某些 Docker 镜像（如 php:alpine）需手动 apk add php-opcache 并启用
opcache.enable 和 opcache.enable_cli 必须设为 1
这两个开关是硬性前提，缺一不可。仅开启 opcache.enable=1 不代表 CLI 环境能用（比如 Composer 或 Artisan 命令仍不走缓存），而 opcache.enable_cli=1 默认是 0，必须显式打开才生效。
建议配置项（加到 php.ini 或 opcache.ini）：
– opcache.enable=1
– opcache.enable_cli=1（开发调试时很有用）
– opcache.memory_consumption=128（单位 MB，小站 64–128 足够，大项目建议 256）
– opcache.max_accelerated_files=10000（低于实际文件数会频繁踢出缓存）
– opcache.revalidate_freq=60（秒级检查文件修改，生产环境可设为 0，配合 opcache.validate_timestamps=0 手动清理）
避免 opcache.validate_timestamps=0 导致代码更新不生效
这是线上最常踩的坑：为追求极致性能把 opcache.validate_timestamps=0，结果改完 PHP 文件刷新页面没变化。它会让 OPCache 完全跳过文件时间戳校验，除非手动调用 opcache_reset() 或重启 PHP-FPM / Apache。
更稳妥的做法：
– 开发环境：保持 opcache.validate_timestamps=1 + opcache.revalidate_freq=2
– 生产环境：设 opcache.validate_timestamps=0，但部署流程中必须包含 opcache_reset() 或 systemctl reload php-fpm
– 不要用 opcache_invalidate($file, true) 逐个刷新，开销大且易漏
if (function_exists('opcache_reset')) {
opcache_reset();
}
opcache.file_cache 对容器和无共享内存环境很关键
在某些受限环境（如 Docker 容器、Windows WSL、部分云函数），shm 共享内存可能不可用或不稳定，此时 opcache 会自动降级为文件缓存 —— 但前提是显式配置了 opcache.file_cache 路径，否则直接失效。
配置示例：
– opcache.file_cache=/tmp/op（确保目录存在且 PHP 进程有写权限）
cache
– opcache.file_cache_consistency_checks=1（启用一致性校验，防缓存污染）
– opcache.file_cache_only=0（默认即可，设为 1 则强制只用文件缓存，性能略低）
注意：/tmp 在某些系统（如 systemd-tmpfiles 清理策略下）可能被定时清空，应改用持久路径如 /var/cache/php-opcache
stat() 时间戳行为可能异常，这时候光调大内存也没用。
