最准的确认方式是执行composer config -g repo.packagist，它直接读取全局配置文件，输出URL即生效镜像，为空则走内置默认源https://repo.packagist.org/；config -l不显示该键属正常，因默认源由代码硬编码兜底而非配置项。
Composer 没有“出厂设置”概念，所谓默认行为是代码逻辑对缺失配置的兜底处理，不是预设的可导出配置。 你执行 composer config --list --global 看不到 repos.packagist.org，不代表它不存在——它只是没被显式写入配置文件，而是在运行时由 Composer 内部硬编码启用。
为什么看不到默认镜像配置项
Composer 启动时会检查全局或项目级 config.json 中是否存在 repositories.packagist.org（简写为 repos.packagist.org）。如果完全没设，它就直接使用内置逻辑：{"type": "composer", "url": "https://repo.packagist.org/"}。这个值不会出现在 config --list 输出里，也不存于任何 JSON 文件中。
- 执行
composer config --global --list | grep packagist返回空，是正常现象 - 执行
composer config --global repos.packagist.org报错 “Key does not exist”，也说明该键未被写入 - 但只要没手动禁用（如设为
false），https://repo.packagist.org/就始终生效
哪些配置删了真能“恢复默认”，哪些不能
不是所有 --unset 都等于“还原出厂”。是否恢复取决于 Composer 源码中对该字段是否有隐式 fallback 逻辑：
-
secure-http：unset 后自动 fallback 到true（强制 HTTPS） -
repo.packagist.org：unset 后自动 fallback 到官方源https://repo.packagist.org/ -
minimum-stability：unset 后无默认值，后续require可能直接失败，必须手动补composer config --global minimum-stability stable -
process-timeout：unset 后不恢复 300 秒，而是继承 shell 的超时行为，甚至可能无限挂起
验证默认行为是否被干扰的实操方法
别信配置输出，要看真实网络请求。新建空目录后运行：
composer init -n && composer require monolog/monolog --no-install -vvv | grep "GET https"
观察终端输出的 URL：
- 看到
GET https://repo.packagist.org/packages.json→ 默认源在工作 - 看到
GET https://mirrors.aliyun.com/composer/packages.json→ 镜像已生效 - 看到
Could not resolve host: repo.packagist.org→ 不是配置问题，是 DNS 或代理拦截
注意：项目级 composer.json 中的 repositories 会完全覆盖全局设置，哪怕只加了一行 "packagist": false，也会让默认源失效。
彻底清空并重建全局配置的边界条件
想“重置一切”？composer config --global --unset 不够用。真正清空需两步：
- 删掉
~/.composer/config.json（Linux/macOS）或%APPDATA%\Composer\config.json（Windows） - 再执行任意一条
composer config --global命令（如composer config --global github-oauth.github.com ""），触发 Composer 自动生成最小骨架文件
此时生成的 config.json 里只有 {} 或极简结构，所有字段都靠运行时逻辑兜底——这才是最接近“默认状态”的时刻。但请记住：这个状态本身不可导出、不可备份、也不代表稳定可用，尤其当网络策略或企业防火墙介入时，https://repo.packagist.org/ 可能根本连不通。
