如何在Composer中恢复网络默认配置-composer-PHP中文网

composer“恢复默认”本质是清除镜像、代理、dns绑定和缓存，使请求直连https://repo.packagist.org；查源顺序为环境变量＞项目级composer.json＞全局配置＞默认源；需逐层检查并正确清除repo.packagist键、空repositories数组及环境变量，再清缓存、防dns污染。

如何在composer中恢复网络默认配置

Composer 没有“网络默认配置”这个开关，所谓“恢复”，本质是清除所有人为干预的镜像、代理、DNS 绑定和缓存，让请求真正落到 https://repo.packagist.org 上——而它是否能通，取决于你的网络环境是否干净。

确认当前生效的源到底是哪一层在起作用

Composer 查源顺序是：环境变量 > 项目级 composer.json > 全局配置 > 默认官方源。只看 composer config -g repo.packagist 输出，很可能被误导。

运行 composer config -g repo.packagist：若返回非空 JSON，说明全局设了镜像；若报错或为空，不代表没生效
进项目目录后运行 composer config repo.packagist：检查项目级是否覆盖
运行 env | grep COMPOSER_REPO_PACKAGIST（Linux/macOS）或 echo %COMPOSER_REPO_PACKAGIST%（Windows）：环境变量会直接压倒一切
打开项目根目录的 composer.json，搜索 "repositories" 字段：哪怕写成 "repositories": [] 或 "packagist.org": false，也会屏蔽默认源

清除镜像配置必须用对键名和参数

字段名写错就等于白操作——repos.packagist（复数）在 Composer ≥2.0 中已弃用，repo.packagist（单数）才是唯一有效键名；漏掉 composer 类型前缀，配置静默失效。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

强制写入官方源（推荐，比删除更稳）：composer config -g repo.packagist composer https://repo.packagist.org
如果想删掉再 fallback，需两条都跑（兼容旧残留）：composer config -g --unset repo.packagist 和 composer config -g --unset repos.packagist
清项目级镜像：composer config --unset repositories（不加 -g），或手动删掉 composer.json 里的整个 "repositories" 块
Windows 用户若提示权限错误，可能是杀毒软件锁了 %APPDATA%\Roaming\Composer\config.json，需管理员权限运行终端

缓存不清 = 配置白改，且 DNS 污染常被忽略

Composer 会把旧镜像的 packages.json 快照存在缓存里，哪怕你刚重配完，composer update 仍按旧快照找包，导致 Package not found 或版本解析失败。

必须执行：composer clear-cache；验证方式是检查 ~/.composer/cache/repo/（Linux/macOS）或 %APPDATA%\Composer\cache\repo\（Windows）是否为空
DNS 污染是隐形杀手：运行 nslookup repo.packagist.org，正确 IP 应为 151.101.10.217（Fastly CDN）。如果不是，即使配置全清，请求仍会被劫持到错误镜像站
绕过 DNS 污染最稳方式：在 /etc/hosts（Linux/macOS）或 C:\Windows\System32\drivers\etc\hosts（Windows）末尾加一行：151.101.10.217 repo.packagist.org

验证是否真回到官方源，别信配置输出

配置命令不报错 ≠ 请求走对了地址。最可靠的方式是观察真实 HTTP 请求路径。

运行：composer require monolog/monolog --no-install -vvv 2>&1 | grep -i 'GET https'（Linux/macOS），或 Windows 下用 composer require monolog/monolog --no-install -vvv 手动翻日志
正确应看到类似 GET https://repo.packagist.org/packages.json；若出现 mirrors.aliyun.com 或其他域名，说明某层干扰仍在
也可用 composer diagnose -v，末尾会明确打印 “Checking https://repo.packagist.org/packages.json” —— 这是 Composer 自己认定的源

实际中最容易被跳过的点是：项目 composer.json 里那个空的 "repositories": []，以及没清掉的 COMPOSER_REPO_PACKAGIST 环境变量。这两处不处理，其他操作全是徒劳。