最常用有效的Docker镜像加速方式是配置国内镜像源，如阿里云提供的HTTPS加速地址，通过修改/etc/docker/daemon.json的registry-mirrors字段并重启Docker服务实现。
国内用户直接换阿里云镜像，90% 的慢、卡、超时问题当场消失；海外用户优先调大超时、禁用镜像、检查 DNS；CI/CD 和 Docker 环境必须用项目级配置，全局 config -g 基本无效。
composer config -g repo.packagist 为什么总不生效
这条命令写错任意一个字符，Composer 就静默 fallback 到 https://packagist.org，不报错、不提示。最常见失效组合：
-
repos.packagist（多一个s）→ 键名非法，整条配置被忽略 -
composer config -g repo.packagist https://mirrors.aliyun.com/composer/（漏掉composer类型值）→ Composer 2.x 不识别，直连官方源 - URL 末尾缺
/→ 请求变成/composerpackages.json，返回 404，Composer 自动降级 - 没加
-g→ 只改当前项目composer.json，换目录或换用户就失效 - 用
http://协议 → Composer 2.2+ 主动拒绝连接，根本不会发请求
验证是否生效，只看这一行输出：composer config -g repo.packagist。正确结果必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、报错或仍显示 https://packagist.org，说明根本没写进去。
Docker 或 CI 中 composer config -g 失效的真相
多数基础镜像（如 php:8.2-cli）默认不带全局配置目录，composer config -g 会静默失败，后续 composer install 仍走官方源。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
正确做法是项目级配置：
- 进项目根目录后执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加-g） - 该命令自动在
composer.json的repositories字段中添加"packagist"条目，不会清空已有私有源 - 若原
repositories是数组格式（[]），命令会报错；需先手动改为对象格式："repositories": {} - 改完务必删掉
vendor/和composer.lock，再跑composer install，否则旧 lock 文件里的哈希可能和镜像元数据不匹配
不同网络环境下的超时与重试策略
默认 http.timeout 和 process-timeout 都是 300 秒，在弱网或大包场景下极易中断。
- 国内用户（已配镜像）：可保持默认，或微调至
600防偶发抖动 - 海外用户（未配镜像）：必须调大，建议设为
1200或更高：composer config --global http.timeout 1200、composer config --global process-timeout 1200 - CI/CD 流水线：推荐用环境变量临时覆盖，避免污染全局配置：
COMPOSER_HTTP_TIMEOUT=1200 COMPOSER_PROCESS_TIMEOUT=1200 composer install - 始终搭配
composer clear-cache使用——缓存里残留的 404 响应或损坏包会掩盖真实网络问题
镜像不是万能的：哪些卡顿它解决不了
镜像只加速 Downloading 和 Loading package information 阶段，对以下情况完全无效：
-
Resolving dependencies卡住超过 10 秒 → 这是本地依赖图计算耗时，和网络无关；精简require-dev、锁定版本、避免dev-main才是解法 -
Installing vendor/package解压慢 → 是磁盘 I/O 或文件系统瓶颈（尤其 macOS/VirtualBox）；用--prefer-dist、关掉 Xdebug、避免挂载vendor/目录 -
Generating autoload files慢 → 和 autoloader 生成逻辑有关；生产环境加--classmap-authoritative --apcu
真正容易被忽略的是：镜像配置只是起点，不是终点。你看到的“慢”，大概率是多个环节叠加的结果——比如 Docker 里既没配项目级镜像，又挂载了 vendor/ 到宿主机，还开着 Xdebug。这时候单换镜像，效果微乎其微。
