composer config repo.packagist.org 查的是当前实际生效的镜像地址，优先级为项目级 > 全局配置 > 官方源；返回 URL 即正在使用该镜像，为空或报错则走官方源 https://packagist.org。
composer config -g repo.packagist.org 查的是当前生效源，不是“全局配置文件路径”
很多人以为 composer config -g repo.packagist.org 输出的地址就是“镜像设置在哪”，其实它只告诉你**此刻 Composer 实际请求的源地址**，背后可能是项目级配置、全局配置，甚至没配（走默认）。这个命令不关心你改了哪个文件，只反馈最终行为。
执行后如果返回空或报错 Could not find repository 'packagist.org'，说明没设任何自定义源，正用官方 https://packagist.org；如果返回一个 URL，就代表那个地址正在被实际使用——哪怕你记得自己只在全局配过，也得防着项目里 composer.json 的 repositories 字段悄悄覆盖了它。
-
composer config -g repo.packagist.org查全局配置中是否定义了该源（但可能被项目覆盖） -
composer config repo.packagist.org（不带-g）查当前目录下项目级是否定义了该源 - 两者都为空？那 Composer 就老老实实用内置默认源
全局镜像真正写在哪：~/.composer/config.json 或 %APPDATA%\Composer\config.json
Composer 全局配置文件位置取决于系统和环境变量：COMPOSER_HOME 环境变量优先，否则 Linux/macOS 默认是 ~/.composer/config.json，Windows 是 %APPDATA%\Composer\config.json。注意不是项目根目录下的 composer.json，也不是 /etc/composer/config.json（那个不存在）。
这个文件由 composer config -g 命令自动创建和更新，手动编辑风险高——JSON 格式错一个逗号，所有 composer 命令都会直接报错退出。更麻烦的是权限问题：如果某次用 sudo composer config -g，配置就写进了 root 用户的家目录，而你日常开发用的是普通用户，根本读不到。
- 确认路径：运行
echo $COMPOSER_HOME（Linux/macOS）或echo %COMPOSER_HOME%（Windows） - 检查文件是否存在且可读：
ls -l ~/.composer/config.json或dir %APPDATA%\Composer\config.json - 别用文本编辑器硬改，
composer config -g --unset repo.packagist.org比手删字段安全得多
为什么 composer diagnose 显示 “Repo is default” 却以为自己配成功了
composer diagnose 里出现 Repo is default，意思是 Composer 没检测到任何有效的自定义 repo.packagist.org 配置——不是“没配”，而是“配了但没加载进来”。常见原因有三个：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 配置写进了错误用户的家目录（比如 CI 脚本里用了
sudo，但构建跑在www-data用户下） - URL 少了末尾
/，例如写成https://mirrors.aliyun.com/composer，导致 Composer 请求packages.json时拼出https://mirrors.aliyun.com/composer/packages.json并 404，于是自动降级回官方源 - 镜像地址协议写成
http://，而新版 Composer（2.2+）会静默忽略非 HTTPS 源，不报错也不警告，直接 fallback
验证是否真生效，不能只看 diagnose 或 config -g 输出，得实测：运行 composer show packagist/support -vvv，从日志里找 Downloading https://... 那行，看域名是不是你设的镜像站。
项目级 repositories 一出现，全局镜像就彻底失效
这是最常被忽略的优先级陷阱。只要当前目录下存在 composer.json，且里面含 "repositories" 字段（哪怕只是空数组 [] 或只禁用 packagist：{"packagist.org": false}），Composer 就会完全跳过全局 repo.packagist.org 配置，只按项目里写的来。
很多团队在 CI/CD 流水线或脚手架模板里加了 "repositories": []，本地开发一切正常，一上 CI 就变慢——因为 CI 环境里没配全局镜像，又没法删项目配置。临时解决只能在项目 composer.json 里显式补全镜像：
"repositories": [
{
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
}
]
但这已不属于“全局”范畴，每个项目都得单独维护。真正想靠全局统一管理，就得确保所有项目 composer.json 里不出现 repositories 字段，连注释都不建议留——某些旧版 Composer 会把注释当语法错误。
