composer install超时或卡在updating dependencies，根本原因是国内直连packagist.org导致dns解析慢、tls握手失败、tcp连接中断；必须正确配置并验证清华/阿里等镜像源，清除项目级repositories覆盖，定期检查同步状态与url格式（如结尾斜杠），避免docker或协作中配置丢失。
为什么 composer install 总是超时或卡在 Updating dependencies
国内直连 Packagist 官方源（https://packagist.org）因网络策略和物理距离，DNS 解析慢、TLS 握手失败、TCP 连接中断很常见。这不是你项目写错了，也不是 Composer 本身坏了，而是默认源不可靠。必须切换镜像源，且不能只“设一次”了事。
- 官方源在国内平均响应时间常超 10s，部分请求直接被重置，表现为
Connection timed out或cURL error 56: Failure when receiving data from the peer - 镜像源不是永久稳定的：阿里云、腾讯云、华为云等镜像会定期同步，但存在数分钟到数小时的延迟；清华源曾因维护临时下线过 API 接口
-
composer config -g repo.packagist设置的是全局镜像，但某些私有项目可能强制写死repositories字段，会覆盖全局配置
如何正确设置并验证国内镜像源（含多源 fallback 方案）
别只用一条 composer config -g repo.packagist 命令应付。要分三层处理：全局默认源、项目级覆盖、运行时兜底。
- 推荐优先使用清华源：
composer config -g repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/，它支持完整 Packagist 协议，包括packages.json和dist文件下载 - 若项目
composer.json中已定义"repositories"，需手动删掉或注释掉类似{"type": "composer", "url": "https://packagist.org"}的条目，否则全局配置无效 - 为防单点故障，可添加备用源脚本：运行前先执行
curl -I https://mirrors.tuna.tsinghua.edu.cn/composer/packages.json 2>/dev/null | grep "HTTP/2 200" || composer config -g repo.packagist composer https://mirrors.huaweicloud.com/repository/php/ - 验证是否生效：运行
composer config -g repo.packagist，输出应为{"type": "composer", "url": "https://mirrors.tuna.tsinghua.edu.cn/composer/"}；再执行composer show -p | head -3，看是否快速列出包而非卡住
composer update 时提示 Package x/y is not available in configured repositories 怎么办
这通常不是镜像问题，而是镜像源没同步到最新包，或你用了非标准分支（如 dev-main）、带 @dev 标签的开发版——这类包很多镜像默认不抓取。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 清华、华为等主流镜像只同步
stable和RC版本，dev-开头的分支需额外配置：composer config -g minimum-stability stable（慎用），或改用--with-all-dependencies强制拉取 - 某些包（如私有 GitLab 仓库、GitHub private repo）根本不在镜像范围内，必须在
composer.json的repositories里显式声明，类型设为vcs，URL 写原始 Git 地址 - 执行
composer update --no-cache可绕过本地缓存，排除因镜像元数据陈旧导致的误判
镜像源需要定期维护吗？哪些操作会悄悄把它搞失效
需要。镜像配置不是“设完即永恒”，几个日常操作会意外破坏它。
- 升级 Composer 到 2.5+ 后，部分老镜像 URL（如带
/packages.json后缀的）会被拒绝，报Invalid repository type；必须用纯域名形式，如https://mirrors.tuna.tsinghua.edu.cn/composer/（结尾斜杠不能少） - 使用
composer create-project初始化新项目时，如果模板自带composer.json且含repositories字段，会自动覆盖全局镜像——建议初始化后立刻检查composer config repo.packagist（不加-g查当前项目） - Docker 构建中若用
composer install --no-interaction，但基础镜像未预置镜像配置，就会回退到官方源；应在Dockerfile中加入RUN composer config -g repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/
最易被忽略的是：团队协作时，有人本地改了全局镜像，却把 composer.lock 提交上去，别人 composer install 时看似正常，实则用的是不同源同步出的依赖版本——锁文件不记录镜像地址，只记录包哈希，隐患极深。
