错误源于http/https传输中连接被中间设备或服务器主动中断；解决方法包括：1. 调高缓冲区至500mb（git config --global http.postbuffer 524288000）；2. 降级http/1.1并关闭低速限制；3. 浅克隆后按需fetch；4. 改用ssh协议。
Mac上克隆超大仓库时，进度走到30%突然卡住，终端弹出error: RPC failed; curl 18 transfer closed with outstanding read data remaining，不是网线松了，也不是Wi-Fi断了，而是Git在HTTP协议层被中间网络设备或服务器主动掐断了连接。
调高HTTP缓冲区上限
第一步：打开终端，执行以下命令，把Git的HTTP POST缓冲区从默认约1MB直接拉到500MB：
git config --global http.postBuffer 524288000
这一步必须做，【不设这个值，后续所有优化都可能白忙】。因为大仓库传输单个pack文件常超200MB，而默认缓冲区仅1MB，Git会反复分片、重连、校验，极易触发curl 18错误。设完后可运行git config --list | grep postBuffer确认是否生效。
强制降级到HTTP/1.1协议
方法一：禁用HTTP/2（最常用）
git config --global http.version HTTP/1.1
Mac系统自带的curl版本较新，默认倾向HTTP/2，但企业内网代理、某些CDN或Git托管服务对HTTP/2的流控支持不完善，容易在长连接中误判“空闲”并断开。降级后连接更“笨重”但更稳，实测对GitHub私有库和GitLab自建实例成功率提升明显。
方法二：同时关闭低速限制（辅助手段）
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999
这两条命令让Git彻底放弃“传输太慢就断连”的判断逻辑。注意：lowSpeedLimit设为0表示不限速下限，lowSpeedTime设为超大值（如999999秒≈11.5天）才能真正起效，设小了反而更易中断。
只取最新快照，跳过全部历史
第一步：执行浅层克隆，仅下载HEAD指向的当前代码树，不含任何commit历史、分支指针、tags：
git clone --depth 1 https://xxx.git
第二步：如果后续需要补全部分历史（比如要查最近3次提交），再进目录执行：
cd 仓库名 → git fetch --unshallow
第三步：若需恢复完整历史，运行：
git fetch --prune origin '+refs/heads/*:refs/remotes/origin/*'
浅克隆能立竿见影避开90%的RPC失败场景，尤其适合CI构建、本地调试、文档预览等无需追溯变更的用途。但注意：【--depth 1后无法执行git blame或git log -p，除非先fetch --unshallow】。
换用SSH协议绕过HTTP瓶颈
方法1：改用SSH URL重新克隆
把https://github.com/user/repo.git换成git@github.com:user/repo.git
方法2：确保SSH密钥已加载且GitHub账户已绑定公钥
ssh-add -l 验证密钥是否在agent中；ssh -T git@github.com 测试连通性。SSH协议不走HTTP栈，不受postBuffer、HTTP/2、代理超时等限制，对大仓库天然友好。但前提是目标仓库必须开启SSH访问权限，且你的Mac已配置好对应密钥对。
