http/2流式响应无需flush，依赖二进制data帧自动分帧与流控；必须前置writeheader、禁用content-length、用error检测断连，并启用http2debug辅助调试。
Go 语言处理 HTTP/2 下的流式响应，和 HTTP/1.1 有本质区别：HTTP/2 本身不使用 chunked transfer encoding，而是靠二进制帧（DATA 帧）天然支持多路复用、流式传输。这意味着你不用手动 flush、也不依赖 Transfer-Encoding 头——但这也带来新的约束和优化点。
HTTP/2 流式响应无需 Flush，但必须避免阻塞写入
在 HTTP/2 连接中，http.ResponseWriter 的 Write() 调用会立即触发 DATA 帧发送（只要连接未关闭、流未重置），底层自动分帧、流控、优先级调度。因此：
- 不需要类型断言
http.Flusher，也不应调用Flush()—— 该方法在 HTTP/2 下是空操作，且可能掩盖逻辑问题 - 仍需确保每次
w.Write()或json.Encoder.Encode()后没有长时间阻塞（如数据库查询、同步 sleep），否则整个流会卡住，客户端感知为“停滞” - 若 handler 中用了
time.Sleep或同步 I/O，建议改用非阻塞方式（如 timer channel + select）或移交至 goroutine 协作
正确设置响应头与状态码，避免流提前终止
HTTP/2 要求 HEADERS 帧必须在首个 DATA 帧之前发送，且一旦发送就不能再修改。常见陷阱：
-
w.WriteHeader()必须在任何w.Write()之前调用；若漏掉，Go 会隐式写 200，但后续无法再设自定义 header - 不要设置
Content-Length—— 虽然 HTTP/2 不强制禁用它，但流式场景下长度未知，设了反而可能干扰客户端解析 - SSE 场景推荐：
w.Header().Set("Content-Type", "text/event-stream")和w.Header().Set("Cache-Control", "no-cache")，这两项在 HTTP/2 下依然关键
检测客户端断连需用更可靠的方式
HTTP/2 没有 TCP 连接级的“断开通知”，http.CloseNotify() 已废弃且在 HTTP/2 下不可用。安全做法是：
- 每次
w.Write()或io.Copy()后检查 error：若返回net/http.ErrAbortHandler或io.ErrUnexpectedEOF，大概率是客户端关闭了流 - 对长周期流（如日志 tail），可定期发送空注释（
fmt.Fprint(w, ":keepalive\n\n")）并检查写入结果，主动探测流健康度 - 避免在 handler 中无限制循环；建议配合 context 超时（
r.Context().Done()）退出
调试与可观测性：善用 GODEBUG=http2debug
HTTP/2 行为不可见，出问题时很难凭直觉定位。生产中应启用调试日志：
- 启动服务时加环境变量：
GODEBUG=http2debug=1，观察流开启、SETTINGS 协商、RST_STREAM 等关键事件 - 若怀疑帧丢失或窗口耗尽，临时升到
=2查看完整 DATA 帧载荷摘要（注意仅限短时诊断） - 结合
curl -v --http2 https://...验证协议协商是否成功，确认 Protocol 列显示h2
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
