问题本质是opcache缓存旧类定义导致class not found。解决方法：禁用opcache验证是否为此原因；开发环境设opcache.validate_timestamps=1、revalidate_freq=0、enable_cli=1；部署后执行opcache_reset()或重启服务。
php.ini 中注释掉或设 opcache.enable=0，然后重启 Web 服务器（如 apache）或 php-FPM
php -d opcache.enable=0 your-script.php 让 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 端加个简单清理页（仅限内网/开发环境）：
if (isset($_GET['clear']) && $_GET['clear'] === 'opcache') { opcache_reset(); echo "opcache cleared”; } ?>
避免 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 的文件状态保持同步——要么靠自动校验（开发），要么靠主动清理（生产部署）。不复杂但容易忽略。
以上就是如何解决 Composer 和 opcache 缓存不一致导致的 “Class not found” 问题？的详细内容，更多请关注php中文网其它相关文章！