改 Composer 镜像源应优先项目级配置而非全局，因全局配置受 COMPOSER_HOME 变量、项目 repositories 覆盖及 CI 工具限制易失效；推荐在 composer.json 中首位声明国内镜像并保留 packagist.org 作 fallback，CI 中用 composer config --no-interaction --working-dir=. 设置且避免缓存 ~/.composer/。
改 Composer 镜像源能明显提速，但直接改全局配置或项目配置容易出错，尤其在多 PHP 版本、多用户、CI 环境下。
为什么 composer config -g repo.packagist 不一定可靠
这个命令看似一劳永逸，实际会写入 ~/.composer/config.json，但以下情况会失效：
- PHP CLI 使用了非默认的
COMPOSER_HOME环境变量（比如 Docker 容器里） - 项目根目录存在
composer.json且已定义repositories，会覆盖全局镜像 - 某些 CI 工具（如 GitHub Actions 的
php-actions/composer）默认忽略全局配置，只读项目级配置
更稳妥的做法是：优先在项目中显式声明，再辅以环境级兜底。
推荐方案：项目级 composer.json + 镜像源参数
在项目根目录的 composer.json 中添加或修改 repositories 字段，明确指定国内镜像：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
{
"repositories": [
{
"type": "composer",
"url": "https://packagist.phpcomposer.com"
},
{
"type": "packagist",
"url": "https://packagist.org"
}
]
}
注意两点：
- 必须把国内镜像放在第一位，Composer 会按顺序查找包
- 保留原
packagist.org作为 fallback，避免某些私有包或新发布包未同步时失败 - 如果用的是阿里云镜像，URL 是
https://mirrors.aliyun.com/composer/；腾讯云是https://mirrors.cloud.tencent.com/composer/
CI/CD 中避免缓存污染的写法
GitHub Actions 或 GitLab CI 中，composer install 前常加 composer config，但要注意：
- 不要用
-g（全局），应使用--no-interaction --working-dir=.显式作用于当前项目 - 推荐写成一行，防止中间步骤失败导致配置残留：
composer config repositories.packagist composer https://mirrors.aliyun.com/composer/ && composer install - 若 CI 使用缓存（如
actions/cache），确保缓存路径包含vendor/和composer.lock，但不缓存~/.composer/—— 否则不同项目的镜像配置可能互相干扰
验证是否生效的最快方式
执行 composer diagnose 只能告诉你配置语法是否正确，不能确认请求真走镜像。真正有效的验证是：
- 删掉
vendor/和composer.lock - 运行
composer install -vvv（加详细日志） - 搜索输出里的
Downloading https://mirrors.aliyun.com/...或类似 URL，而不是packagist.org - 留意首条下载日志的时间戳，对比改源前后耗时差异（通常快 3–10 倍）
有些镜像（如华为云）会返回 X-Mirror-From: huaweicloud 响应头，用 curl -I 抓一个包的 URL 也能快速确认。
