使用 –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 插件时。