直接结论：命令composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/配对即生效，90%失败源于键名拼错（如repos.packagist）、缺失type值composer、URL末尾缺/；静默失效不报错，需验证输出JSON及-vvv日志确认真实请求地址。
直接结论：别折腾代理或改 hosts，composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这条命令配对就生效，90% 的失败不是镜像问题，是 repo.packagist 拼错、composer type 缺失、URL 少了末尾 /。
为什么 composer config -g 总是不生效？
这条命令静默失败，不报错也不提醒，但实际没写进去。常见错误包括：
-
repos.packagist（多一个s）→ 写进无效字段，composer config -g repo.packagist查出来是空 - 漏掉中间的
composer→ Composer 2.0+ 会 fallback 到官方源，你以为换成了，其实没换 - URL 用
http://或结尾没/→ 请求变成https://mirrors.aliyun.com/composerpackages.json，404 - 在 root 下执行，但宝塔/CI 以
www或runner用户运行 → 它读的是自己的~/.composer/config.json，根本看不到你的配置
项目级配置比全局更可靠
尤其适合 Git 协作和 CI 流水线，因为 composer.json 可提交、可复现。操作很简单：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 进项目根目录（有
composer.json的地方） - 运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：去掉-g） - 它会自动往
composer.json的repositories字段里安全追加，key 固定为"packagist" - 如果已有
"repositories": []（数组），命令会报错；得先手动改成"repositories": {}（对象）再运行 - 改完删掉
vendor/和composer.lock，再composer install
验证镜像到底有没有用上
别只信 composer config -g repo.packagist 的输出，它只显示“你写了什么”，不反映“实际发了什么请求”。真正有效的验证方式是：
- 运行
composer show -v | head -n 5 - 看日志里真实出现的 URL：
Downloading https://mirrors.aliyun.com/composer/...→ 成功；packagist.org→ 没生效；phpcomposer.com→ 地址已失效 - 如果卡在
Resolving dependencies阶段几十秒，和镜像无关，是composer.json里 PHP 版本约束太宽、require-dev包太多导致的
最易被忽略的一点：换源后首次安装若报 hash 校验失败，不是镜像问题，是旧 composer.lock 里记录的包 hash 和新镜像元数据不一致——必须删掉 vendor/ 和 composer.lock 重来。
