必须严格使用composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/命令，三要素缺一不可：-g（全局）、repo.packagist（单数键名）、composer（type值）及末尾带/的HTTPS URL，否则静默失效。
composer config -g repo.packagist 命令必须带齐三个参数
这条命令不是“大概对就行”，漏掉任意一个都会静默失败，且不报错：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 必须严格包含三部分：
-
-g：表示全局配置，影响所有项目；漏掉就只改当前目录的composer.json，换个项目就失效 -
repo.packagist：键名必须是单数repo，不能写成repos.packagist或mirror——Composer 内部硬编码只识别这个 key，写错会悄悄写进无效字段 -
composer：这是type值，不是可选参数，也不是注释；省略后 Composer 2.0+ 会 fallback 到官方源，等于白配 -
https://mirrors.aliyun.com/composer/：URL 必须用 HTTPS，且末尾必须带/；少斜杠会导致请求路径拼成/composerpackages.json，直接 404
验证是否真的生效，别信命令输出
执行完命令后，别看终端回显“OK”就以为成了。真正判断依据只有这一条：
运行 composer config -g repo.packagist，正确输出应为类似：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
如果返回空、null、报错，或输出里没有 type 和 url 字段，说明没写对。
Windows 用户改完需重启终端才能读到新配置；CI 流水线里若用 sudo composer config -g，可能写进了 root 用户的配置，但构建时用的是普通用户，根本读不到。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
项目级配置比全局更可靠，尤其适合协作
全局看着省事，但实际容易踩坑：
- 某些项目在
composer.json里写了"packagist.org": false或空"repositories"数组，会直接屏蔽全局设置 - 团队协作时，全局配置无法被 Git 跟踪，新人拉代码后行为不一致
- CI 流水线混用不同镜像，可能导致
composer.lockhash 不一致，引发部署失败
推荐做法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）。它会自动在 composer.json 顶层写入 "repositories" 字段，key 固定为 "packagist"，不会覆盖已有私有源——前提是原来 repositories 是对象结构（不是数组）。
换源后卡在 Resolving dependencies？和镜像无关
镜像只加速下载，不解决依赖解析慢的问题。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，基本可以确定是本地环境或 composer.json 写法导致的：
- PHP 版本约束太宽，比如
"php": "^7.4 || ^8.0"，会让 Composer 尝试大量组合 - 大量未锁定版本的 dev 包，如
"monolog/monolog": "dev-main" -
require-dev里塞了太多工具链（phpunit、phpstan、psalm混在一起）
这时候换镜像源毫无作用，得去调 composer.json 或升级 PHP 版本约束。
