Composer 2.2+ 已废弃 repo.packagist，必须用 repositories.packagist.org 分两行配置 type 和 url（末尾带/），并清除缓存、刷新 DNS、删除项目级 repositories 字段及 vendor/composer.lock 才生效。
WSL 下 composer config -g 配镜像后不生效，不是命令没运行成功，而是配置被静默忽略或覆盖——Composer 2.2+ 已彻底废弃 repo.packagist 键名，且 WSL 的 DNS 缓存、项目级 repositories 字段、.vhdx 扫描三者叠加，让“配了等于没配”成为常态。
为什么 composer config -g repo.packagist 在 WSL 里根本不起作用
这条命令在 Composer 2.2+ 中已完全失效：它写入的是一个被忽略的字段，不会被读取。你运行它时没有任何报错，composer config -g repo.packagist 可能还返回空或旧值，但网络请求始终走 packagist.org。
- 必须用
repositories.packagist.org（注意是复数repositories+ 点号 +packagist.org） - 必须拆成两行设置：
composer config -g repositories.packagist.org.type composer和composer config -g repositories.packagist.org.url https://mirrors.aliyun.com/composer/ -
url值末尾的/不可省略；少它会导致请求路径拼成/composer/packages.json，返回 404 - 验证是否真写入：
composer config -g repositories.packagist.org必须输出完整 JSON 对象，形如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
WSL 下明明全局配对了，composer install 还卡在 Loading composer repositories
常见原因不是镜像地址错，而是 WSL 层面的 DNS 缓存未刷新，或 PHP/cURL 复用系统缓存解析结果，导致 mirrors.aliyun.com 仍被解析到海外 IP。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 临时绕过 DNS 缓存：加环境变量运行，例如
COMPOSER_NO_INTERACTION=1 composer install - 更可靠的做法是强制指定 DNS：在 WSL 中执行
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf > /dev/null（重启终端后需重设） - 别信
ping mirrors.aliyun.com—— 它走 ICMP，而 Composer 走 HTTPS；用curl -I https://mirrors.aliyun.com/composer/packages.json验证实际连通性 - 如果返回 301 或 HTML 页面，说明镜像服务异常（如清华源偶发人机验证），换阿里云或腾讯云源
项目根目录 composer.json 里有 "repositories" 字段就全完了
只要 composer.json 出现 "repositories" 字段，哪怕内容是 {}、[] 或 {"packagist.org": false}，全局镜像立刻失效，Composer 直接 fallback 到默认行为。
- 检查命令：
grep -A 5 '"repositories"' ./composer.json - 临时清空：
composer config --unset repositories（注意不加-g） - 清完必须删掉
vendor/和composer.lock，否则旧 lock 文件仍按原始源解析依赖 - CI/CD 流水线中尤其容易误加
"packagist.org": false，结果基础包都拉不到
验证镜像是否真在被请求，别只看 config -g 输出
composer config -g 显示有值 ≠ 网络请求走的是这个地址。真实行为得看连接发起点，尤其在 WSL 这种跨层环境中。
- 最轻量验证：
composer install -vvv 2>&1 | grep "Downloading.*packages.json"，确认域名是mirrors.aliyun.com而非packagist.org - 更底层验证（Linux/macOS）：
strace -etrace=network composer install 2>&1 | grep 'connect'，看 socket 连接的目标 IP 是否属于国内镜像服务器 - WSL2 下若仍连海外 IP，大概率是 Windows 主机 DNS 设置干扰，需在 WSL 内单独配置
/etc/resolv.conf，而非依赖 Windows DNS - Docker 构建时，
composer config -g写进容器/root/.composer，但构建用户常为www-data，根本读不到——应在 Dockerfile 中用USER www-data后再执行配置
真正卡住的地方，往往不在命令怎么写，而在 WSL 的 DNS 缓存机制、项目级配置的优先级规则、以及镜像源本身的同步延迟——三者叠加时，改对字段名也救不了连不上。
