直接改/etc/hosts比换DNS更可靠，因其优先级高于DNS，可绕过DNS污染；需用curl -I实测可用IP后静态绑定关键域名，且须禁用systemd-resolved防止覆盖配置。
直接改/etc/hosts比换DNS更可靠
DNS污染在企业网、校园网或某些ISP下极常见，哪怕你设了223.5.5.5，packagist.org或github.com仍可能被解析成错误IP。这时候光改/etc/resolv.conf没用，必须静态绑定关键域名。
执行curl -I https://mirrors.aliyun.com/composer/确认当前可用IP（比如223.6.6.6），然后往/etc/hosts加这几行：
223.6.6.6 mirrors.aliyun.com 223.6.6.6 packagist.org 223.6.6.6 github.com 223.6.6.6 githubusercontent.com
注意：别用ping packagist.org查IP——它返回的可能是CDN入口，而Composer走的是HTTPS元数据接口，必须用curl -I或openssl s_client -connect实测能建连的地址。
composer config -g repos.packagist必须带尾斜杠
阿里云镜像URL末尾的/不是可选的。漏掉它会导致Composer发请求到https://mirrors.aliyun.com/composer/packages.json（404），而不是正确的https://mirrors.aliyun.com/composer//packages.json（自动补双斜杠）。
验证是否生效的唯一方式是运行：
composer config -g repos.packagist
输出必须是纯URL字符串，例如https://mirrors.aliyun.com/composer/。如果看到{"type": "composer", "url": "..."} 这种JSON对象，说明你误用了旧版命令repo.packagist（已废弃），要删掉重配：
composer config -g --unset repos.packagistcomposer config -g repos.packagist composer https://mirrors.aliyun.com/composer/
禁用systemd-resolved防止它偷偷覆盖resolv.conf
Ubuntu 18.04+ 和 CentOS 8+ 默认启用systemd-resolved，它会监听53端口并劫持/etc/resolv.conf为软链，导致你手动写的nameserver在重启后消失。
彻底解决方法是停用它：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
sudo systemctl disable --now systemd-resolved
然后确认/etc/resolv.conf不再是软链接：
-
ls -l /etc/resolv.conf→ 应显示“regular file”，不是-> -
cat /etc/resolv.conf→ 只保留两行：nameserver 223.5.5.5和nameserver 114.114.114.114
不这么做，hosts+镜像源的组合拳会在某次系统更新后突然失效。
别信HTTP_PROXY环境变量，必须用https-proxy配置项
很多用户在终端里设了export HTTP_PROXY=http://127.0.0.1:8080，但composer install依然卡住——因为Composer默认所有仓库走HTTPS，而HTTP_PROXY只管HTTP请求，HTTPS请求完全不走它。
必须显式配置：
composer config -g http-proxy http://user:pass@127.0.0.1:8080composer config -g https-proxy http://user:pass@127.0.0.1:8080
注意两点：
第一，https-proxy值仍是http://开头，不是https://；第二，如果密码含@或/，必须用rawurlencode()编码，否则Composer解析失败且无提示。
验证是否生效：composer config -g --list | grep proxy必须同时输出http-proxy和https-proxy两行。
真正难搞的从来不是Composer本身，而是它穿过的那层网络栈——DNS污染、代理分流、systemd服务覆盖、URL编码陷阱，每一步都可能静默失败。动手前先跑一遍composer diagnose，重点看HTTP proxy和DNS resolution两行，比反复重装快得多。
