Composer多仓库同步核心逻辑是配置composer.json的repositories数组（私有源置顶、packagist.org显式禁用）和config优化（dist安装、认证、共享缓存），而非依赖脚本；90%场景一条composer install命令即可，仅批量更新或镜像重建等特殊场景需shell协调。
Composer 多仓库同步脚本的核心逻辑是什么？
本质是让 composer install 或 composer update 能同时从多个私有源（如 GitLab、GitHub 私库、自建 Satis）拉取包，而不是只认 packagist.org。关键不在“写脚本”，而在配置好 composer.json 的 repositories 和 config 段，再辅以简单 shell 控制流程。
怎么配 repositories 实现多源并存？
必须用 composer.json 的 repositories 数组显式声明每个私有仓库，顺序影响优先级（靠前的先匹配）。不能只写一个 packagist 类型源来“代理”所有私库——它不支持自动发现私有包。
-
"type": "vcs"：适用于单个 Git 仓库（如https://gitlab.example.com/myorg/my-package.git），Composer 会自动识别composer.json并读取版本 -
"type": "composer"：对接 Satis、Private Packagist 或 Artifactory 的 Composer 仓库服务，适合管理大量私有包，需确保其packages.json已生成且可公开访问 - 避免混用
vcs和composer类型时漏掉"packagist.org": false，否则公共包仍会走官方源，可能因网络或策略失败
拉取慢？这几个配置项必须改
默认 composer install 会逐个 clone 完整 Git 仓库，对含大二进制或历史冗长的私库极其低效。优化重点在跳过完整 clone、复用本地缓存、禁用无谓操作：
- 加
"preferred-install": {"*": "dist"}到config：强制走 zip 包（dist）而非source，前提是私库已配置archive支持（GitLab/GitHub 默认开启） - 设
"github-oauth": {"github.com": "xxx"}或"gitlab-token": {"gitlab.example.com": "yyy"}：避免因未授权被限速或 403 - 加
"cache-dir": "/path/to/shared/cache"：多项目共用缓存目录，dist包和metadata不重复下载 - CI 环境务必加
--no-interaction --no-progress，否则交互提示或进度条可能卡住流水线
同步脚本要不要自己写？什么情况下真需要
90% 场景下，一条带参数的 composer install 就够了；只有当你要做「批量更新多个项目」或「触发私库镜像重建」时，才需要 shell 脚本协调。典型例子：
- 遍历
projects/下所有含composer.json的子目录，统一执行composer update --with-dependencies - 先调
git pull更新私有包仓库本身，再跑composer update myorg/my-package强制刷新依赖 - 用
curl -X POST触发 Satis 构建 API，等返回成功后再执行下游composer install
注意：脚本里别硬编码 token 或密码，一律通过环境变量注入（如 ${GITLAB_TOKEN}），避免泄露到日志或 git 历史。
