直接写string到io.Writer会内存爆炸，因为[]byte(s)强制完整拷贝100MB字节，触发高频GC甚至OOM；应优先用io.WriteString（零拷贝、调用WriteString方法），或unsafe.Slice分段构造只读[]byte视图。
为什么直接写 string 到 io.Writer 会内存爆炸？
Go 中 string 是只读的，底层指向不可变字节数组。当你把一个 100MB 的 string 传给 w.Write([]byte(s))，[]byte(s) 会触发一次完整内存拷贝——不是引用，是实打实复制全部字节。对大字符串做流式输出时，这直接让 GC 压力飙升，甚至 OOM。
真正该做的，是避免一次性转 []byte，而是按需切片、分段写入：
- 用
unsafe.String+unsafe.Slice（Go 1.20+）绕过拷贝，构造零分配的[]byte视图 - 或手动用
string的底层结构（reflect.StringHeader）构造切片（需//go:linkname或unsafe，慎用） - 更稳妥的做法：用
io.WriteString—— 它内部做了优化，对string直接调用底层 write 方法，不额外分配
io.WriteString 真的比 w.Write([]byte(s)) 快且省内存？
是的，而且差距明显。因为 io.WriteString 是专门针对 string 的写入优化入口，它会尝试调用 w 的 WriteString 方法（如果实现了），否则才 fallback 到 Write([]byte)。标准库中 bufio.Writer、os.File、bytes.Buffer 都实现了 WriteString，完全避免 []byte 转换开销。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远优先用
io.WriteString(w, s)，而不是w.Write([]byte(s)) - 若要写子串（如从位置
start到end），别拼新string：io.WriteString(w, s[start:end])即可 —— Go 运行时保证切片 string 不拷贝底层数据 - 注意：
s[start:end]仍是一个合法string，长度为end - start，底层数据未复制
大字符串分块写入时，bufio.Writer 的 Flush 时机怎么控？
盲目调 Flush() 会导致频繁系统调用，影响吞吐；不调又可能卡住数据，延迟高或丢失（尤其在 panic/exit 前）。关键不是“要不要 flush”，而是“什么时候 flush”。
推荐策略：
- 设置合理缓冲区大小：
bufio.NewWriterSize(w, 64*1024)（64KB），避免小块写放大 - 每写完逻辑单元（比如一个 JSON 对象、一行日志、一个协议帧）后调
bw.Flush() - 不要在循环内每次写都
Flush；也不要等整个 1GB 字符串写完再Flush - 最后必须显式
bw.Flush()，否则末尾数据滞留在 buffer 中 - 如果写入目标支持
io.Seeker或需要精确偏移（如写文件头），记得bw.Reset前先Flush
用 strings.Reader 做流式读取再写入，是不是多此一举？
不是多此一举，而是明确语义和边界控制的必要手段。当你有一大段 string，想以流方式“喂”给下游（比如 HTTP 响应体、加密 writer、压缩 writer），strings.Reader 提供了标准 io.Reader 接口，天然适配所有期望 io.Reader 的函数（如 io.Copy、gzip.Writer 的 Write）。
好处在于：
- 无需自己实现
Read方法，strings.Reader已经高效处理偏移、EOF、并发安全 - 配合
io.CopyN可精确控制写入字节数（比如只传前 1MB） - 与
io.MultiReader组合，能拼接多个string流而不拼接内存 - 注意：
strings.Reader底层仍持有原string引用，不会拷贝，所以它本身是零分配的
真正容易被忽略的是：大字符串生命周期必须长于 strings.Reader 的使用期，否则逃逸分析失败或出现悬垂引用 —— 如果源 string 来自局部变量且没被其他地方引用，运行时可能提前回收。稳妥做法是确保该 string 是包级变量、常量，或明确逃逸到堆上（比如作为函数返回值传出去）。
