应使用 composer install --no-dev --optimize-autoloader；dump-autoload -o 默认不重建 classmap，仅刷新轻量映射，多数情况下无效，且在 composer 2.x + php 7.4+ 下可能拖慢冷启动。
Composer 的 autoload 优化不是靠“教程”解决的，而是靠 composer dump-autoload 加上正确的配置和使用习惯——不生成映射文件或生成方式不对，ClassLoader 就得每次扫描整个 vendor 目录。
为什么 composer dump-autoload 不生效？
常见现象：执行完命令后 vendor/autoload.php 没变，或者 class_exists() 还是慢，甚至报 Class not found。
- 没加
-o或--optimize参数：默认只重写 PSR-4/PSR-0 映射，不生成classmap；必须显式加composer dump-autoload -o才会扫描所有 PHP 文件建类名索引 - 项目里混用了
psr-4和classmap，但classmap指向了未提交的临时目录或 symlink 路径，导致扫描失败（composer dump-autoload -vvv可看到跳过提示） -
autoload-dev中的路径被误加进生产 classmap，增大体积且无意义；生产环境应只跑composer install --no-dev后再dump-autoload -o
classmap 和 psr-4 到底该用哪个？
不是“越全越好”，而是按场景选：PSR-4 是开发友好型，classmap 是运行时性能型。
- 新项目、有命名空间规范的代码，优先用
psr-4：加载快、可热更、IDE 支持好；composer dump-autoload几乎不耗时 - 遗留代码、无命名空间、全局函数文件（如
functions.php）、或需极致启动速度的 CLI 工具，才把它们加进classmap数组；注意：classmap 一旦生成，改文件名或删文件不会自动失效，必须重新 dump - 别在
classmap里塞vendor/下的包——Composer 自己已为每个包建好映射，重复扫描只会拖慢 dump 过程
如何验证 classmap 是否真起作用？
不能只看命令是否成功，得查生成结果和运行行为。
- 检查
vendor/composer/autoload_classmap.php：文件非空，且包含你预期的类名 → 键是类名，值是绝对路径 - 用
strace -e trace=openat php -r 'new \SomeClass();'（Linux）或dtruss（macOS）观察是否还 open 了大量.php文件；优化后应只打开autoload_classmap.php和目标文件 - 对比
composer dump-autoload -o前后microtime(true)加载同一类的时间差——通常能从 ~10ms 降到 ~0.2ms，但前提是没其他 autoloader 干扰
真正卡点往往不在命令本身，而在 composer.json 里写了不该扫的路径、用了 files 加载方式却忘了它不进 classmap、或者部署时漏掉了 -o。classmap 是静态快照，不是魔法开关。
