composer config -g repo.packagist 命令不生效的根本原因是键名必须为单数repo.packagist、第二个参数必须显式指定为composer（type值）、url必须https且末尾带/，三者缺一即静默回退官方源；验证需输出完整json对象，否则配置失败。
composer config -g repo.packagist 命令不生效？先核对三个硬性条件
这条命令静默失败，几乎全是键名、type值、URL格式写错导致的，不是网络或权限问题。
-
repo.packagist是固定键名，写成repos.packagist（多一个 s）或packagist.org都无效 - 第二个参数必须是
composer，它是 type 值，不能省略，也不能替换成composer.org或其他字符串 - URL 必须用 HTTPS 且末尾带斜杠：
https://mirrors.aliyun.com/composer/✅，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 里记着老 URL。
- 先运行
composer clear-cache清掉元数据缓存 - 删掉项目下的
vendor/和composer.lock - 再执行
composer install -vvv，观察日志里是否出现mirrors.aliyun.com
如果日志里仍是 packagist.org 或请求超时，说明配置根本没生效，回头重查上一步的三个硬性条件。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
团队协作或 CI 环境该用全局配置还是项目级配置？
全局配置（加 -g）只对当前终端用户生效；CI 流水线、宝塔后台、GitHub Actions 默认不读它，直接用会出包 hash 不一致或依赖解析失败。
- 推荐做法：进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 这条命令会安全追加到
composer.json的repositories字段，key 固定为"packagist"，不会覆盖已有私有源 - 改完必须删掉
vendor/和composer.lock，再composer install，否则 lock 文件仍指向旧源
注意：composer.json 中的 repositories 优先级高于全局配置，一旦写死，所有人强制走同一源——跨地域团队或混合网络环境里容易翻车。
宝塔、Docker 或多用户环境里镜像不生效？得切对用户再配
全局配置写在 ~/.composer/config.json，但它只对当前 shell 用户生效。宝塔默认以 www 用户跑 PHP CLI，CI 环境可能用 runner 用户，跟你终端里的用户不是同一个。
- 查实际执行用户：在宝塔计划任务或日志里看 UID，或运行
whoami - 给对应用户配：比如
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - Docker 内部若用非 root 用户，需在 Dockerfile 中指定用户后再运行配置命令
别指望一条命令配完就全环境通用——用户隔离是常态，不是例外。漏掉这步，换源只是给错误的用户加速报错。
