OPcache 清除需主动触发而非仅靠配置：启用 opcache.validate_timestamps=1 并设合理 revalidate_freq，部署时用 systemctl reload 平滑重启，单文件更新用 opcache_invalidate，file_cache 需单独清理。
PHP 8 系列（8.0–8.3）中，OPcache 本身不提供自动清除机制，所谓“配置清除缓存”，本质是配置触发条件 + 选择安全清理方式。重点不是“设个参数就自动清”，而是让缓存能被精准识别、按需刷新、不伤服务。
✅ 正确理解：OPcache 清除 ≠ 配置一个开关
-
opcache_reset()是手动调用函数，不是配置项； -
opcache.validate_timestamps=1和opcache.revalidate_freq=N决定是否自动检查更新，但不等于“自动清除”； - 真正的“清除动作”必须由运维或部署流程主动发起。
? 关键配置项（必须检查并设合理值）
这些配置决定了缓存能否响应变更、是否容易清理：
opcache.enable=1
必须开启，否则所有 OPcache 功能无效。opcache.validate_timestamps=1
生产环境也建议设为1（不是0）。设为0意味着“永远不看文件改没改”，代码上线后必须靠reload或opcache_reset()才生效——极易踩坑。opcache.revalidate_freq=60
表示每 60 秒检查一次文件修改时间。开发环境可设为0（每次请求都校验），生产环境60是较稳妥平衡点。opcache.file_cache_only=0（默认）或=1
若启用磁盘缓存（如opcache.file_cache="/path/.opcache"），注意它不会随opcache_reset()删除，必须单独定时清理目录。opcache.max_accelerated_files和opcache.memory_consumption
若缓存池长期 >95% 占用，说明容量不足，频繁驱逐旧脚本——这不是“过期”，是“挤出”，清了也很快又满。应先扩容再清理。
? 清理操作不能只靠配置，要分场景选方法
| 场景 | 推荐方式 | 说明 |
|---|---|---|
| 部署新代码后全量刷新 | sudo systemctl reload php8.x-fpm |
平滑重启所有 worker 进程，最可靠；比 opcache_reset() 有效得多 |
| 只更新单个配置/关键类 | opcache_invalidate('/path/to/config.php', true) |
精准失效，不影响其他脚本，适合热更 |
| 临时调试或验证 | 访问一个含 opcache_reset() 的 PHP 文件（如 /opcache-reset.php） |
注意：只重置当前 worker，多刷几次提高命中率 |
| 启用 file_cache 后目录堆积 | 定时脚本保留最新 2 个时间戳子目录，其余 rm -rf
|
例如 /path/.opcache/20261005142230，命名规则是 YYYYMMDDHHIISS
|
⚠️ 常见误配导致“清不掉”的原因
-
opcache.validate_timestamps=0→ 改了代码也不校验，opcache_reset()成唯一出口，但易遗漏； -
opcache_reset()在 CLI 下执行 → 返回false是正常现象（CLI 默认不加载 OPcache）； - 使用宝塔等面板时，
.user.ini或 FPM pool 配置覆盖了php.ini→ 实际生效值需用php -r "print_r(opcache_get_configuration()['directives']);"查； - 文件缓存目录被多个 PHP 版本共用 → 加载错位字节码，清了也白清。
✅ 部署脚本里建议加的三步保险
# 1. 确保语法正确（避免 reload 失败导致 502） php -l /path/to/app/index.php # 2. 清理旧 file_cache（保留最新 2 个目录） cd /path/.opcache && ls -t | tail -n +3 | xargs -r rm -rf # 3. 平滑重载 FPM sudo systemctl reload php8.3-fpm
不复杂但容易忽略。
