jenkins中必须动态配置镜像源而非依赖全局配置，因agent环境不持久且项目级repositories会屏蔽全局设置；正确做法是pipeline中用--repository-url参数指定阿里云镜像，并配合cache复用vendor、-vvv验证请求域名。
直接用默认 Packagist 源在 Jenkins 里跑 composer install，大概率会超时或失败——尤其在国内网络环境下。必须显式配置中文镜像源，且不能只改本地 ~/.composer/config.json，因为 Jenkins 的构建环境通常是干净容器或新 workspace，每次都要重新生效。
为什么Jenkins里composer install总卡住或报404
根本原因不是 Composer 本身慢，而是它默认从 https://packagist.org 拉包，该域名在国内 DNS 解析不稳定、TLS 握手常失败、CDN 节点响应差。CI 构建超时（比如 Jenkins 默认 10 分钟）后直接中断，vendor 目录不完整，后续步骤全崩。
- 现象：日志里反复出现
Connection timed out或Failed to decode response: zlib_decode(): data error - 场景：Dockerized Jenkins agent、Kubernetes Pod、或裸机 Jenkins slave 启动新 shell 时
- 关键点：Jenkins 不继承宿主机的
~/.composer/config.json，每个构建都是“全新用户上下文”
在Jenkins Pipeline中安全设置阿里云镜像源
不能用 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这种全局命令——它写入的是 agent 容器内的 /home/jenkins/.composer/config.json，但下次构建可能换节点，且存在权限和缓存污染风险。应直接在命令行注入镜像源参数。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 推荐写法：
composer install --repository-url=https://mirrors.aliyun.com/composer/ --no-scripts --no-dev --prefer-dist --optimize-autoloader - 如果项目依赖私有包，且私有源也走国内镜像（如 GitLab 私仓），需额外加
--repository-url多次，但注意顺序：Composer 只认最后一个--repository-url，所以私有源必须放最后 - 避免用
composer config修改文件，因为 Jenkins agent 用户可能无权写~/.composer，或目录不存在，报错Could not find package ... - 若必须用 config（例如要同时配 auth.json），请用
composer config --global repo.packagist composer https://mirrors.aliyun.com/composer/并确保HOME环境变量已设为可写路径
配合cache指令避免重复下载同一镜像包
即使用了阿里云镜像，composer install 仍会逐个请求包元数据（packages.json）、校验 hash、解压。频繁重装 vendor 耗时依旧明显。Jenkins 的 cache 指令能复用上一次的 vendor 目录，但前提是 composer.lock 未变且镜像源一致。
- 正确 cache 写法：
cache(key: 'composer-vendor-${hash('composer.lock')}', paths: ['vendor']) - 必须搭配
--prefer-dist：否则 Composer 默认拉 git source，每次都要 clone，无法利用 cache - 镜像源变更会导致 hash 不一致（哪怕 lock 文件没动），所以一旦切过镜像源，旧 cache 就失效——这是容易被忽略的隐性成本
- 不要 cache
~/.composer/cache：Jenkins agent 生命周期短，该目录几乎没复用价值；反而vendor是构建产物，复用率高
验证镜像是否真正生效的检查点
光看命令执行成功不够，得确认实际流量走的是镜像站。最简单方式是加 -vvv 参数抓请求日志，但 CI 日志太长易淹没。更可靠的是检查 vendor 下包的 dist URL。
- 构建完成后，在 Jenkins 控制台日志里搜
Downloading https://mirrors.aliyun.com，应有若干条匹配 - 进构建 workspace 执行：
grep -r "dist.url" vendor/composer/installed.json | head -3，输出应含mirrors.aliyun.com而非packagist.org - 如果看到
github.com或gitlab.com的原始 URL，说明某些包没走镜像——这是正常现象（镜像站只同步 packagist 官方索引，不代理 git 源），但不影响主体速度 - 注意：PHP 8.5.5 等新版 PHP 对 TLS 1.3 支持更严格，部分老旧镜像站（如某些高校源）可能握手失败，阿里云和腾讯云镜像是目前最稳的两个选择
