524288000（500MB）是经实测验证的稳妥值，适用于RuoYi、ECharts等含大量静态资源的中大型项目；默认1MB易触发curl 56错误，而2GB可能在Windows或旧版Git上导致内存分配失败。
git config --global http.postBuffer 要设多大才够用
524288000（即 500MB）是经过大量实测验证的稳妥值，覆盖 RuoYi、ECharts 等含大量静态资源或历史提交的中大型项目。设太小（如默认 1MB）必然触发 curl 56；设太大（如 2GB）反而可能在某些 Windows 或旧版 Git 上引发内存分配失败。
实际建议按场景选：
- 普通项目（104857600（100MB）已足够
- 含大量二进制文件或完整历史的项目（如 Apache 仓库）：用
524288000 - 极特殊情况（如内网超大镜像库）：可试
1073741824（1GB），但需同步关闭core.compression
为什么改了 postBuffer 还报 curl 56
常见原因不是配置没生效，而是 Git 没读到它——尤其当你混用 HTTPS 和 SSH 协议时。http.postBuffer 只对 HTTP/HTTPS 生效，SSH 完全不走这套逻辑。
检查和修复步骤：
- 运行
git config --global --get http.postBuffer确认值已写入 - 确认 clone URL 是
https://开头，不是git@或ssh:// - 若用代理，确保
https.proxy配置与http.postBuffer同时存在，否则代理层可能截断流 - Git for Windows 2.41+ 用户注意：
curl 56+ “HTTP/2 stream was reset” 很可能是 HTTP/2 协议兼容问题，临时降级到 2.40.x 更快见效
浅克隆（--depth=1）能绕过 RPC failed 吗
能，而且是最快见效的临时方案，特别适合只读、CI 构建或本地调试。
GitHub Actions Runtime Regression Audit
下载
对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。
但要注意副作用：
-
git pull会失败，因为没拿到完整历史，无法计算差异 -
git blame、git log --all等依赖完整提交图的功能不可用 - 如果远程后续强制推送（force push）覆盖了你 clone 的那个 commit，本地将无法自动同步
- 部分私有仓库（如 GitLab 自托管）对 shallow clone 有策略限制，可能直接拒绝
命令示例：git clone --depth=1 https://gitee.com/y_project/RuoYi.git
error: RPC failed; curl 56 和 errno 54/10054 的区别
它们看起来像一类错误，但底层原因完全不同，混用解决方案会白忙活。
-
curl 56：纯客户端网络层中断，表现为“Recv failure”“Connection was reset”，本质是 TCP 连接被意外切断，优先调http.postBuffer和协议版本 -
errno 54（macOS / LibreSSL）或errno 10054（Windows）：SSL 层异常终止，常因 TLS 握手失败、证书校验不通过或中间设备（如企业防火墙）主动 kill 连接，此时加大 buffer 毫无作用，应换代理或关 HTTPS 验证（http.sslVerify false）
最稳的判断方式：加环境变量复现 GIT_CURL_VERBOSE=1 git clone ...，看最后一行是 Recv failure 还是 SSL_read: SSL_ERROR_SYSCALL
