jenkins 中 composer config -g 基本无效，因 agent 每次构建均为干净环境且项目级 repositories 会完全屏蔽全局配置；必须在项目根目录动态探测镜像可用性后执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/，并配合挂载 composer_cache_dir 缓存路径才能真正提速。
为什么 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": []→ 全局镜像被静默屏蔽 - 命令漏掉
composer子命令名，或 URL 少末尾/→ 配置写入但无效
必须在 Pipeline 中动态探测并写入项目级镜像
核心逻辑不是“配一次”，而是“每次构建前检查镜像是否可用，再写进项目级配置”。所有操作都在项目根目录下进行，绕过全局配置失效问题。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json探测镜像可用性 - 探测成功后，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g，URL 必须带结尾/） - 务必在
composer install前清理旧产物：rm -rf vendor/ composer.lock，否则 Composer 会沿用 lock 文件里的旧约束
配合缓存路径才能真正提速
镜像源再快，如果缓存路径不对或没挂载，Composer 还是会重下包——默认缓存位置是 ~/.composer/cache，不是项目目录下的临时路径。
- 在 Jenkins 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.lock 提交后还能复用 vendor/
vendor/ 是构建产物，含 PHP 扩展兼容性、autoloader 生成路径等环境强耦合信息。不同 PHP 版本或 opcache.enable=1 等配置下，vendor/ 不可直接复用。
- 每次构建都保留
vendor/看似省事，但 Jenkins agent 用户（如jenkins）和上一次构建者（比如root）不一致时，Permission denied就卡住 -
composer.lock提交了新版本，旧vendor/却没清理，composer install会跳过更新，实际依赖还是旧的 - 哪怕只改一行
composer.json，vendor/也必须重建，缓存失效率极高
真正该复用的是 $HOME/.composer/cache 里的压缩包和 dist hash，这才是稳定、跨项目、无副作用的缓存方式。
