composer config -g repo.packagist 不生效的根本原因是配置未被正确读取，需同时满足：键名必须为单数 repo.packagist、中间参数必须显式指定 composer（type 值）、url 必须 https 且以 / 结尾；任一缺失即静默回退官方源，且不报错。
不能靠“清缓存”或“删 vendor”解决全局包版本冲突——它根本不是缓存或本地文件问题，而是配置层级、执行主体和仓库优先级三者错位的结果。
为什么 composer config -g 不生效？先查 COMPOSER_HOME 和执行用户
你运行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 后，composer install 仍走 packagist.org，大概率不是命令失败，而是配置写进了错误用户的家目录。
-
composer config --global home输出的路径，必须和当前 PHP 进程实际使用的$HOME一致（比如宝塔用www用户，Docker 里是www-data） -
echo $COMPOSER_HOME看环境变量是否被覆盖；若为空，Composer 默认用$HOME/.composer，但该目录可能属主是root，普通用户无权读写 - CI/CD 或 Docker 中，避免用
sudo composer config -g—— 应在构建阶段以目标用户身份执行
项目级 repositories 字段会静默屏蔽全局镜像
只要 composer.json 里有 "repositories" 字段（哪怕空数组），Composer 就彻底忽略 composer config -g 的设置，直接回退到默认源。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 验证：运行
composer config repositories，看是否输出https://repo.packagist.org；若有，说明项目级配置已接管 - 快速禁用：执行
composer config --unset repositories（注意不加-g） - 如需保留私有源又不想丢全局镜像，别用
-g写整个repositories数组，改用：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（无-g，只追加 packagist 源）
镜像 URL 缺少末尾斜杠 = 白配
写成 https://mirrors.aliyun.com/composer（缺 /）会导致 Composer 拼出 /composerpackages.json，返回 404 后安静切回 packagist.org，不报错、不提示。
- 正确格式必须带 trailing slash 且为 HTTPS：
https://mirrors.aliyun.com/composer/ - 验证方式：
curl -I https://mirrors.aliyun.com/composer/，应返回200 OK或301 Moved Permanently - 旧地址如
https://packagist.phpcomposer.com已停更，必须替换
缓存刷新 ≠ 清掉就完事，得盯住 packages.json
composer clear-cache 不清理 ~/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json，而这个文件决定你能看到哪些版本 —— 它 15 分钟内不过期，就会一直挡着新版本。
- Composer ≥ 2.5：直接跑
composer update --refresh（只删packages.json和provider-*.json，不动 ZIP 包） - Composer ≤ 2.4：手动删子目录：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer - 删完后，务必用
composer show --tree | grep "your-package"确认依赖树里出现的是你期望的新版本，而不是锁在旧composer.lock里的残留
真正卡住的从来不是缓存，而是谁在哪个上下文里写了哪条配置、又由谁去读它 —— 多数“全局冲突”其实压根没走到求解器那步，就在配置加载阶段被绕开了。
