调用 opcache_reset() 可清当前进程 OPcache，但需启用且有权限；PHP-FPM 下仅清单个 worker，CLI 默认不生效；APCu 用 apcu_clear_cache() 清用户缓存，同样具进程局部性；重启前需手动清理 opcache.file_cache 等外部缓存。
PHP 里怎么清空 OPcache 缓存
直接调用 opcache_reset() 就能清空当前进程的 OPcache，但前提是它被启用且当前脚本有执行权限。这个函数不抛错、不返回 false，成功就返回 true，失败静默返回 false——很多人以为没反应其实是权限或配置问题。
- 必须在 Web SAPI（如 Apache 或 FPM）下运行，CLI 模式默认不加载 OPcache，
opcache_reset()在 CLI 下始终返回false - PHP-FPM 场景下，
opcache_reset()只清当前 worker 进程的缓存，不是全站生效；要彻底清空，得重启所有 worker 或触发 FPM reload - 如果启用了
opcache.enable_cli=1，CLI 下也能用，但生产环境极少这么配 - 常见错误现象：
opcache_reset()返回false却没报错，先检查opcache.enable是否为1，再确认当前 SAPI 类型
如何确认 OPcache 当前状态和命中率
靠 opcache_get_status() 查实时数据，比看 phpinfo() 更快更准。它返回数组，关键字段包括 opcache_enabled、memory_usage、opcache_statistics 里的 hits/misses。
-
opcache_get_status(false)只返回汇总信息，轻量；加true会拉取全部脚本缓存详情，可能卡住，别在高并发接口里用 - 命中率低于 80% 值得警惕，但别只盯这一个数——如果
opcache.memory_consumption长期 >95%，说明缓存池太小或脚本太多，该调大或清理无用文件 - 注意
opcache.validate_timestamps=0时，即使改了 PHP 文件也不会自动重载，必须手动opcache_reset()或重启服务
APCu 缓存怎么安全清掉
apcu_clear_cache() 是主力函数，但它分两层：不带参数清用户缓存（apcu_store() 存的），加 'user' 或 'system' 字符串可指定范围；系统缓存（如 APCu 内部结构）一般不用动。
- 开发调试时常用
apcu_clear_cache('user')，但线上别裸写进接口——没鉴权会被人刷崩 - APCu 的 key 是进程级的，PHP-FPM 多 worker 下，每个进程有独立缓存，
apcu_clear_cache()只清当前进程，和 OPcache 一样有“局部性” - 如果用
apcu_bc兼容旧 APC，函数名还是apc_clear_cache()，但行为一致，别混淆 - 错误现象：清完还读到旧值？确认是不是多个进程各自缓了一份，或者用了
apcu_add()（仅当 key 不存在才存）导致没覆盖成功
重启服务前先确认哪些缓存不会自动重建
OPcache 和 APCu 都是进程启动时初始化，重启 PHP-FPM 或 Apache 后会重新加载，但有些缓存依赖外部状态，比如 Redis、Memcached 里的 PHP 序列化数据，或者自定义的文件缓存目录，它们不会因 PHP 重启而刷新。
立即学习“PHP免费学习笔记（深入）”；
- OPcache 的
opcache.file_cache（磁盘二级缓存）目录内容在重启后仍存在，下次启动会优先加载，但若 PHP 版本升级或 opcache 配置变更，可能引发兼容问题，建议上线前手动清空该路径 - APCu 没持久化机制，重启即空，但如果你用
apcu_store()存了大量大对象，重启后首次请求会明显变慢——这是冷启动代价，得接受 - 最容易被忽略的是 Composer 的 autoloader 优化文件（
vendor/autoload_*.php），它和 OPcache 无关，但修改类后不删它，composer dump-autoload --optimize生成的新文件不会自动生效
