composer dump-autoload 是刷新自动加载映射的轻量操作，用于新增类、修改命名空间或调整 PSR-4 路径；加 -o 生成 classmap 提升性能，生产环境应配合 --no-dev 使用；它不解决函数/常量未定义问题，且仅响应 composer.json 中明确定义的 autoload 规则。
“Class not found”时，composer dump-autoload 是第一反应动作
不是重装依赖，也不是改 vendor，而是让 Composer 立刻重新读一遍你的类文件和 composer.json 里的 autoload 配置。只要新增了类、改了命名空间、移动了目录，或调整了 "psr-4" 映射路径，composer dump-autoload 就是让自动加载“认出新文件”的最轻量方式。
- 它不联网、不修改
vendor、不碰composer.lock，只刷新vendor/composer/autoload_*.php这几个映射文件 - 开发中改完
app/Models/User.php却报错Class 'App\Models\User' not found？大概率就是忘了运行这句 - 执行后可立刻验证：打开
vendor/composer/autoload_psr4.php，确认你新加的命名空间是否已写入数组
composer dump-autoload -o 不只是“加个参数”，它改变了类加载机制
默认模式下，Composer 每次加载类都要按 PSR-4 规则拼路径、逐层 is_file() 判断；而加了 -o（即 --optimize）后，它会提前扫描所有可加载类，生成一张完整、静态的 classmap 表——运行时直接查数组，跳过全部磁盘查找。
- 效果明显：Laravel 中型项目框架启动阶段类加载耗时常下降 30%–70%
- 但代价是：生成过程变慢（尤其类多时），
autoload_classmap.php文件体积显著增大 -
开发环境别常开
-o：改一个类就得重新 dump，反而拖慢迭代；它属于部署环节的“一次性优化”
生产环境部署必须组合使用：--optimize --no-dev
单独 -o 不够安全。开发用的测试类、Mock 工具、require-dev 里的包，不该出现在生产自动加载里——它们既增加体积，又可能引发冲突。
- 正确命令是：
composer dump-autoload --optimize --no-dev
- 更推荐在 CI/CD 或部署脚本中统一用：
composer install --no-dev --optimize-autoloader
（等价且更可靠，因它还会校验composer.lock） - 如果想进一步锁死行为，可加
--classmap-authoritative：强制只走 classmap，禁用任何回退查找——但要求项目中无运行时动态生成的类（如 PHPUnit Mock、AOP 织入类），否则直接报错
哪些情况根本不用手动执行？
很多人养成“一出问题就 dump”的习惯，其实多数时候是白忙。
-
composer install和composer update默认都会自动触发dump-autoload，无需重复执行 - 只改了业务逻辑代码（没动命名空间、没新增类、没调
composer.jsonautoload 字段），运行这个命令毫无作用 - 错误提示是
Call to undefined function或Undefined constant？那不是自动加载问题，dump-autoload解决不了
dump-autoload 只响应 composer.json 里明确声明的 autoload 规则**。如果你把类扔进了 src/ 却没在 "psr-4" 里配 "App\\": "src/"，或者用了 classmap 但路径写错了，再 dump 十次也不会生效。 
