go的http.responsewriter是否分块传输取决于content-length是否设置，而非字符串拼接；未设则自动启用chunked，但需显式flush()才能触发发送，否则数据滞留于4kb缓冲区。
Go 的 http.ResponseWriter 不会因为你拼接了大字符串就自动分块；它只管写入缓冲区，是否 chunked 完全取决于你有没有设 Content-Length——设了就禁用 chunked，没设才启用。真正影响“客户端何时收到数据”的，是底层 4KB 缓冲 + 你是否调用 Flush()。
为什么字符串拼接后 flush 也不一定立刻发包？
Go 的 HTTP server 内置输出缓冲区约 4KB，Write() 只是把字节塞进去，不触发网络发送。即使你拼了一个 10MB 的 string 然后 w.Write([]byte(bigStr))，只要没 Flush()，数据就卡在服务端内存里。
- 本地测试时容易误判：小字符串（如 "
ok
"）可能凑够 4KB 缓冲就自动 flush，但线上高延迟或低带宽下不会 - 拼接本身不改变传输行为，但一次性写入过大字符串会阻塞 goroutine，且无法感知 client 断连
- 如果拼接后直接返回 handler，Go 会在函数退出时 flush 整个缓冲区——但这不是流式，而是“攒完再发”
大字符串该不该先拼好再 Write？
不该。尤其是响应体不可预估长度、或需支持 SSE / 日志流等场景。
-
bytes.Buffer或strings.Builder全量拼接会吃光内存：100MB 字符串 = 100MB 堆分配，GC 压力陡增 - 拼接过程无错误反馈：中间出错（如模板渲染 panic）会导致整个响应丢失，无法降级
- 更安全的做法是边生成边写：
json.NewEncoder(w).Encode(v)、template.Execute(w, data)，它们内部按需 flush，且天然适配 chunked - 若必须拼接（如 HTML 模板片段），用
io.WriteString(w, s)替代w.Write([]byte(s))，避免重复 alloc
如何让大字符串真正“分块发出”？
关键不是拆字符串，而是控制 write + flush 的节奏。chunked 是协议层自动加的，你只需确保不拦住它。
- 确认没设
Content-Length：w.Header().Set("Content-Length", "...")或任何间接设置（比如http.ServeFile、http.Error）都会让 chunked 失效 - 每次逻辑单元写完就 flush：
if f, ok := w.(http.Flusher); ok { f.Flush() }，例如每渲染一个列表项、每输出一条日志行 - 避免高频 flush：
time.Sleep(1 * time.Millisecond)后 flush 会引发大量 syscall，建议按语义边界（如 JSON object、HTML tag 对）flush - 注意 context 中断：
select { case 应放在每次 write/flush 前，否则超时后还在写，会返回 <code>context canceled错误
最容易被忽略的坑：中间件偷偷写了 Content-Length
一个 gzip.Handler、一次 http.Redirect、甚至某个日志中间件调了 io.ReadAll(r.Body) 后又调 w.WriteHeader(200)，都可能导致响应头里悄悄出现 Content-Length。结果就是：你写了 10 次 Flush()，curl 却只收到一个整包响应。
查问题第一件事：用 curl -i http://localhost:8080/stream 看响应头里有没有 Content-Length。有，就说明 chunked 已被禁用——别调半天 Flush()，先翻中间件代码。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
