最可靠的恢复方式是执行composer config -g repo.packagist composer https://packagist.org，它在2.0+全版本稳定生效；删配置易踩坑，因--unset仅删字段不还原默认值，且受字段名错误、旧版fallback崩溃、项目级配置覆盖、环境变量干扰及缓存未清等多重因素影响。
直接执行 composer config -g repo.packagist composer https://packagist.org 是最可靠的恢复方式，它不依赖 Composer 版本的 fallback 逻辑，在 2.0+ 全版本（包括易出错的 2.2–2.4）都稳定生效。删配置反而容易踩坑。
为什么 composer config -g --unset repos.packagist 常常失败
这个命令只是删除 JSON 字段，并不“还原默认值”。实际失效原因往往不是命令本身，而是以下几点：
- 字段名写错：
repos.packagist（复数）是旧版遗留写法，新版 Composer 只认repo.packagist（单数），写错不会报错但完全无效 - 旧版 Composer（如 2.2–2.4）在删掉
repos.packagist后，fallback 逻辑可能崩溃，卡在Could not parse version constraint或静默卡住 - 项目级
composer.json里还留着"repositories"块，它优先级高于全局配置，删了全局也白删 - 环境变量
COMPOSER_REPO_PACKAGIST仍存在，会彻底盖掉所有配置
怎么确认当前真正走的是官方源
不能只看命令有没有报错，必须验证两件事：配置已生效、网络请求地址正确。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查当前实际生效的源：
composer config repo.packagist（不加-g），输出应含https://repo.packagist.org，而不是mirrors.aliyun.com等镜像域名 - 看真实请求地址：
composer require monolog/monolog --no-install -vvv，滚动日志里找Downloading https://开头的行，URL 必须是https://repo.packagist.org - 检查缓存是否清空：
ls -la ~/.composer/cache/（Linux/macOS）或dir %APPDATA%\Composer\Cache\（Windows），目录应为空或只剩空子目录
三层覆盖关系必须理清，否则换源等于白换
Composer 查源顺序是固定且严格的：环境变量 > 项目级配置 > 全局配置。哪怕你全局设对了，只要其中一层“盖住”了，就一定不生效。
- 查项目是否自定义源：
grep -A 5 '"repositories"' composer.json（Linux/macOS），或手动打开composer.json搜索repositories - 临时覆盖项目级设置：进项目目录后运行
composer config repo.packagist composer https://packagist.org - 排查环境变量干扰：
env | grep COMPOSER_REPO（Linux/macOS）或echo %COMPOSER_REPO_PACKAGIST%（Windows），有就unset COMPOSER_REPO_PACKAGIST
最容易被忽略的一点是缓存：哪怕配置全对、URL 正确，composer update 仍可能拉错版本、找不到包——因为旧镜像缓存的 packages.json 还在，Composer 会继续读它。不执行 composer clear-cache，前面所有操作都白做。
