换镜像源本身不提升带宽，但能绕过物理链路瓶颈，让实际下载速率逼近本地带宽上限；关键在选对源、配对参数、清旧缓存。
换镜像源本身不提升带宽，但能绕过物理链路瓶颈，让实际下载速率逼近你本地带宽上限；关键在选对源、配对参数、清旧缓存。
为什么改镜像后速度还是上不去
常见现象是执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，但 composer install 仍卡在 Downloading 或只有几百 KB/s。这不是镜像没生效，而是请求根本没走到镜像站。
- 本地 DNS 缓存未刷新，
curl -I https://mirrors.aliyun.com/composer/packages.json返回超时或 503，说明网络层就断了 - 项目
composer.json里有repositories字段但没加"packagist.org": false，Composer 会 fallback 到官方源拉 provider 元数据 - 缓存未清，
composer clear-cache必须跟在换源后立即执行，否则 Composer 还在用旧的packages.json索引 - 用了已停更的源（如
https://packagist.phpcomposer.com），现在返回 404，但 Composer 不报错，只默默重试直到超时
parallel-downloads 并发数怎么设才不翻车
这个参数只对 composer install 有效，本质是控制同时发起多少个 dist 包的 HTTP 下载请求。设太高反而触发镜像限流或本地临时文件竞争。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Composer 2.2+ 默认值是 5，基本等于没开；实测设为
10或15是多数场景的甜点值 - 设成 20+ 容易出现
file_put_contents(/tmp/): failed to open stream，尤其在 Docker 或低配 CI 环境 - 阿里云/腾讯云镜像支持 HTTP/2 多路复用，
15能压满千兆宽带；华为云镜像建议用10，避免偶发 503 - 验证是否生效：加
-vvv运行composer install，日志里会看到类似Downloading https://mirrors.aliyun.com/composer/dists/... (15 concurrent)
哪些操作会让镜像“失效”
不是所有包都会走你配置的镜像源。以下情况会强制绕过 repo.packagist：
- 包的
composer.json显式声明了repositories（比如私有 Git 地址），且未设置"packagist.org": false - 使用
path类型仓库（如"type": "path", "url": "../my-local-package"） - 依赖中包含已废弃（
abandoned）的包，Composer 会尝试从原始源拉元数据做兼容处理 - 新发布的包尚未同步到镜像（通常延迟 5–30 分钟），此时
composer show vendor/package -vvv会显示请求发往repo.packagist.org
生产环境必须加的两个参数
--prefer-dist 和 --no-dev 不是可选项，它们直接决定你能否用满镜像带宽：
-
--prefer-dist强制走 ZIP 包而非 Git clone，跳过 SSH 认证、分支解析、子模块等耗时操作；国内镜像的 dist 包 CDN 节点比 Git 服务器稳定得多 -
--no-dev跳过require-dev中所有包（如phpunit、phpstan），省掉 30–60% 的下载量和解压时间 - CI/CD 中建议组合使用：
composer install --no-dev --prefer-dist --optimize-autoloader - 注意：
--classmap-authoritative会禁用 PSR-4 动态扫描，本地开发慎用，否则新增类直接Class not found
真正卡住安装速度的，从来不是带宽本身，而是元数据请求失败后反复重试、dist 包下载串行排队、以及 dev 包无谓拉取。镜像只是入口，后面每一步都得对齐，才能把“理论上很快”的速度变成终端上真实跑出来的秒级响应。
