composer install本身不支持零停机部署，它只是依赖安装命令；真正实现零停机需在新release目录执行，严格使用--no-dev --optimize-autoloader --no-scripts及COMPOSER_DISABLE_NETWORK=1等参数，确保操作隔离、无网络、无脚本、无 autoload 重建风险。
composer install 本身不支持零停机部署——它只是本地依赖安装命令，运行时既不涉及服务切换，也不控制进程生命周期。真正实现“零停机”，靠的是部署层的原子操作、进程管理或容器编排，composer install 只是其中一环，且必须在不中断服务的前提下安全执行。
为什么直接在 production 目录跑 composer install 会中断服务
常见错误现象：composer install 会重建 vendor/ 目录，期间 autoload.php 可能短暂不可读，PHP 进程（如 PHP-FPM）加载类时触发 Class not found；若同时执行 php artisan migrate，还可能因 schema 不匹配导致请求失败。
根本原因：没有隔离新旧代码环境，所有操作都在同一路径下进行，无回滚能力、无原子性保障。
- Web 服务器（如 Nginx）指向的
current目录被实时修改 -
vendor/重写过程非原子，PHP 的 opcache 或 realpath cache 可能缓存旧路径 - 未禁用网络时，
composer install仍会尝试访问packagist.org，超时拖慢部署
composer install 在零停机流程中的正确位置和参数
它只应在新 release 目录中执行，且必须配合严格参数控制行为：
- 必须加
--no-dev：避免安装开发依赖，减小体积、规避安全风险 - 必须加
--optimize-autoloader（简写-o）：生成静态映射，提升加载性能 - 必须加
--no-scripts：跳过post-install-cmd（如 Laravel 的php artisan config:clear），防止在未切换前误操作线上配置 - 生产环境应设
COMPOSER_DISABLE_NETWORK=1，确保即使 lock 文件有远程 URL 也不会发请求
示例命令：
COMPOSER_DISABLE_NETWORK=1 composer install --no-dev --optimize-autoloader --no-scripts
注意：该命令不重建 autoload，所以后续需手动补 composer dump-autoload -o，但这个动作也必须在新目录完成、且在切换软链之后再触发（或由上线后首个请求触发）。
离线场景下 composer install 容易失败的三个硬坑
很多人把本地 vendor/ 打包传到服务器，然后直接 composer install，结果报错退出——这不是命令用错，而是前提没满足：
-
composer.lock里的dist.url是 GitHub 或 Packagist 的 HTTPS 地址，composer install默认仍会尝试 GET，哪怕vendor/已存在；必须配COMPOSER_DISABLE_NETWORK=1+--no-plugins --no-scripts --no-autoloader -
vendor/composer/installed.json含绝对路径哈希，跨机器复制后会导致 autoloader 失效；上线前应删掉该文件，让dump-autoload重建 -
vendor/bin/下的软链接在 Windows/Linux 间拷贝会损坏，必须删除或用composer bin重生成
真正可靠的离线包，是含完整 vendor/ 的目录 + 清理后的 installed.json + 显式声明的 COMPOSER_DISABLE_NETWORK 环境变量。
关键点不是“怎么用 composer install 实现零停机”，而是“怎么让它不破坏零停机”。所有操作必须落在未上线的目录里，所有副作用（autoload、脚本、网络）必须显式关闭。漏掉任意一个参数或路径，都可能让一次看似平滑的发布变成 30 秒的 500 错误。
