bufio.NewReader 配合 io.Copy 流式推送比 os.ReadFile 更优，因其仅维持固定缓冲区内存恒定，避免大文件加载引发的 GC 压力与 OOM；默认 4KB 缓冲不足，推荐设为 32–64KB 以平衡 syscall 次数与首字节延迟。
直接用 io.Copy + bufio.Reader 组合，比手动循环读+网络写快 3–5 倍，且内存更稳——前提是缓冲区大小和错误检查到位。
为什么 bufio.NewReader 配合网络写入比 os.ReadFile 更适合流式推送
os.ReadFile 把整个文件加载进内存，遇到几百 MB 的日志或导出数据时，GC 压力陡增，还可能触发 OOM；而流式读取只维持一块缓冲区，边读边推，内存占用恒定。
- 默认
bufio.NewReader的 4KB 缓冲在小文件上够用，但推送 CSV 或 JSONL 到 HTTP 客户端时，建议设为32 * 1024～64 * 1024：太小导致 syscall 过多，太大则首字节延迟升高 - 别复用同一个
bufio.Reader实例跨多个请求——它内部状态（如缓冲区偏移）不安全，每次新请求都应新建 - 如果源文件极长（如 >1GB），且网络链路不稳定，考虑加
context.WithTimeout包裹io.Copy，避免卡死
io.Copy 写到 net/http.ResponseWriter 时，Content-Length 怎么设才不丢数据
不设 Content-Length 时，HTTP/1.1 默认启用 Transfer-Encoding: chunked，但某些旧客户端或代理会截断 chunked 响应。设了又容易错——因为 io.Copy 不返回总字节数。
- 可靠做法：先
file.Stat()拿Size()，再调w.Header().Set("Content-Length", strconv.FormatInt(size, 10)) - 注意：如果文件在 copy 过程中被并发修改（如日志轮转），
Size()可能不准，此时宁可不用Content-Length，改用chunked并确保 handler 不 panic - 千万别在
io.Copy后再写 header——Go 的http.ResponseWriter一旦开始写 body，header 就锁定了，会静默忽略
Scanner 用于日志行推送时，token too long 错误怎么防
scanner: token too long 不是文件大，是某一行超长（比如嵌了 base64 的 trace 日志），撑爆了默认 64KB 缓冲。错误发生在 scanner.Scan() 内部，不查 scanner.Err() 就捕获不到，后续所有行都会被跳过。
立即学习“go语言免费学习笔记（深入）”；
- 必须提前调
scanner.Buffer(make([]byte, 64*1024), maxLineLen)，例如支持最长 512KB 行：scanner.Buffer(make([]byte, 64*1024), 512*1024) -
scanner.Text()返回的字符串底层复用缓冲区，下一次Scan()就覆盖——推送到 HTTP 流时若需保留原始行内容，得立刻拷贝：append([]byte{}, scanner.Bytes()...) - 不可控输入（如用户上传的日志）慎用
Scanner；换reader.ReadBytes('\n')更可控，错误可明确判断是否 EOF 或 I/O 中断
写完没响应？Flush 和 Close 的顺序陷阱
用 bufio.NewWriter(w) 包裹 http.ResponseWriter 是常见误区：它会让响应延迟，甚至因未 flush 导致客户端永远收不到数据。
-
http.ResponseWriter本身不实现io.WriteCloser，调w.Close()无意义，且bufio.Writer的Close()会先Flush()再 close 底层 writer——但底层是 responseWriter，close 操作被忽略 - 正确做法：不用
bufio.Writer包 responseWriter；直接io.Copy(w, reader)，或手动读写时用w.Write()，无需额外缓冲 - 如果非要缓冲（比如加压缩中间件），必须显式调
w.Flush()，且不能 defer——panic 或提前 return 会导致 flush 被跳过
最易被忽略的是：网络推送场景下，缓冲区大小不是越大越好，而是要匹配客户端接收节奏；还有就是 Scanner 的缓冲复用机制，不拷贝 Bytes() 直接传指针，线上可能看到“上一行内容出现在下一行里”的诡异现象。
