Composer镜像不生效的根本原因是三个硬性条件缺一不可：键名必须为单数repo.packagist、type值必须显式写composer、URL须HTTPS且末尾带/；任一缺失即静默回退官方源。
composer config -g repo.packagist 命令没写对，镜像就根本不会生效——不是慢、不是超时，是 Composer 完全无视你配的地址，静默 fallback 到 <a href="https://www.php.cn/link/ec811d0d775adc62776ba80fadd4ed19">https://www.php.cn/link/ec811d0d775adc62776ba80fadd4ed19</a>。
为什么 composer config -g repo.packagist 总是不生效
这条命令看着简单，但漏掉任意一个硬性条件，配置就等于没写进去，且无报错提示：
-
repo.packagist必须是单数，写成repos.packagist或repositories.packagist全部无效 - 中间必须显式传入
composer作为type值：正确写法是composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏掉composer参数即失效 -
URL必须以https://开头，且末尾带斜杠：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会拼出/composerpackages.json导致 404） - 必须加
-g，否则只改当前目录下的composer.json，换项目就失效
验证是否成功：运行 composer config -g repo.packagist，输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、只返回 URL 字符串，都说明没写对。
项目级 repositories 正在覆盖全局配置
Composer 的源优先级是：项目级 composer.json 中的 repositories > 全局配置 > 默认源。哪怕你全局配得再准，只要项目里有这个字段，就会屏蔽全局设置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查方式：运行
composer config repo.packagist（不带-g），有输出就说明项目自己写了镜像 - 常见陷阱：
"repositories": {}或"repositories": []这种空结构也会触发覆盖 - 临时清理：
composer config --unset repositories（注意没-g） - 安全追加：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/，它会自动 merge 到composer.json的repositories对象中，不破坏已有私有源
缓存没清，配置白配
Composer 缓存的是 packages.json 和 provider 文件路径（如 p/provider-2025-10%24.json）。改了镜像但不清缓存，它仍按旧元数据发起请求，结果就是 404、找不到包、锁文件错乱。
- 必做动作：
composer clear-cache（注意不是cache-clear，后者已废弃） - 验证是否清空：
ls -la ~/.composer/cache/（Linux/macOS）或dir %APPDATA%\Composer\Cache\（Windows），应为空或只剩空子目录 - 更彻底方式：先执行
composer config -g cache-dir /tmp/composer-cache-empty，再clear-cache - 清完缓存后，用
composer install -vvv | grep "Downloading.*packages.json"确认第一行请求域名是你配的镜像地址
DNS 污染导致镜像域名根本解析不了
不是镜像挂了，是你的本地系统查不到 mirrors.aliyun.com 的真实 IP——名字认不出来，后续所有请求都发不出去。
- 确认是否 DNS 污染：
nslookup mirrors.aliyun.com 1.1.1.1如果返回 IPv4（比如223.5.5.5），而nslookup mirrors.aliyun.com（不指定 DNS）超时或报*** Can't find mirrors.aliyun.com: Non-existent domain，就是污染实锤 - 直连验证镜像服务：
curl -I --resolve mirrors.aliyun.com:443:223.5.5.5 https://mirrors.aliyun.com/composer/packages.json，返回HTTP/2 200和Content-Type: application/json才说明服务本身正常 - 生产环境首选方案是绑定
/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows），但三处必须同时满足：IP 必须最新（每次用dig mirrors.aliyun.com @8.8.8.8 +short | head -n1拿）、格式严格（IP 和域名之间只能是空格）、缓存必须刷新（sudo dscacheutil -flushcache/ipconfig /flushdns/sudo systemd-resolve --flush-caches）
真正卡住的地方往往不在镜像地址本身，而在配置落盘路径、DNS 解析层、缓存生命周期这三处——它们不报错，但会让所有操作变成“看似做了，其实没做”。
