结论：composer dump-autoload -o 仅对非 PSR-0/PSR-4 的 classmap 路径生效，适用于遗留项目或禁用运行时扫描的场景，但对纯 PSR-4 项目无效，且易因动态类名、未更新快照等导致类加载失败。
直接说结论：用 composer dump-autoload -o 生成的类映射（classmap）只对 psr-0、psr-4 之外的自动加载方式生效，且仅当你的代码里有大量非标准命名空间路径（比如 lib/ 下一堆散装 PHP 文件）时才值得开这个优化。
为什么 dump-autoload -o 有时没效果
Composer 的 -o（optimize）本质是把所有可扫描到的类文件路径，硬编码进 vendor/composer/autoload_classmap.php。但它不会处理以下情况：
-
psr-4映射本身已足够快，-o对这部分不产生额外 classmap 条目 - 如果项目只用了
psr-4（绝大多数现代项目），-o实际上只扫了composer.json里显式声明的classmap字段路径（比如"classmap": ["src/"]） - 某些 IDE 或测试工具会临时写入
vendor/，导致 classmap 文件被覆盖或未更新
composer dump-autoload -o 真正适用的场景
它不是“通用加速开关”，而是为特定结构服务的补丁：
- 遗留项目混用
include/require+ 手动__autoload，且无法重构命名空间 -
composer.json中明确配置了"classmap": ["legacy/", "utils/"]这类非 PSR 路径 - 部署环境禁止运行时文件扫描（如某些无写权限的容器），需要把类位置全部固化
- 你确认过
autoload_classmap.php生成后体积明显变大（几百 KB 起），且get_declared_classes()加载速度确实提升
容易踩的坑：优化后反而报错或失效
常见现象是执行完 dump-autoload -o 后，某些类突然找不到——这不是 bug，而是 classmap 机制本身的限制：
- 动态拼接的类名（如
$class = $prefix . 'Handler'; new $class）不会被 classmap 捕获，必须确保类名字符串字面量可被静态分析到 - 如果某个文件里有多个类，但只用了其中一个，classmap 仍会加载整个文件，可能触发意外副作用（比如提前执行全局代码）
- 修改了
classmap路径下的文件但忘了重新运行dump-autoload -o，旧路径还在 classmap 里，新类就永远进不来 - 在 CI/CD 中用
--no-dev安装后又单独跑dump-autoload -o，会导致 dev-only 的 classmap 路径丢失（比如tests/）
classmap 优化不是银弹，它把“运行时查找”换成“构建时快照”，代价是灵活性和维护成本。真正影响加载性能的，往往不是自动加载器本身，而是 autoloader 前的 I/O（比如 NFS 挂载、低配容器里的磁盘延迟）或者滥用 require_once 链。别为了一个 -o 忽略这些更实际的瓶颈。
