[github]cursor导入项目失败，由于使用http2协议，修改为http1.1
解决办法，本次导入切换为http1.1 协议
不改变默认的http2协议
报错如下：
2026-06-23 20:05:46.553 [info] Cloning into ‘/Users/…’
fatal: unable to access ‘https://github.com/Jere…’: Error in the HTTP2 framing layer
（单次克隆生效，不修改全局配置）修改协议：
git-chttp.version=HTTP/1.1 clone https://github.com/Jere.../...Dictionary.git /Users/...永久强制HTTP/1.1
gitconfig--globalhttp.version HTTP/1.1原因
国内直连 GitHub 时，HTTP/2 极易报Error in the HTTP2 framing layer，HTTP/1.1 稳定可用，根源是两者底层传输机制、中间网络设备兼容性、跨境链路抗抖动能力完全不同。
一、底层设计根本差异（看懂为什么2更容易崩）
1. HTTP/2：单TCP连接多路二进制帧传输
HTTP/2 把所有请求塞进同一条TCP长连接，数据切割成二进制「帧（frame）」并行传输（多路复用）：
- 全程只有1条TCP通道，所有克隆/拉取数据共用这条链路；
- 数据是二进制分段帧，中间防火墙、运营商DPI、老旧代理必须完整解析二进制帧；
- 只要链路轻微丢包、延迟波动、中间设备解析异常，整条连接直接作废，直接抛出
framing layer帧解析错误； - 跨境访问GitHub本身RTT延迟200~900ms，链路抖动频繁，一丁点丢包就会破坏二进制帧结构，连接直接中断。
2. HTTP/1.1：多条独立文本TCP连接
HTTP/1.1 无多路复用，靠并行多条独立TCP连接传输，数据是明文文本格式：
- 每个请求单独一条TCP通道，一条断了不影响其他；
- 文本格式数据包，国内所有防火墙、DPI、代理都完美兼容，不会解析出错；
- 单条连接失败只会重试当前分片，不会直接中断整个克隆流程，容错性极强。
二、国内环境四大致命痛点（HTTP/2 必踩坑）
1. 国内中间网络设备对HTTP/2兼容性差
运营商防火墙、校园网/企业网关、DPI流量识别系统，大多对HTTP/2二进制帧解析不完善：
- 遇到大流量Git克隆（大量二进制帧持续传输），设备会截断、篡改、丢弃部分帧；
- 二进制帧少一段、顺序错乱 → curl 直接判定帧层非法，报错断开；
- HTTP/1.1明文流量不会触发解析bug，不会被截断。
2. 跨境链路抖动、丢包对单TCP连接毁灭性打击
GitHub服务器在海外，国内访问国际带宽拥堵、路由频繁绕行：
- HTTP/2 共用唯一TCP连接，一旦出现丢包，整条链路阻塞、帧重组失败；
- HTTP/1.1多连接分散压力，局部丢包只会重传单条连接数据，不会整体崩溃。
3. 代理/梯子残留配置冲突
如果开过代理、VPN，残留的http.proxy配置和HTTP/2握手流程冲突：
- HTTP/2 握手依赖TLS ALPN协议协商，代理对ALPN处理有缺陷，协商失败直接断连；
- HTTP/1.1 不依赖ALPN，代理兼容无压力。
4. Git+curl底层对HTTP/2容错逻辑弱
Git 的HTTPS底层依赖libcurl：
- curl对HTTP/2帧异常极其敏感，轻微数据错乱直接终止整个RPC克隆流程；
- 对HTTP/1.1有完善重试、分段容错机制，网络差也能断续完成下载。
三、通俗类比理解
- HTTP/2 = 单根大水管，多路水流并行：水管稍微堵一点、漏一点，整根管道直接爆掉，所有水流全部中断；
- HTTP/1.1 = 十几根独立细水管：一根堵了，其他水管正常流水，堵的那根单独重试即可，整体不会崩溃。
四、补充实操提示
- 国内直连GitHub，永久强制HTTP/1.1是最优解：
gitconfig--globalhttp.version HTTP/1.1- 若网络环境极好（专线/稳定合规代理），HTTP/2速度更快，但普通家用宽带不推荐；
- 彻底规避HTTPS协议问题可以切换SSH克隆，完全不走HTTP协议，无帧层报错。