必须显式调用Flush，Write仅写入内存缓冲区；常见问题如文件为空、HTTP响应卡住均因未Flush；Flush推数据到底层，Close先Flush再释放资源。
Go 的 Write 不会自动刷到磁盘，必须显式调用 Flush
Go 标准库中绝大多数 Writer（比如 bufio.Writer、gzip.Writer、http.ResponseWriter）都带缓冲，Write 只是把数据拷进内存缓冲区，不等于写入底层文件或网络连接。调试时看到文件没内容、HTTP 响应卡住、日志延迟，八成是忘了 Flush。
常见场景：
- 用
bufio.NewWriter(os.Stdout)打印调试信息，程序退出前没Flush→ 终端看不到输出 - 用
gzip.NewWriter(f)写压缩文件，只Write不Close或Flush→ 文件损坏或无法解压 - HTTP handler 中对
http.ResponseWriter调用Write后直接 return → 响应体可能未发出（尤其启用 HTTP/2 或启用了中间件缓冲时）
Flush 和 Close 有什么区别？什么时候该用哪个？
Flush 强制把缓冲区数据推到底层 Writer（如文件句柄、socket），但不关闭它；Close 通常先 Flush 再释放资源（比如关文件、结束 gzip 流）。误用会导致数据丢失或 panic。
关键判断点：
- 还在循环中持续写入？→ 用
Flush，别Close - 写完就不再用了（比如单次日志、生成一个文件）？→ 用
Close更安全（它隐含Flush） - 底层
Writer是os.File或net.Conn？→ 它们本身没有Flush方法，必须包一层bufio.Writer才有 - 用的是
io.MultiWriter或自定义 wrapper？→ 检查它是否实现了interface{ Flush() error }，否则调Flush会编译失败
调试时怎么快速验证是不是缓冲没刷？
最直接的办法：在 Write 后立刻加 Flush，观察行为是否变化。不要依赖 defer Close() 在函数末尾才刷——如果中间 panic 或提前 return，就漏了。
典型调试片段：
// ❌ 错误：只 defer Close，但 Write 后没及时刷，调试日志延迟
w := bufio.NewWriter(f)
defer w.Close()
w.Write([]byte("debug: start\n"))
// ... 中间可能 panic 或 return，"start" 就卡在缓冲里
// ✅ 正确：Write 后立即 Flush，或用 Close 确保收尾
w := bufio.NewWriter(f)
defer w.Close()
w.Write([]byte("debug: start\n"))
w.Flush() // 关键：立刻可见
// ✅ 更稳妥（尤其写文件）：用 Close 收尾，但确保它被调用
w := bufio.NewWriter(f)
w.Write([]byte("final data\n"))
if err := w.Close(); err != nil {
log.Fatal(err) // Close 包含 Flush，失败说明写入底层出错
}
哪些 Writer 默认不带缓冲？它们需要 Flush 吗？
标准库中少数 Writer 是无缓冲的，比如 os.Stdout、os.Stderr、bytes.Buffer。它们的 Write 直接生效，调 Flush 是空操作（bytes.Buffer 甚至没实现 Flush 方法）。
但注意：os.Stdout 在终端里可能被行缓冲（遇到 \n 才刷），所以调试时仍建议加换行符；而重定向到文件时，os.Stdout 实际是带缓冲的 *os.File，此时又需要 bufio.Writer + Flush。
简单记：
- 不确定有没有缓冲？→ 统一包
bufio.NewWriter，写完调Flush或Close - 用
log.Logger？→ 它默认用os.Stderr，已处理缓冲，不用管Flush - HTTP handler 返回响应？→
http.ResponseWriter的Flush是可选的（用于流式响应），但普通响应靠Write+ 函数返回即可，底层 HTTP server 会处理收尾
缓冲行为不是黑盒，而是明确由类型决定的。调试时盯住具体类型（bufio.Writer？gzip.Writer？http.ResponseWriter？），查它的文档和方法集，比猜“应该刷了吧”更可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
