Composer在PHP-FPM热重启后依然读取旧自动加载文件的解决（缓存清理）-composer-PHP中文网

php-fpm热重启后autoload.php未更新的根源是opcache未清除，而非重启本身问题；即使执行composer dump-autoload或重装vendor，只要opcache仍缓存旧的autoload_classmap.php等文件，类加载就会失效，需显式调用opcache_reset()或重启php-fpm强制清空共享内存中的字节码缓存。

composer在php-fpm热重启后依然读取旧自动加载文件的解决（缓存清理）

PHP-FPM热重启后`autoload.php`没更新？不是重启问题，是OPcache没清

PHP-FPM热重启（如 kill -USR2 或 systemctl reload php-fpm）本身不会清除OPcache，而Composer生成的 vendor/autoload.php 依赖的类映射（尤其是 composer/autoload_classmap.php 和 composer/autoload_psr4.php）一旦被OPcache缓存，就会持续生效。你改了 composer.json、执行了 composer dump-autoload，甚至删了 vendor/ 重装，只要OPcache没刷新，PHP就还在用旧的自动加载逻辑。

常见现象包括：新增类无法找到、旧类仍可实例化、class_exists() 返回 true 但实际文件已删——这些都不是Composer或FPM配置问题，而是OPcache缓存了过期的PHP字节码和文件路径映射。

确认是否启用OPcache：检查 php.ini 中 opcache.enable=1，且 Web SAPI（如 FPM）加载了该配置
不要只清 opcache_reset() —— 它只对当前请求进程有效；FPM子进程各自持有独立OPcache，需全局触发
最稳妥方式是在部署脚本中调用 opcache_reset() 并确保所有worker进程都执行到（例如通过 curl 触发一个专用路由）
临时调试可用 opcache_get_status()['scripts'] 查看 vendor/autoload.php 及其依赖文件的缓存时间戳是否更新

`composer dump-autoload -o` 后仍不生效？检查是否启用了`apcu`类缓存

当项目启用 apcu（如 Laravel 的 APCuCache 或 Doctrine 的 ApcuCache），Composer 的优化自动加载（-o）会把类映射写入 apcu，而非仅靠OPcache。此时即使清了OPcache，apcu 里的 composer-autoload 键可能还存着旧数据。

典型表现：本地CLI下 composer dump-autoload -o 正常，但Web请求里类找不到；php -r "print_r(apcu_fetch('composer-autoload'));" 显示的是老数组。

APCu缓存键名通常为 composer-autoload 或 composer-autoload-<hash></hash>，取决于Composer版本
执行 apcu_clear_cache('user')（需在FPM上下文中运行）可清空全部用户缓存；更精准的做法是 apcu_delete('composer-autoload')
若使用Laravel，php artisan config:clear 不影响autoload，但 php artisan optimize:clear（Laravel 9+）会顺带清理APCu autoload缓存
注意：APCu在FPM中默认启用，但CLI模式下通常关闭，这就是为什么命令行能跑通、Web却报错

CI/CD部署时自动清理失败？别信`composer install --no-cache`

--no-cache 只禁用Composer自身的包下载缓存（~/.composer/cache），对OPcache和APCu完全无效。很多部署脚本误以为加了这个参数就“干净”，结果上线后依然加载旧类。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

真正需要在部署末尾强制执行的是：

opcache_reset()（需PHP >= 7.0，且 opcache.enable_cli=0 不影响FPM）
apcu_clear_cache('user') 或明确删除autoload相关键
如果用Envoy或Capistrano等工具，确保清理命令运行在FPM worker所属的用户和PHP SAPI环境下（比如不能在root下跑 php -r 'opcache_reset();' 却期望www-data进程生效）
某些托管环境（如cPanel、Plesk）限制OPcache控制函数，此时只能重启PHP-FPM服务（systemctl restart php*-fpm）才能彻底清空

如何验证autoload确实更新了？绕过所有缓存直接测

不要依赖 class_exists() 或 new X()，它们受OPcache和APCu双重影响。最可靠的方式是绕过自动加载机制，直接包含并检查文件内容：

php -r "
require 'vendor/autoload.php';
var_dump(\Composer\Autoload\ClassLoader::getRegisteredLoaders());
"

或者更直接地检查生成文件时间戳和内容：

stat vendor/composer/autoload_classmap.php | grep Modify 确认文件已被重写
grep 'YourNewClass' vendor/composer/autoload_classmap.php 看是否已写入
在PHP-FPM中执行 var_dump(include 'vendor/composer/autoload_classmap.php');，观察数组是否含最新类路径
如果返回空数组或不含新类，说明 composer dump-autoload 没成功执行，或执行时工作目录不对（比如在子目录下运行导致 composer.json 未被识别）

真正卡住的地方往往不是“怎么清”，而是“清哪儿”——OPcache、APCu、Composer自身缓存、甚至Nginx FastCGI缓存（极少见但存在），得一层层排除。每次变更后，优先查 opcache_get_status() 和 apcu_fetch() 的输出，比猜更快。