单纯换 composer 镜像源对 docker 构建速度提升非常有限，因镜像仅加速元数据（packages.json），不加速 zip 包下载；实际包仍直连 github，受 dns、tls 等影响卡顿；必须在 dockerfile 中显式配置 --repository 或 composer config --global，并严格满足键名、type、url 斜杠三要素，同时配合分层缓存与合理参数优化。
单纯换 Composer 镜像源，**对构建速度的提升非常有限，甚至可能没效果**——因为容器内默认不读取宿主机配置，composer install 依然直连 packagist.org 或 github.com，卡在 Downloading https://api.github.com/ 是常态。
镜像源只加速元数据，不加速 zip 包下载
阿里云、腾讯云等镜像只代理 packages.json 和 provider 索引（元数据），但实际 zip 包仍从 github.com 或 codeload.github.com 下载。国内访问 GitHub 极不稳定：DNS 解析慢、TLS 握手超时、连接重置频繁，这才是真瓶颈。
-
composer install -vvv日志里反复出现Downloading https://api.github.com/或https://codeload.github.com/→ 镜像没起作用 - 元数据加载飞快（
mirrors.aliyun.com/composer/），但某个包卡住 30 秒以上 → 八成是 GitHub 直连问题 - 即使
composer config -g repo.packagist显示正确，速度也毫无改善 → 镜像只管元数据，不管 dist 包路径
配置生效必须满足三个硬性条件
90% 的“配了但没用”，都栽在这三处细节上，且不报错、静默失效：
-
repo.packagist不能写成repos.packagist（多一个s就彻底忽略） - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会拼出/p2//类路径，返回 404） - 命令中必须带
composer类型参数：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏掉中间那个composer就白配
验证方式：运行 composer config -g repo.packagist，输出必须是完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或还是 https://packagist.org，说明根本没写进去。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Docker 构建中镜像源必须显式写进流程
宿主机配的 ~/.composer/config.json 在构建阶段完全不可见。容器启动是全新上下文，composer install 默认永远走官方源。
- 推荐做法：
RUN composer install --repository=https://mirrors.aliyun.com/composer/—— 参数直连，语义清晰、可复现、不依赖全局状态 - 次选：
RUN composer config --global repo.packagist composer https://mirrors.aliyun.com/composer/，注意--global在容器内才生效 - 别用
COPY ~/.composer/config.json—— 路径不可靠，且容易覆盖 auth 配置
更重要的是分层缓存：COPY composer.json composer.lock ./ 必须放在 RUN composer install 之前，且越靠前越好；否则任何代码改动都会让整个安装层失效，镜像源再快也没意义。
真正卡顿的环节，镜像根本不管
如果 composer install 卡在 Resolving dependencies，和镜像源完全无关。这是本地 PHP 在做依赖求解，典型诱因有：
-
composer.json里版本约束太宽，比如"php": "*"或"^7.4 || ^8.0 || ^8.1"，导致求解器暴力遍历组合 -
"minimum-stability": "dev"强制拉取 dev 分支，候选版本爆炸增长 -
composer.lock被删或未提交，install实际退化为update - 项目
repositories字段指向了已下线私有源，Composer 逐个超时才 fallback
这类问题只能靠 composer validate --strict + composer config --list | grep repositories 排查，换镜像源毫无帮助。
