Go可用net/http+io.Pipe+json实现流式微服务，关键在禁用缓冲、调用Flusher、用Pipe解耦生产与传输、处理客户端断连及超时。
Go 本身没有内置的“流式微服务框架”，但用 net/http + io.Pipe + json.Encoder/json.Decoder 就能实现低延迟、内存可控的流式数据处理，关键在连接生命周期管理和反压控制。
用 http.ResponseWriter 直接写入流而不缓冲
默认 HTTP handler 会等 handler 返回才发响应，流式必须禁用缓冲并保持连接打开。核心是调用 Flusher 接口：
常见错误：直接用 fmt.Fprintf(w, ...) 写多次但没 Flush() → 客户端收不到中间数据；或 handler 返回后连接被关，后续写入 panic。
- 先断言
w是否支持http.Flusher：if f, ok := w.(http.Flusher); ok { ... } - 每次写完结构化数据（如 JSON 对象）后立刻调用
f.Flush() - 避免在写入中途返回 error 并结束 handler，否则连接中断；应持续写入错误帧（如
{"error":"timeout"}）再关闭 - 设好
http.Server.ReadTimeout和WriteTimeout，防止长连接耗尽资源
用 io.Pipe 解耦生产与传输逻辑
业务逻辑（如从 Kafka 拉消息、聚合指标）和 HTTP 响应写入不应耦合。Pipe 提供 goroutine 安全的单向通道：
立即学习“go语言免费学习笔记（深入）”；
典型场景：一个 goroutine 从消息队列读数据并写入 pipeWriter，主 handler 从 pipeReader 读并转发给客户端。
-
pr, pw := io.Pipe()创建配对管道；handler 中用io.Copy(w, pr)流式转发 - 生产 goroutine 写完需调用
pw.Close()，否则io.Copy不会结束；出错时用pw.CloseWithError(err) - 注意 pipe buffer 默认为 4KB，突发高吞吐可能阻塞写端 —— 若需更高背压能力，改用带缓冲的
chan []byte或bytes.Buffer手动控制 - 不要在多个 goroutine 并发写同一个
pw，需加锁或由单一生产者负责
处理客户端断连：检查 http.ErrHandlerTimeout 和 write: broken pipe
流式连接中客户端随时可能关闭，不检测会导致 goroutine 泄漏和无效写入。
错误现象：write tcp ...: write: broken pipe 或 handler 被强制超时中断后仍尝试写入。
- 每次调用
f.Flush()后检查w.(http.CloseNotifier).CloseNotify()（旧版 Go）或更可靠的方式：捕获write错误中的os.ErrClosed或syscall.EPIPE - Go 1.22+ 推荐用
http.Request.Context().Done()监听取消：select { case - 在写入前加
if !f.Flushed() { ... }避免对已关闭连接重复 flush - 务必用
defer pw.Close()或显式 close 管道，否则 reader 永远阻塞
JSON 流格式选 ndjson 而非数组封装
用 application/json 响应体传多条记录时，别用 [{},{},{}] —— 客户端必须收全才能解析，失去流意义。
正确做法是每行一个 JSON 对象（NDJSON / JSON Lines），便于前端用 response.body.getReader() 流式解析。
- 服务端写法：
enc := json.NewEncoder(pw); for _, v := range data { enc.Encode(v) }（Encode自动换行） - 设置 header：
w.Header().Set("Content-Type", "application/x-ndjson")（标准 MIME 未注册，application/json-seq是 RFC 7464，但浏览器支持弱，务实用x-ndjson） - 避免在流中混入非 JSON 行（如日志、注释），NDJSON 解析器会失败
- 若需传输二进制（如 protobuf），改用
application/grpc+proto或自定义分隔符（如长度前缀），而非 base64 编码 JSON
流式处理真正的难点不在 Go 语法，而在于连接状态机设计：什么时候该重试、什么时候该降级、怎么让下游消费速度慢时不拖垮上游。这些逻辑没法靠库自动解决，得在 select + context + 显式错误分支里一条条写清楚。
