Deployer实现集群部署需配合Composer，但Composer仅负责单机依赖安装；真正调度靠Deployer等工具，其deploy.php中须用run()封装命令、显式切换目录、指定PHP路径，并加--no-dev等参数确保生产环境效率。
Composer 本身不支持集群部署，它只管单机依赖安装；真正实现集群自动化，必须靠 Deployer、Ansible 或 Docker Compose 这类工具来调度，而 Composer 只能在其中某个节点上执行 composer install 这类动作。
Deployer 中调用 Composer 的实际写法和坑点
Deployer 的 deploy.php 文件里不能直接写 shell 命令字符串，得用 run() 封装，并注意路径和权限：
-
cd('{{release_path}}')必须显式切换目录，否则composer install会失败（找不到composer.json） - 推荐用
{{bin/php}}和本地composer.phar，避免远程下载慢或失败；如果服务器没预装，加一行run('curl -sS https://getcomposer.org/installer | php')再执行 -
--no-dev --optimize-autoloader是生产环境刚需，漏掉会导致 autoload 效率低、内存溢出 - 别在
task('deploy:composer')里用sudo—— Deployer 默认以非 root 用户 SSH 登录，应提前配好用户对vendor/目录的写权限
Ansible playbook 调用 PHP 脚本时如何安全集成 Composer 逻辑
Ansible 不直接运行 Composer，但可通过 shell 模块在远程主机上触发 Composer 命令。关键不是“能不能跑”，而是“在哪跑、用谁跑、跑几次”：
- 用
become: yes切换到应用用户（如www-data），而不是 root，防止 vendor 权限混乱 - 加
args: chdir: /var/www/myapp明确工作目录，否则composer install会报No composer.json found - 加上
creates: "{{ release_path }}/vendor/autoload.php"实现幂等：若 vendor 已存在，跳过重装 - 集群中多个节点执行时，建议加
serial: 2控制并发数，避免同时拉取 Packagist 导致限流或超时
Docker Compose 部署 PHP 服务时，Composer 应该放在哪一步？
容器化场景下，composer install 必须在构建镜像阶段完成，而非容器启动时。运行时再装等于放弃一致性：
- Dockerfile 中用
RUN composer install --no-dev --optimize-autoloader，不是CMD ["composer install"]—— 后者每次重启都重装，浪费时间还可能失败 - 不要把
vendor/单独挂载为 volume，否则本地修改会覆盖镜像内已优化的 autoloader - 多服务共用同一套依赖？用
build: { context: ., dockerfile: Dockerfile.php }+depends_on确保顺序，但别指望 Compose 自动帮你同步不同服务的composer.lock - CI 构建时可加
--cache-from复用 vendor 层，提速明显；但注意composer.lock变更后必须清缓存层，否则装错版本
最常被忽略的一点：所有工具调用 Composer，都默认走 Packagist 官方源。国内集群部署务必在 composer.json 顶层加 "repositories" 切换为腾讯云或阿里云镜像源，否则几十台机器并发请求会集体卡在 DNS 解析或连接超时。
