Composer还原官方源必须满足：composer config -g repo.packagist输出为{"type":"composer","url":"https://packagist.org/"}（type不可缺、url须HTTPS且以/结尾、格式为合法JSON）；composer diagnose中Repo packagist.org行必须完全匹配；composer require -vvv日志需出现packagist.org域名请求。
composer config -g repo.packagist 输出必须是官方源完整 JSON
还原后第一眼就该看这个命令的输出，不是“有没有报错”，而是它**是否返回了合法的官方源结构**。运行：
composer config -g repo.packagist
正确生效的表现只能是：
{"type":"composer","url":"https://packagist.org/"}
注意三点：type 字段不能丢、url 必须是 https://packagist.org/（结尾斜杠不能少）、整个内容必须是合法 JSON（双引号、逗号、花括号齐全）。任何偏差——比如输出 "https://packagist.org"（纯字符串）、null、空行、或漏掉斜杠——都代表还原失败，Composer 会静默 fallback 到默认行为，但你根本收不到提示。
composer diagnose 中 Repo packagist.org 行必须匹配
composer diagnose 不只是检查环境，它会主动解析当前实际使用的源地址。重点盯住这行输出：
Repo packagist.org: https://packagist.org/
这个 URL 必须和 composer config -g repo.packagist 的 url 值**完全一致**（协议、域名、结尾斜杠缺一不可）。如果这里还是镜像地址，说明还原被更高优先级配置覆盖了，常见原因包括：
- 项目根目录
composer.json里存在"repositories"字段，且没删干净 - 环境变量
COMPOSER_REPO_PACKAGIST仍被设为镜像地址（Linux/macOS 运行echo $COMPOSER_REPO_PACKAGIST，Windows 运行echo %COMPOSER_REPO_PACKAGIST%） - CI/CD runner 用户（如
www-data）家目录下的~/.composer/config.json没同步更新
composer require -vvv 日志里得出现 packagist.org 域名
配置写了 ≠ 请求真发出去了。最终验证必须落到网络请求上。执行：
composer clear-cache && composer require monolog/monolog -vvv 2>&1 | grep "GET https"
日志中应反复出现类似这样的行：
Downloading https://packagist.org/packages.json
或
Downloading https://repo.packagist.org/p2/monolog/monolog.json
如果看到 mirrors.aliyun.com、mirrors.cloud.tencent.com 等任意镜像域名，说明还原没起作用。此时不要怀疑镜像服务，99% 是本地残留配置在作祟——尤其注意项目级 composer.json 里的 "repositories" 段，它优先级最高，删或注释掉再试。
容易被忽略的缓存与权限陷阱
即使所有配置都改对了，旧缓存和用户权限仍会让验证失败：
-
composer.lock和vendor/里可能还存着镜像源的包元数据，导致 Composer 复用旧路径；务必先rm -rf vendor composer.lock再验证 - Linux/macOS 下若曾用
sudo composer config -g，配置被写进/root/.composer/config.json，而普通用户运行时读的是$HOME/.composer/config.json，结果就是“明明配了却没用” - Windows 用户改完配置必须重启终端（CMD/PowerShell/WSL），否则新
config.json不会被加载 - Docker 多阶段构建中，final 阶段若以非 root 用户运行，需确保该用户家目录下
~/.composer/config.json确实包含还原后的配置，而不是 builder 阶段写的 root 配置
