composer dump-autoload是手动重生成自动加载映射文件的命令，仅在修改autoload配置、新增类或切换Git分支导致映射未同步时才需运行；它不安装包、不联网，只更新vendor/composer/autoload_*.php。
Composer 生成自动加载文件的时机非常明确：它只在你**显式触发安装、更新或重生成操作时才写入 vendor/autoload.php 和相关映射文件**，不会监听文件变化、不自动刷新、也不依赖 OPCache 或文件修改时间。
composer install / update 一定会生成 autoload
每次运行 composer install 或 composer update，Composer 都会强制重新生成全部 autoload 文件（包括 vendor/autoload.php、vendor/composer/autoload_psr4.php、autoload_classmap.php 等）。这是最安全、最常用的触发方式。
- 即使
composer.json的autoload段没改，只要依赖有变（比如新增了 require 的包），autoload 就会重刷 - 如果项目第一次运行
composer install，vendor 目录不存在，autoload 文件必然从零生成 -
composer update --no-dev也会生成 autoload，但会跳过autoload-dev配置部分
composer dump-autoload 是唯一手动重生成方式
当你只改了 composer.json 中的 autoload 配置（比如加了新 PSR-4 前缀、新增 files 路径），或者新增/移动了类文件但没动依赖，就必须手动运行 composer dump-autoload —— 否则 vendor/composer/autoload_psr4.php 里还是旧映射，new MyClass() 必然报错。
- 改了命名空间或类路径后不执行这步，autoload 机制就“看不见”新类
-
composer dump-autoload -o会额外生成autoload_classmap.php，但开发中慎用：它把所有可加载类固化成数组，改一个文件就得重 dump -
composer dump-autoload --no-dev可跳过测试类映射，适合部署脚本
哪些操作完全不会触发 autoload 生成？
这些行为看似和加载有关，但对 autoload 文件毫无影响：
- 仅修改类文件内容（比如改函数体、加注释）→ 映射表不需要更新
- 手动编辑
vendor/composer/autoload_psr4.php→ 下次dump-autoload会被直接覆盖 - 清空 OPCache 或重启 PHP-FPM → 不重建映射，只影响已加载的字节码缓存
- 在 CLI 脚本里漏掉
require 'vendor/autoload.php'→ autoload 根本没注册，和生成与否无关
CI/CD 或部署环境容易忽略的关键点
很多线上部署失败，不是因为代码写错，而是构建流程跳过了 autoload 生成步骤：
- Docker 构建时用了
composer install --no-scripts→ autoload 不会生成（--no-scripts会禁用所有 post-install-cmd 钩子，包括 autoload 写入） - CI 脚本里先
cp -r vendor/再改composer.json→ 新配置永远不会生效，因为没跑dump-autoload - 误以为
composer update --lock会刷新 autoload → 它只更新composer.lock，不碰 vendor 或 autoload
最稳妥的部署命令是：composer install --no-dev --optimize-autoloader，它等价于 install + dump-autoload -o，且跳过 autoload-dev。
