Composer镜像配置失效主因是三要素未同时满足：键名必须为单数repo.packagist、type值必须显式写composer、URL须HTTPS且末尾带/；任一缺失即静默回退官方源，且需执行clear-cache并验证config输出为完整JSON。
Composer安装失败，90%不是网络差或PHP坏，而是镜像没切对、缓存没清、或配置被覆盖——换源本身不难，难在“换对”和“生效”。
composer config -g repo.packagist 为什么总不生效
这条命令静默失败的常见原因有三个，缺一不可：
-
repo.packagist写成repos.packagist（多一个 s），Composer 完全不识别，直接 fallback 到https://packagist.org - 漏掉
composer这个 type 参数，比如写成composer config -g repo.packagist https://mirrors.aliyun.com/composer/，结果只是存了个字符串，不是有效源定义 -
url缺末尾/，例如https://mirrors.aliyun.com/composer→ 实际请求变成/composerpackages.json，返回 404
验证是否真写入：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、报错或只返回 URL 字符串，都说明没成功。
换源后仍卡在 Loading composer repositories
这不是镜像慢，而是根本没走镜像——Composer 还在读旧缓存或旧 composer.lock 中记录的官方地址。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须执行
composer clear-cache，否则元数据缓存仍指向packagist.org - 删掉项目下的
vendor/和composer.lock，再重装；否则composer install会按 lock 文件里已存的 URL 去拉包，跟当前镜像配置无关 - 加
-vvv看真实请求：composer install -vvv | grep -i "mirrors.aliyun"，日志里出现Reading packages.json from cache at /https---mirrors-aliyun-com-composer/才算真正生效
全局配置在宝塔/CI 中失效怎么办
全局配置写在 ~/.composer/config.json，但宝塔「一键部署」、Docker 或 CI 流水线常以 www 或 runner 用户运行，根本读不到 root 的配置。
- 先确认执行用户：
whoami，再查该用户的家目录下是否有.composer/config.json - 若需让
www用户也生效，切换用户再配：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 更稳妥的是项目级配置：进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带-g），它会自动往composer.json的repositories字段安全追加，可提交 Git，不受用户权限影响
项目 composer.json 里已有 repositories 怎么办
别手动编辑 JSON，容易格式错误或误删私有源。Composer 自带合并逻辑：
- 如果
composer.json原本是"repositories": {}（对象），命令会转为数组并插入packagist条目 - 如果原本是
"repositories": []（数组），命令会 append 新项，不破坏原有私有仓库 - 改完后务必运行
composer update --lock，否则composer.lock仍记录旧源地址，下次install还会 fallback
最容易被忽略的一点：换源只是替换元数据和 ZIP 分发节点，它不解决 Resolving dependencies 阶段的性能问题——那和 PHP 版本约束、require-dev 包数量强相关，和镜像无关。
