升级PHP后需手动清空opcache、APCu及Redis/memcached三类缓存，并验证版本一致性与缓存状态，同时注意PHP 8+兼容性断点及Composer autoload更新。

PHP 版本过低导致缓存行为异常怎么办

PHP 版本过低（比如 7.2 或更低）本身不会“自动清缓存”，但会影响 opcache、apcu、redis 等扩展的行为和配置项支持。升级 PHP 后，旧缓存可能仍被旧进程加载，或新版本因默认配置变化导致缓存未生效、命中率骤降甚至报错。

升级 PHP 后必须手动清空的三类缓存

升级不是一劳永逸——很多缓存不随 PHP 二进制切换而自动失效，需人工干预：

• opcache：PHP 内置字节码缓存，进程级驻留。即使重启 Web 服务，若使用 php-fpm 的静态模式且未 reload，旧 opcache 仍可能运行；升级后建议执行 opcache_reset() 或调用 sudo systemctl reload php*-fpm（注意匹配实际服务名，如 php7.4-fpm）
• APCu：用户数据缓存，进程隔离。PHP 升级后新进程无共享内存段，但旧 php-fpm worker 可能还在用老缓存；执行 apcu_clear_cache() 或重启 php-fpm 才能彻底清空
• 外部缓存（redis/memcached）：不受 PHP 版本直接影响，但应用层代码若依赖低版本序列化格式（如 PHP 7.3 前的 igbinary 兼容性问题），可能读取失败；建议升级后用 redis-cli FLUSHDB 或 flush_all 清空对应库

检查是否真清干净了的两个关键动作

别只信“我 reload 过了”。验证比操作更重要：

Sentinal Redis

监控Redis服务器健康状况、内存、性能及BullMQ队列。检查队列深度、失败任务，分析慢查询并诊断问题。

下载

• 确认当前运行的 PHP 版本与预期一致：php -v 和 phpinfo() 输出要一致；Web 请求中执行 echo PHP_VERSION;，避免 CLI 和 FPM 使用不同版本
• 验证缓存重置是否生效：对 opcache，访问 /opcache-reset.php（内容为 <?php opcache_reset(); ?>）后，再查 opcache_get_status() 中 opcache_enabled 和 memory_usage 是否归零；对 APCu，调用 apcu_cache_info() 查看 num_hits 是否从升级后开始累计

容易被忽略的兼容性断点

PHP 8.0+ 移除了 mysql_*、废弃了 create_function()，部分缓存逻辑若硬编码了这些函数，会在升级后直接 fatal error，导致整个缓存写入流程中断——此时你以为“缓存没清”，其实是“根本没写进去”。尤其注意：

立即学习“PHP免费学习笔记（深入）”；

• 自定义缓存驱动里是否用了 serialize() + unserialize() 处理对象？PHP 8.1+ 对未声明 __unserialize() 的类更严格，可能静默失败
• Composer 自动加载器（vendor/autoload.php）在 PHP 升级后需重新生成：composer dump-autoload --optimize，否则类缓存可能指向旧路径
• .user.ini 或 php_admin_value 中的 opcache.enable=0 类配置，在新版 PHP 中可能被忽略或报 warning，需改用 ini_set('opcache.enable', '1') 或统一在 php.ini 中设置

升级 PHP 后缓存是否真正“焕然一新”，取决于你有没有盯住进程生命周期、扩展初始化时机和序列化边界。多数故障不出在“没清”，而出在“以为清了，其实旧缓存还挂在某个 worker 进程里”。