最常见原因是键名、type值、URL格式三处错误：必须是repo.packagist（单数），type必填composer，URL须以https://开头且末尾带/；任一缺失均静默失效。
composer config -g repo.packagist 命令为什么总不生效
最常见原因是命令写错三个关键点，且 Composer 不报错、只静默失效：键名必须是 repo.packagist（单数，不能多一个 s），composer 是必填的 type 值（不是可选参数），URL 必须以 https:// 开头且末尾带 /。漏掉任意一项，composer config -g repo.packagist 查出来就是空或 null，但你完全意识不到。
常见错误示例：
-
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/→ 多了个s，字段写进去了但 Composer 不认 -
composer config -g repo.packagist https://mirrors.aliyun.com/composer/→ 少了composertype 值，新版直接 fallback 官方源 -
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer→ 缺末尾/，请求路径拼成/composerpackages.json，404 后静默回退
全局配置 vs 项目级配置：哪个更可靠
全局配置看着省事，但实际落地时容易被绕过：CI 流水线用的是 runner 用户，宝塔后台用的是 www 用户，Docker 构建里甚至没有 ~/.composer 目录——这些场景下你配的 repo.packagist 根本读不到。
项目级配置虽然要每个项目执行一次，但优势明显：
- 运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意没-g）会安全写入当前项目的composer.json的repositories字段，且只新增"packagist"子项，不覆盖已有私有源（前提是原repositories是对象，不是数组） -
composer.json可提交 Git，团队成员拉代码后行为一致 - CI 脚本里不用额外处理用户权限或
COMPOSER_HOME路径
如果项目已存在 "repositories": []（数组格式），该命令会失败；需先手动改成 "repositories": {}（空对象）再运行。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
换镜像后还是卡在 “Loading composer repositories”
这不是配置没生效，而是请求根本没发到镜像站——大概率是项目级 repositories 配置覆盖了全局设置，或者 composer.json 里写了 "packagist.org": false 这类禁用语句。
排查步骤：
- 运行
composer config -g repo.packagist和composer config repo.packagist（无-g）分别看输出，确认哪一层在起作用 - 检查
composer.json是否存在"repositories"字段，尤其留意有没有"packagist.org": false或"packagist": false这种彻底关源的写法 - 临时验证镜像是否可达：
curl -I https://mirrors.aliyun.com/composer/packages.json，返回200 OK才算服务正常 - 想跳过所有配置直连镜像？用
composer install -vvv --repository-url=https://mirrors.aliyun.com/composer/，-vvv会打印真实请求地址，一眼看清走的是哪个域名
换源后依赖安装失败或 hash 不匹配
镜像源同步再快也有几秒延迟，而 composer.lock 里的 hash 是按官方源元数据生成的。一旦你换了镜像又没清理旧状态，Composer 会尝试从新源拉包，但校验旧 hash，结果就是 file could not be downloaded 或 hash mismatch。
正确做法很直接：
- 删掉
vendor/目录和composer.lock文件 - 确保镜像配置已生效（用上面方法验证）
- 再跑
composer install，让 Composer 重新解析依赖并生成匹配新源的 lock 文件
别跳过这一步。很多团队 CI 报错，根源就是缓存了旧 lock 文件，又在不同镜像间来回切——hash 对不上，安装必然失败。
