“could not resolve host”本质是网络层dns解析失败，主因是packagist.org被劫持，换国内镜像源（如阿里云）比修dns更高效；需确保全局或项目级配置键名、type、url格式正确，并清缓存生效。
“Could not resolve host” 不是 Composer 坏了，是你根本没连上域名服务器——换镜像源比修 DNS 更快、更准、更可靠。
为什么 Could not resolve host 八成不是 DNS 问题
报这个错时，很多人第一反应是改 /etc/resolv.conf 或换 DNS，但实际多数情况是：Composer 根本没走你设的 DNS，它在尝试直连 packagist.org，而该域名在国内已被运营商劫持或污染，dig packagist.org 返回空或错误 IP 是常态。
更关键的是：composer install 卡在这一步，说明请求还没发到 HTTPS 层，SSL 证书、CA 文件、PHP 函数禁用这些全不相关——纯属 DNS 解析失败。
- 验证方式：运行
curl -I https://packagist.org/packages.json，如果也报Could not resolve host，确认是网络层问题 - 别信
ping packagist.org——很多环境 ping 走 ICMP，而 Composer 走 HTTPS，两者解析路径可能不同 - 临时切热点测试有效，但不解决根本；系统级 DNS 修改会影响内网服务，不推荐作为首选
composer config -g repo.packagist 配了却没生效？检查这三处硬伤
这条命令静默失败的常见原因不是手误，而是三个条件缺一不可：
- 键名必须是
repo.packagist（不是repos.packagist、repositories.packagist或packagist.org） -
type必须显式传composer：漏掉它，Composer 2.5+ 直接忽略整条配置 - URL 必须是 HTTPS 且末尾带
/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（拼路径变成/composerpackages.json，404）
验证是否真写进去了：运行 composer config -g repo.packagist。输出必须是完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果还是 https://packagist.org 或空，说明没配对。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
项目级配置比全局更稳，尤其在宝塔、CI、Docker 里
全局配置存在两个致命短板：
- 只要项目
composer.json里有"repositories"字段（哪怕只是"repositories": []），全局设置就彻底失效——不是优先级低，是直接跳过 - 权限错位：宝塔用
www用户执行命令，你在终端用root配的~/.composer/config.json，www根本读不到；CI 或 Docker 容器里甚至没有~/.composer目录
推荐做法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加 -g）。它会自动合并到 composer.json 的 repositories 字段中，key 固定为 "packagist"。
如果原 composer.json 是 "repositories": []，需先手动改为 "repositories": {} 再执行，否则报错。
换源后仍卡在 Loading composer repositories？清缓存是刚需
镜像只加速元数据和 ZIP 包拉取，不解决缓存污染问题。旧失败记录还在缓存里，重试照样走原地址。
- 必须执行
composer clear-cache，否则无效 - 验证是否真生效：运行
composer install -vvv | grep "Downloading.*packages.json"，看实际请求域名是不是阿里云地址 - 别信
composer config -g repo.packagist的输出——它可能返回旧值或空，不代表当前行为
复杂点在于：同一个命令在不同上下文（CLI / Web / CI）可能读取不同配置；容易被忽略的是，composer.json 中的 repositories 字段一旦存在，全局镜像就形同虚设——这点在部署脚本里最容易踩坑。
