最常见错误是执行 composer config -g repos.packagist 或漏掉 type 参数，正确格式为 composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/，url 必须以 https:// 开头且末尾带斜杠。
composer config -g repo.packagist 命令写错最常见
很多人执行 composer config -g repos.packagist 或漏掉 composer 类型参数，结果配置无效但不报错。必须严格用这个格式：
-
composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/（推荐腾讯云，503 少、响应快） - URL 必须以
https://开头且末尾带斜杠，http会被 Composer 2.0+ 拒绝 - 执行后立刻验证：
composer config -g repo.packagist应输出完整 JSON 对象，不是空或null
镜像源失效时别硬等，快速切到备用地址
阿里云、华为云镜像在流量高峰（如凌晨或大促）可能返回 503 Service Temporarily Unavailable，而腾讯云和 https://packagist.proxy.fly.dev 更稳定。遇到 503 可秒切：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 换腾讯云：
composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/ - 临时验证用
--repository参数，不改全局：composer update --repository=https://packagist.proxy.fly.dev - 已停用的
https://packagist.phpcomposer.com别再试，现在会跳转到不可靠页面
项目级配置比全局更安全，尤其 CI/CD 场景
全局镜像在团队协作或 CI 流水线中容易引发 hash 不一致、依赖解析失败等问题。项目级写进 composer.json 才是可控做法：
- 在
composer.json顶层加"repositories"字段，key 必须是"packagist"：
"repositories": {
"packagist": {
"type": "composer",
"url": "https://mirrors.cloud.tencent.com/composer/"
}
}
repositories 字段？别手动覆盖，用命令追加，避免误删私有包源composer install 若报 hash 校验失败，删掉 vendor 和 composer.lock 重来即可“Could not resolve host”和“Connection refused”本质是 DNS 或协议层问题
这类错误常被误判为 Composer 本身故障，实际多与本地环境有关：
- 先试
curl -I https://packagist.org，如果连不通，说明不是 Composer 配置问题 - DNS 解析失败就改
/etc/resolv.conf或系统设置，加nameserver 1.1.1.1 - IPv6 不稳定时，镜像源比调
CURL_IPRESOLVE=4更可靠——国内镜像基本都做了协议适配和 CDN 优化 - 代理配置残留很隐蔽：
composer config -g --unset http-proxy和--unset https-proxy要一起清
Resolving dependencies 卡顿。那通常是 php 版本约束太宽、require-dev 包太多导致的，和网络无关。
