jenkins中composer config -g无效，因agent每次构建均为全新环境且项目级repositories字段会完全屏蔽全局配置；必须每次构建前用curl探测镜像可用性，并在项目根目录执行composer config repo.packagist composer $mirror_url/（不加-g）、清理vendor/和composer.lock以确保生效。
为什么 composer config -g 在 Jenkins 里写了也白写
因为 Jenkins agent（尤其是 Docker 或临时节点）每次构建都是全新环境，~/.composer/config.json 写进去就丢了；更关键的是，只要项目根目录的 composer.json 里有 repositories 字段，全局配置就会被完全忽略——连 fallback 都不触发，Composer 直接走你项目里写的源。
常见现象：Pipeline 里执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，日志显示成功，但 composer install 依然卡在 Resolving dependencies 或持续连接 packagist.org。
- agent 容器没挂载
$HOME/.composer→ 配置不持久 -
composer.json含"repositories": []→ 全局镜像被静默屏蔽 - 命令漏掉
composertype 参数，或 URL 少末尾/→ 配置写入但无效
必须每次构建前动态写入项目级镜像
核心逻辑不是“配一次”，而是“每次构建前检查镜像是否可用，再写进项目级配置”。所有操作都在项目根目录下进行，绕过全局配置失效问题。
先用 curl 探活：
sh'curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json'
若返回非 200，fallback 到 https://packagist.org，并确保 "packagist.org": true（不是 false）。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行
composer config repo.packagist composer $MIRROR_URL/—— 注意不加-g，且 URL 必须带结尾/ - 删掉
vendor/和composer.lock，否则 Composer 会沿用旧 lock 文件里的 dist URL，导致校验失败 - 不要用
composer config --unset repositories，它会清空整个字段，私有源直接失效
保留私有仓库时怎么安全写入镜像
项目原本用了私有 Git 包（如 "my-vcs": {"type": "vcs", "url": "https://git.internal/pkg"}），直接运行 composer config repo.packagist 会全量替换 repositories 数组，导致私有包无法解析。
正确做法是手动编辑 composer.json，把镜像源作为 repositories 数组第一个元素，私有源跟在后面，并显式加 {"packagist.org": false} 作为独立对象（和 repositories 同级）：
{
"packagist.org": false,
"repositories": [
{
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
},
{
"type": "vcs",
"url": "https://git.internal/pkg"
}
]
}
-
"packagist.org": false必须写在根节点，不是repositories里面；漏掉这行，Composer 仍会 fallback 到官方源 -
"packagist"是固定 key 名，不能改成"aliyun"或其他名字，否则镜像逻辑不触发 - 如果原
repositories是数组格式（[]），先手动改成对象（{}），否则composer config命令会报错
缓存路径不对，镜像再快也没用
镜像源再快，如果缓存路径不对或没挂载，Composer 还是会重下包——而且默认缓存位置是 ~/.composer/cache，不是项目目录下的临时路径。
真正该复用的是 $HOME/.composer/cache 里的压缩包和 dist hash，这才是稳定、跨项目、无副作用的缓存方式。
- 在 agent 启动脚本（systemd service 或 Docker entrypoint）里固化环境变量：
export COMPOSER_CACHE_DIR=/var/lib/jenkins/composer-cache - 手动创建并授权：
sudo mkdir -p /var/lib/jenkins/composer-cache && sudo chown jenkins:jenkins /var/lib/jenkins/composer-cache - 若用 Docker agent，在
agent { docker { args '-v /var/lib/jenkins/composer-cache:/home/jenkins/.composer/cache' } }中挂载 - Pipeline 中无需额外命令，只要调用
/opt/composer/bin/composer install或php composer.phar install就自动命中缓存
别信 composer config -g repo.packagist：Docker agent 每次重启，~/.composer/config.json 就丢，且会被项目级 repositories 字段静默屏蔽。验证是否真生效，唯一可靠方式是加 -vvv 并盯日志里的 HTTP 请求域名——看到 mirrors.aliyun.com 才算到位。
