composer dump-autoload 仅刷新类自动加载映射，不安装包或修改依赖；加 -o 生成 classmap 需满足 psr-4 配置、路径与类名严格匹配、单文件单类三个前提；生产环境应使用 composer install --no-dev --optimize-autoloader。
“Class not found”时，composer dump-autoload是第一反应动作
它不装包、不联网、不改 vendor 或 composer.lock，只做一件事：根据当前 composer.json 里的 autoload 配置，重新扫描项目目录，刷新 vendor/composer/autoload_*.php 这几张“类地图”。
- 新增了
app/Models/Post.php却报Class 'App\Models\Post' not found？大概率就是忘了这句 - 改了命名空间（比如从
App\Utils换成App\Support），或挪动了目录结构，也得靠它同步映射 - 执行后可立刻验证：打开
vendor/composer/autoload_psr4.php，搜你的命名空间，看是否已写入数组
composer dump-autoload -o 真正生效的三个前提
加 -o（即 --optimize）不是“一键加速”，它只在满足全部条件时才生成有效的 classmap：
- 项目中必须有明确的
psr-4（或psr-0）配置 —— 纯classmap字段声明的路径也会被扫，但现代项目几乎都靠psr-4 -
psr-4映射路径下的 PHP 文件，类名必须严格匹配路径：比如App\Controller\Home必须定义在src/Controller/Home.php，不能是src/Controllers/HomeController.php - 一个文件里不能定义多个类，或类名是动态拼出来的（如
$class = $prefix . 'Handler'），否则该文件会被classmap跳过
不满足任一条件，-o 仍会执行，但生成的 autoload_classmap.php 会稀疏甚至为空，性能毫无提升。
生产环境怎么用才不算白干
单独跑 composer dump-autoload -o 是半截操作；真正上线该用的是更完整的部署命令：
-
composer install --no-dev --optimize-autoloader—— 推荐首选，它等价于：跳过require-dev、校验composer.lock、自动生成classmap、并启用优化模式 - 如果已安装好依赖，可用
composer dump-autoload -o --no-dev补救，但注意：它不会清理dev包留下的 autoload 条目 - 想彻底禁用运行时回退查找（比如确保 Mock 类不意外加载），可追加
--classmap-authoritative，但前提是项目无 PHPUnit 动态生成类、无 AOP 织入等行为
别在开发机上常开 -o：改一个类就得重 dump，反而拖慢迭代；它属于构建阶段的一次性快照，不是开发开关。
为什么有时候 -o 像没用？常见静默失效点
不是命令坏了，而是你没意识到它的机制本质是“静态快照”：
-
autoload_classmap.php体积没变大？说明没扫到有效类 —— 检查composer.json的autoload.psr-4路径是否指向空目录，或是否漏了"src/": ["src/"]这种显式声明 - 启用了
--classmap-authoritative却报错找不到类？不是命令失败，而是那个类根本没被扫描进 map —— 可能是文件后缀不是.php，或放在了未声明的目录下 - CI/CD 中先
install --no-dev，又单独dump-autoload -o？后者会覆盖前者生成的 classmap，且可能把tests/等 dev-only 路径也清掉
最易忽略的一点：classmap 优势要配合 OPcache 才能真正落地 —— 没开 OPcache，每次请求还得读磁盘加载 autoload_classmap.php，内存查表的优势就废了一半。
