Composer autoloader未生效典型表现为Class not found错误，根源是autoload map未更新；需执行composer dump-autoload刷新映射，尤其在修改composer.json autoload配置、新增PSR-4类或拉取含autoload的模块后。
Composer autoloader没生效的典型表现
运行脚本时抛出 Class not found 错误，但确认类文件存在、命名空间和路径也对得上——大概率不是代码写错了，而是 Composer 的自动加载器压根没把你的类注册进去。常见于：手动新增了类但忘了刷新 autoload，或修改了 composer.json 里的 autoload 配置却没执行重载。
什么时候必须跑 composer dump-autoload
以下情况不执行这句命令，新类就永远进不了 autoload map：
- 在
composer.json中新增了"psr-4"或"classmap"映射（比如加了一行"App\Helpers\": "app/Helpers/"） - 手动创建了符合 PSR-4 规范的新目录/类，但项目还没执行过 autoload 生成
- 从 Git 拉下别人写的扩展模块，里面带 autoload 配置，但你本地没重载
- 改过
vendor/composer/autoload_psr4.php这类文件（不推荐直接改，应改composer.json后再 dump）
dump-autoload 的两个常用参数差异
默认执行 composer dump-autoload 只生成优化后的静态映射，适合生产环境；但开发中常需要更灵活的行为：
-
composer dump-autoload -o：启用 classmap 优化，把所有类路径硬编码进autoload_classmap.php，加载更快，但会忽略动态 require 的文件（比如files类型 autoload） -
composer dump-autoload --no-optimize：强制走 PSR-4/PSR-0 动态解析，适合调试阶段——比如你正在改命名空间但还没稳定，不想被 classmap 缓存卡住 - 如果用了
"files"autoload（如全局 helper 函数），必须加--no-optimize才能生效，否则会被-o忽略
为什么有时 dump-autoload 也不管用？
执行完命令还是报错，别急着怀疑 Composer，先盯住这几个点：
- 检查
composer.json里autoload和autoload-dev是否写反了——测试类误配到主 autoload，或业务类漏在 dev 区 - 确认类文件后缀是
.php，且没有 BOM 头（尤其 Windows 下用记事本保存过） - 如果类在
vendor/下，别自己 dump —— 应该用composer install或composer update，因为 vendor 包的 autoload 由它们控制 - CLI 环境和 Web 环境可能用了不同 PHP 配置，导致
opcache.enable=1时旧 autoload map 被缓存，需重启 PHP-FPM 或清 opcache
autoload 不是魔法，它只是按规则查表。表没更新，自然找不到人。
