问题本质是opcache缓存旧类定义导致Class not found。解决方法：禁用opcache验证是否为此原因；开发环境设opcache.validate_timestamps=1、revalidate_freq=0、enable_cli=1；部署后执行opcache_reset()或重启服务。
这个问题本质是 opcache 缓存了旧的类定义（比如自动加载映射或已编译的 PHP 文件），而 Composer 的 autoloader 已更新（如执行了 composer install 或 composer update），但 opcache 没有刷新，导致 PHP 找不到新路径下的类，报 Class not found。
确认是否是 opcache 缓存导致
先快速验证：临时禁用 opcache，看问题是否消失。
- 在 php.ini 中注释掉或设
opcache.enable=0，然后重启 Web 服务器（如 Apache）或 PHP-FPM - 或者在 CLI 下运行：
php -d opcache.enable=0 your-script.php - 如果禁用后类能正常加载，基本可确定是 opcache 缓存未同步
让 opcache 自动感知文件变更
关键配置项要设对，尤其在开发环境：
-
opcache.validate_timestamps=1（默认开启，必须为 1） -
opcache.revalidate_freq=0（设为 0 表示每次请求都检查文件修改时间，适合开发） -
opcache.enable_cli=1（CLI 模式也要启用，否则php artisan或composer dump-autoload后 CLI 脚本仍可能出错）
改完记得重启 PHP 服务（FPM/Apache），仅 reload 不一定生效。
手动清除 opcache（应急或部署后）
不依赖重启服务，可编程或命令行清理：
- PHP 脚本中调用：
opcache_reset();（需确保opcache.enable开启且脚本本身没被缓存） - CLI 清除（推荐）：
php -r "opcache_reset();" - Web 端加个简单清理页（仅限内网/开发环境）：
red"; } ?>
避免 autoload.php 被过度缓存
Composer 生成的 vendor/autoload.php 是入口，但它本身很小，真正容易出问题的是它引用的 vendor/composer/autoload_classmap.php 等映射文件——这些文件内容会随依赖变化而重写。
- 确保 opcache 不跳过这些文件（默认不会，但若用了
opcache.blacklist_filename，别把vendor/加进去） - 部署时建议加一步：
composer dump-autoload --optimize（或--classmap-authoritative），减少运行时查找，也降低因映射未更新引发的类缺失风险 - CI/CD 部署脚本末尾加上
php -r "opcache_reset();"，确保新代码立即生效
基本上就这些。核心就是让 opcache 和 Composer 的文件状态保持同步——要么靠自动校验（开发），要么靠主动清理（生产部署）。不复杂但容易忽略。
