Composer autoload 失败时，首要确认 vendor/autoload.php 是否被正确引入；其次检查 composer.json 的 autoload 配置是否规范（如 PSR-4 路径须以 结尾）、执行 dump-autoload 刷新映射，并排除 OPcache 或 IDE 缓存干扰。
composer autoload 失败时，先确认 vendor/autoload.php 是否真被引入
很多“自动加载失败”其实不是 Composer 问题，而是代码压根没 require 到那个文件。比如在 CLI 脚本里忘了写 require __DIR__ . '/vendor/autoload.php';，或者 Web 入口（如 index.php）路径写错导致加载失败。
- 检查报错堆栈里是否出现
Class not found且没有autoload.php相关路径 —— 这大概率是入口没加载 - 用
file_exists(__DIR__ . '/vendor/autoload.php')手动验证路径是否存在，注意相对路径是否因执行位置不同而失效 - Web 环境下，
$_SERVER['DOCUMENT_ROOT']和脚本实际位置可能不一致，别硬写死../vendor/autoload.php
运行 composer dump-autoload 前，先看 composer.json 的 autoload 配置对不对
dump-autoload 不会修复错误配置，只会按当前 composer.json 重新生成映射。常见配错点：路径拼错、命名空间漏斜杠、PSR-4 的目录没加 trailing slash。
- PSR-4 映射必须以
结尾："App\": "src/App/"✅，"App\": "src/App"❌（后者会导致类名解析多一层） -
classmap指向的目录如果含非法文件（如 .DS_Store、空文件、PHP 语法错误文件），dump-autoload会静默跳过，但不报错 —— 可加-v查看详细扫描过程 - 修改了
autoload后，必须运行composer dump-autoload，仅composer install或update不会重刷 autoload（除非锁文件变动触发重装）
composer install 和 composer update 对 autoload 的影响差异
install 是按 composer.lock 安装，只重建 vendor 目录和 autoload；update 会升级包并重写 lock 文件，同时刷新 autoload —— 但如果你只改了本地 composer.json autoload 部分，它不会触发更新逻辑。
- 纯调整自动加载规则？用
composer dump-autoload就够了，别跑update，避免意外升级依赖 - 删了
vendor但保留composer.lock？运行composer install即可恢复 autoload，不用update - 执行后发现新类还是找不到，用
composer show --path确认类是否真在 autoload 映射里（例如composer show --path my/package）
开发中类改动后仍加载旧版本，可能是 opcode 缓存或 IDE 缓存干扰
Composer 生成的 vendor/composer/autoload_classmap.php 是 PHP 文件，但 APCu / OPcache 可能缓存了它的字节码，导致你改了 composer.json 并 dump-autoload 后，PHP 还在用旧映射。
- CLI 下可临时加
php -d opcache.enable=0 -d apc.enabled=0 composer dump-autoload排除缓存干扰 - Web 环境下，重启 PHP-FPM 或清空 OPcache（
opcache_reset()）比反复重跑命令更有效 - IDE（如 PHPStorm）有时会缓存类索引，改完 autoload 后手动触发 “Reload project” 或清缓存
dump-autoload 不是万能刷新键，它只忠于当前 composer.json 的描述。 
