根本原因是composer.lock未提交或被忽略，导致install退化为update重新解析依赖；需确保lock文件提交、启用缓存、CI中同时缓存vendor/和~/.composer/cache。

为什么 Composer 会重复下载同一个包？

根本原因不是镜像本身的问题，而是 composer.lock 文件未被提交或被忽略，导致每次 composer install 都重新解析依赖并可能触发重复下载。中文镜像（如阿里云、腾讯云、华为云）只是加速源，不改变依赖解析逻辑。

• composer.lock 缺失或过期时，composer install 退化为 composer update 行为，重新计算版本并下载
• 团队协作中有人删了 vendor/ 但没提交 composer.lock，其他人执行 install 就会重下
• CI/CD 环境未缓存 vendor/ 或 ~/.composer/cache，每次都是干净环境

如何确认当前是否用了中文镜像？

运行 composer config -g repo.packagist，输出应类似：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。若显示 https://packagist.org，说明镜像未生效。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 全局设置镜像：用 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• 项目级设置优先级更高：在项目根目录运行 composer config repo.packagist composer https://mirrors.tencent.com/composer/
• 临时禁用镜像调试：加 --no-cache 或设环境变量 COMPOSER_REPO_PACKAGIST=https://packagist.org

怎样避免重复下载——关键操作清单

镜像只解决「下载慢」，不解决「重复下」。真正止住重复下载，得靠锁文件 + 缓存 + CI 配置三者配合。

• 确保 composer.lock 提交到 Git（不在 .gitignore 中），且每次 composer update 后都 commit 它
• 开发机开启 Composer 缓存：默认已启用，检查 composer config -g cache-dir 路径是否可写
• CI 中复用缓存目录：例如 GitHub Actions 用 actions/cache 缓存 ~/.composer/cache 和 vendor/
• CI 中始终用 composer install --no-interaction --prefer-dist，不用 update

镜像切换后仍重复下载？先查这几个点

换完镜像发现下载量没变少，大概率是底层机制没对上，而不是镜像地址错了。

• 运行 composer install -v，看日志里是否真从镜像域名发起请求（如 mirrors.huaweicloud.com），而非 fallback 到 packagist.org
• 检查是否启用了 fxp/composer-asset-plugin 类插件，它们可能绕过主镜像配置，需单独设 asset-packagist 镜像
• 私有包（如 "repositories": [{"type": "vcs", ...}]）不受 packagist 镜像影响，需单独优化其 clone 速度
• composer clear-cache 后首次 install 会全量下载，这不是 bug，是缓存重建的正常行为

实际项目里，最常被忽略的是 composer.lock 的生命周期管理——它不是“生成一次就完事”，而是必须随依赖变更同步更新、同步提交。镜像只是管道，管好源头（lock 文件）和中间缓存（cache dir），才能让下载真正稳定下来。