opcache_reset() 返回 false 不代表失败，而是因未满足启用、Web SAPI、权限三前提；它仅重置当前worker进程缓存，CLI默认不生效，需先用opcache_get_status()验证状态。
opcache_reset() 返回 false 就是失败吗
不是。它只在成功时返回 true，失败时静默返回 false，不抛异常、不报错——很多人卡在这一步，以为函数没生效，其实是条件没满足。
必须同时满足三个前提：
-
opcache.enable=1（php.ini 中已启用） - 当前运行环境是 Web SAPI（如 Apache、PHP-FPM），不是 CLI
- 脚本有执行权限（例如未被
disable_functions拦截）
验证方式：先跑 var_dump(opcache_get_status()['opcache_enabled']);，输出 true 才说明 OPcache 真启用了；再确认 php_sapi_name() 是 fpm-fcgi 或 apache2handler，而不是 cli。
为什么在 PHP-FPM 下清了缓存页面还是旧的
因为 opcache_reset() 只清当前 worker 进程的缓存，不是全站重置。FPM 通常有多个子进程，你访问的请求可能落到另一个没被重置的 worker 上。
立即学习“PHP免费学习笔记（深入）”；
临时解决办法（开发/调试用）：
- 加一句
opcache_reset(); die('OPcache reset');写进一个独立 PHP 文件（如/opcache-reset.php），反复刷新几次，提高命中已重置进程的概率 - 改小
opcache.revalidate_freq=0（开发环境），让每次请求都检查文件时间戳，绕过缓存逻辑 - 真正可靠的做法是 reload FPM：
sudo systemctl reload php8.3-fpm（版本号按实际替换）
注意：opcache.validate_timestamps=0 时，即使改了 PHP 文件也不会自动更新，必须手动重置或 reload，这点极易被忽略。
命令行下能用 opcache_reset 吗
默认不能。CLI 模式不加载 OPcache，opcache_reset() 必然返回 false。
除非你在 php.ini 中显式开启：opcache.enable_cli=1，然后才能这样用：
php -r "if (function_exists('opcache_reset')) { var_dump(opcache_reset()); }"
但生产环境几乎从不开启 opcache.enable_cli，因为 CLI 脚本生命周期短，缓存收益低，还增加配置复杂度。别为了图方便开这个选项。
清理前要不要看缓存状态
要，而且应该先看。直接 opcache_reset() 是“暴力清”，但问题可能不在缓存脏，而在配置不合理。
用 opcache_get_status(false) 查关键指标：
-
memory_usage.used_memory占memory_usage.total_memory超过 95%？说明池子太小，该调大opcache.memory_consumption -
opcache_statistics.hits / (hits + misses)命中率低于 80%？可能是脚本太多、缓存时间太短，或opcache.max_accelerated_files不够 -
scripts数量远小于预期？说明很多文件根本没进缓存，检查opcache.restrict_api是否误拦了路径
别把“清缓存”当成万能操作——很多“改了代码不生效”的问题，根源是 OPcache 根本没缓存到那个文件，或者被 opcache.blacklist_filename 排除了。
