Git推送至GitHub出现RPC failed curl92 HTTP/2流未关闭错误的解决方法

结合你已经做过的排查操作（切换HTTP/1.1、删除.git重新初始化均无效），这个RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)报错的核心触发逻辑已完全排除HTTP2协议本身的兼容bug，实际诱因通常来自以下几个：

• 本地Git默认的HTTP传输缓冲区上限过低（默认仅1MB左右），单次推送的对象体积一旦超过缓冲区阈值，会直接导致传输流被主动取消
• 操作流程顺序错误导致大文件未被LFS接管：你是在完成文件add、commit之后才执行git lfs track "*.jpg"命令，此时LFS只会追踪后续新增/修改的文件，已经存入Git对象库的大体积二进制文件不会自动迁移到LFS通道，仍然会走普通HTTP传输撑爆缓冲区
• 本地网络链路和GitHub之间存在丢包、HTTP代理拦截：公共网络环境下的代理会对大流量的HTTP传输做主动中断，直接把传输流置为CANCEL状态，触发该报错
• 哪怕重新初始化仓库，如果没有先配置好LFS规则再add文件，之前的大体积文件仍然会被存入普通Git对象库，问题自然会重复出现

1. 调大Git全局HTTP传输缓冲区阈值，从根源解决缓冲区过小导致的流中断：

   git config --global http.postBuffer 524288000
   

   该命令会将缓冲区上限设置为500MB，足够覆盖绝大多数中小型项目的单次推送需求，不需要设置更高的数值避免不必要的内存占用。
2. 修正LFS配置的操作顺序，确保大文件被正确接管：
   • 删除旧的.git目录完成仓库重初始化时，先依次执行LFS配置命令，再做文件暂存操作：

     git lfs install
     git lfs track "*.jpg"
     git add .gitattributes
     

   • 确认.gitattributes被纳入暂存区之后，再执行git add .、git commit操作，所有jpg格式文件会直接被LFS接管，不会进入普通Git对象的传输通道。
3. 切换远程仓库关联协议，规避网络层的HTTP拦截：
   如果完成上述两步操作后仍报错，说明当前网络环境存在HTTP层的流量拦截，直接将远程关联地址从HTTPS格式切换为SSH格式即可：
   • 提前在GitHub账号中添加本地生成的SSH公钥，再执行命令修改远程地址：

     git remote set-url origin git@github.com:你的用户名/你的仓库名.git
     

   SSH协议走独立的加密传输通道，不会被普通HTTP代理规则拦截，大文件传输的稳定性远高于HTTPS通道。
4. 大体积仓库的兜底推送方案：
   如果项目仓库总大小超过1GB，单次全量推送仍然存在流中断风险时，不要一次性推完全部提交，分批次逐次推送最早的提交到远程main分支，等每一批次推送成功后再推送下一批，降低单次传输的体积阈值。

内容的提问来源于stack exchange，提问作者hane Smitter