“Connection reset by peer”不是网络问题，大概率是镜像源返回403/502或拒绝TCP连接，需先用curl -I测试镜像根路径是否返回HTTP/2 200，避免测已不可用的旧源或缺斜杠的URL，并通过--repository临时覆盖源验证，同时检查缓存和目录权限。
“Connection reset by peer”不是网络问题，大概率是镜像源返回了 403/502 或直接拒绝 TCP 连接——重试本身没用，得先换源或调参数。
curl -I 测试镜像源是否真通
Composer 不报具体 HTTP 状态码，只笼统提示连接重置。必须手动验证镜像根路径是否可访问：
- 运行
curl -I https://mirrors.aliyun.com/composer/，看是否返回HTTP/2 200；若卡住、超时或返回403 Forbidden，说明源已失效或被拦截 - 别测
https://packagist.org——国内多数情况它根本连不通，但测它会误导你去调 DNS 或代理 - 已停服的
https://packagist.phpcomposer.com和少斜杠的https://mirrors.aliyun.com/composer（缺末尾/）都会导致拼出错误路径/composerpackages.json→ 404
临时重试：用 --repository 绕过所有配置
改错全局配置会导致后续项目批量失败，临时验证请直接覆盖源地址：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 命令形如：
composer install -vvv --repository=https://mirrors.huaweicloud.com/repository/php/ -
-vvv会输出完整请求链路（DNS 解析、TLS 握手、HTTP 状态码），一眼看出卡在哪一步 -
--repository只对当前命令生效，不影响composer.json或全局 config - 注意 URL 必须带完整路径后缀，
https://mirrors.huaweicloud.com会 404，正确是https://mirrors.huaweicloud.com/repository/php/
调高重试次数和超时时间
默认 3 次重试 + 300 秒 process-timeout 在企业网或 CI 下完全不够用：
- 全局设重试次数：
composer config -g retries 5 - 必须同步调两个超时：
composer config -g process-timeout 1800（整个命令生命周期）和composer config -g http-timeout 600（单次 HTTP 请求） - CI 环境建议加
--prefer-dist --no-interaction --no-scripts，跳过 git clone 和钩子脚本，避免卡在php artisan key:generate这类阻塞操作 - 别设
process-timeout=0，CI 中稳比快重要，无限等待等于构建挂起
权限污染导致重试反复失败
很多人反复重试却始终失败，其实是 vendor/ 或 ~/.composer 被 sudo 占用过，普通用户无权写入：
- 检查归属：
ls -ld vendor/ composer.lock $(composer config --global home) - 若输出中出现
root，说明已被污染，执行sudo chown -R $USER:$USER vendor/ composer.lock ~/.composer - 永远不要用
sudo composer global require——它会把二进制装进/root/.composer/vendor/bin/，你的 shell 根本找不到 - 清缓存前先确认归属：
composer clear-cache若报 Permission denied，说明缓存目录也归 root 了
重试只是表象，真正卡点往往在镜像源可用性、URL 末尾斜杠、缓存归属这三处，其他参数调整都是补救。每次失败后先跑一遍 curl -I 和 ls -ld，比盲目重试快得多。
