Write后调用WriteHeader失效，因Go的ResponseWriter惰性写入：首次Write自动发200 OK并锁定响应头，后续WriteHeader被忽略；正确顺序是先WriteHeader再Write。
为什么 Write 后再调用 WriteHeader 会失效？
Go 的 http.ResponseWriter 是惰性写入的：第一次调用 Write 时，若状态码未显式设置，会默认写入 200 OK，并锁定响应头。此后再调用 WriteHeader 就会被忽略——HTTP 头已发送，无法更改。
常见错误现象：WriteHeader(404) 放在 Write([]byte{...}) 之后，浏览器仍收到 200 响应。
- 正确顺序：先
WriteHeader，再Write - 如果只写正文没设状态码，Go 自动补
200，但不报错，容易掩盖逻辑问题 - 调试时可用
httptest.ResponseRecorder检查实际写入的状态码和头
如何安全地多次写入响应体（如流式响应）？
标准 ResponseWriter 支持多次 Write，但必须确保响应头已确定、且未触发 flush。适合日志推送、SSE、大文件分块传输等场景。
关键限制：Content-Length 不能预知时，需依赖 Transfer-Encoding: chunked，而 Go 默认在 Write 后自动启用分块编码（只要没显式设 Content-Length 且未关闭连接）。
立即学习“go语言免费学习笔记（深入）”；
- 不要手动设置
Content-Length，除非你能精确计算总字节数 - 调用
Flush()（需类型断言为http.Flusher）可强制刷出缓冲区，用于实时推送 - 注意客户端是否支持流式响应（如某些代理或测试工具会缓存直到 EOF）
json.Encoder 直接写入 ResponseWriter 为什么比 json.Marshal + Write 更好？
对 JSON 响应，直接用 json.NewEncoder(w).Encode(v) 可避免内存拷贝和中间 []byte 分配，尤其适合结构体较大或高并发场景。
它底层调用 w.Write 分段写入，且自动处理 HTTPEncode 相关的转义与换行，同时保持流式友好性。
- 不用手动加换行或逗号，
Encode自动处理 - 若结构体含不可序列化字段，
Encode会立即返回 error，而Marshal可能静默截断 - 注意：
Encode末尾会输出换行符，某些前端解析器敏感，必要时用json.Compact包装
写入响应体时如何避免 panic：nil pointer 和 closed body？
两种典型 panic：panic: write on closed response body（handler 返回后还异步写入），以及 nil pointer dereference（误将 nil 写入 Write）。
前者多见于 goroutine 中未同步生命周期；后者常因 io.Copy 或自定义 io.Reader 返回 nil, nil 被误当作数据源。
- 禁止在 handler 返回后访问
ResponseWriter，goroutine 需通过context或 channel 控制退出 -
Write(nil)是合法的（写 0 字节），但Write(*nil)会 panic；检查指针解引用前是否非空 - 使用
io.Copy时，确保源Reader不会在中途返回(nil, nil)—— 这是违反io.Reader协议的行为
最易被忽略的一点：Go HTTP Server 默认启用 HTTP/1.1 的 keep-alive，但一旦响应体写入出错（如网络中断），Write 可能返回 err != nil，此时继续写入无意义，也无需重试——连接很可能已断开。
