使用 --no-autoloader 时跳过生成 vendor/autoload.php 和 vendor/composer/autoload_*.php 文件，但不影响依赖下载、安装及 lock 文件更新，后续需手动执行 composer dump-autoload。

什么时候需要跳过自动加载器生成

当你在构建阶段（比如 Docker 镜像、CI 打包）只关心依赖下载和锁定，不打算立即运行 PHP 代码时，--no-autoloader 能显著提速并避免因环境不全导致的失败。典型场景是：基础镜像中没装 ext-dom 或 ext-xml，但 composer install 默认会尝试生成 vendor/autoload.php，而这个过程依赖这些扩展——结果报错中断。

它到底跳过了哪些操作

该参数不是“禁用自动加载”，而是跳过两件事：生成 vendor/autoload.php 和 写入 vendor/composer/autoload_*.php 文件。依赖包本身仍被完整下载、解压、安装到 vendor/；composer.lock 和 vendor/composer/installed.json 也照常更新。只是没有可直接 require 的入口文件。

• 后续若需自动加载，必须手动执行 composer dump-autoload
• 不会影响 composer require 或 composer update 的依赖解析逻辑
• autoload-dev 部分同样被跳过，所以 tests/ 下的类也不会进 autoloader

常见错误现象与规避方式

最典型的误用是：加了 --no-autoloader 后，在容器里直接 php index.php 报 Fatal error: Uncaught Error: Class not found。这不是 Composer 没装好，而是你忘了补上 autoload 步骤。

• CI 构建阶段用：composer install --no-autoloader --no-scripts --no-progress
• 运行前准备阶段用：composer dump-autoload --optimize（注意：这步需要完整 PHP 环境）
• 如果项目用了 classmap 或 psr-4，dump-autoload 仍能正常工作，不受之前是否加过 --no-autoloader 影响

和 --no-scripts、--no-plugins 的组合影响

--no-autoloader 本身不干扰脚本或插件执行，但它会让某些依赖于 autoloader 的脚本失效。例如，有些 post-install-cmd 会调用 ClassLoader::addPsr4() 或实例化类——此时即使加了 --no-autoloader，脚本仍可能因找不到类而崩溃。

稳妥做法是组合使用：

composer install --no-autoloader --no-scripts --no-plugins

否则得确认所有 scripts 都不依赖已生成的 autoloader，这点容易被忽略——尤其当团队引入了自定义 Composer 插件时。