composer dump-autoload 仅在新增、移动或重命名类文件后需手动执行，用于更新 PSR-4/classmap 映射；修改类内逻辑无需运行，其核心作用是解决“文件存在但 Class not found”的静态扫描滞后问题。
只在新增、移动或重命名类文件后才需要手动跑 composer dump-autoload；修改已有类内容、改方法逻辑、调用方式，完全不用跑。
Class not found 却文件存在？先看是不是漏了 dump
典型现象：Class 'AppServicesPaymentService' not found，但文件明明在 app/Services/PaymentService.php，命名空间也写对了（namespace AppServices;）。这大概率是因为你刚加完类，Composer 还没“看见”它。
- PSR-4 映射是静态扫描生成的，不是实时监听文件系统
- Laravel 默认用 PSR-4，新增控制器、模型、服务等都属于“新类文件”，必须刷新映射
- 执行
composer dump-autoload后，会更新vendor/composer/autoload_psr4.php和autoload_static.php - 如果用了
php artisan config:cache或路由缓存，dump 之后还得清缓存：php artisan optimize:clear
加 -o 参数真能提速？PHP 7.4+ / Composer 2.x 下多数情况不能
在现代环境里，composer dump-autoload -o 不仅不提速，还可能让冷启动变慢——因为生成的 autoload_classmap.php 是一个几 MB 的全量数组，每次请求都要反序列化，而实际只用到其中不到 5% 的类。
- Composer 2 默认启用
autoload_static.php，它是预编译的轻量静态映射，比 classmap 更快、更省内存 -
-o只对手动注册的非标准路径有效，比如你在composer.json里写了"classmap": ["legacy/utils/"]，这时-o才会扫描并收录那些散落的.php文件 - 纯 PSR-4 项目（Laravel/Symfony 默认结构）加
-o不产生任何 classmap 条目，只是白忙一场 - 验证是否生效：跑完后打开
vendor/composer/autoload_classmap.php，看里面数组是不是空的
--classmap-authoritative 是什么？别乱加
--classmap-authoritative 不是“更高级的 -o”，而是强制关闭所有 fallback 行为：查不到 classmap 就直接报错，不再尝试 PSR-4 拼路径。它只在极少数条件全部满足时才安全。
- 项目里没有
"files"类型 autoload（比如全局 helper 函数文件） - 没混用
classmap声明非标准路径（如插件目录、模板逻辑） - 部署时已加
--no-dev，确保autoload-dev没被错误合并 - 所有类严格符合 PSR-4：命名空间末尾有反斜杠、目录大小写完全一致、文件名首字母大写
- 运行时不会动态生成类（比如 Mock、AOP 织入、测试桩），否则直接
Class not found
生产部署该怎么做？别只盯着 dump-autoload
真正影响 autoload 性能的，从来不是要不要加 -o，而是 autoload 配置本身是否干净、opcache 是否启用、以及 install 时是否走对流程。
- 删掉
composer.json里无用的 autoload 条目："docs/": ["docs/"]、"tests/": ["tests/"]这类配置会让扫描白耗几百个文件 - 避免过宽前缀：
""→"legacy/"是灾难，应改为"Legacy\": "legacy/src/" - 生产构建必须用：
composer install --no-dev --optimize-autoloader --classmap-authoritative - 但前提是 PHP 已开启 opcache（
opcache.enable=1），否则 classmap 的内存优势根本发挥不出来 - 最容易被忽略的是：框架反复
require 'vendor/autoload.php'或自己封装 autoload 加载链，会绕过所有优化
