流式处理应避免strings.Split或一次性strings.NewReader转切片，因其会导致内存暴增和GC压力；推荐用bufio.Scanner包裹strings.Reader并调用scanner.Buffer设置缓冲区。
别用 strings.Split 或一次性 strings.NewReader 转切片——流式处理的核心是让数据“过一遍就走”，不驻留、不累积。
为什么不能把大字符串先 split 再遍历
看似简单：把整个字符串 strings.Split(s, "\n") 成切片，再 for range 处理。但问题立刻暴露：
- 如果原始字符串含 100 万行，
split会分配 100 万个string头（每个 16 字节）+ 底层数组指针，内存开销远超原文本本身 - 哪怕字符串只有 10MB，split 后的切片可能触发 GC 压力，尤其在高频调用场景下
- 你根本不需要所有行同时存在——绝大多数业务只需逐行解析、过滤、转发或计数
用 bufio.Scanner 包裹 strings.Reader 是最稳解法
这是标准库唯一既安全又轻量的“字符串流”模拟方式，底层复用缓冲区，避免重复 alloc。
- 必须显式调用
scanner.Buffer(make([]byte, 4096), 1 ——否则默认 64KB 缓冲上限，遇到含 base64 的长行直接 panic <code>scanner: token too long - 用
scanner.Text()获取当前行（返回拷贝，安全）；若需原字节操作（如跳过 BOM、校验 CRC），改用scanner.Bytes() - 最后一行没换行符？
scanner.Scan()在 EOF 时仍返回该行，无需额外判断err == io.EOF
reader := strings.NewReader(largeString)
scanner := bufio.NewScanner(reader)
scanner.Buffer(make([]byte, 4096), 1<<20) // 关键：设最大长度为 1MB
for scanner.Scan() {
line := scanner.Text() // 或 scanner.Bytes()
processLine(line)
}
if err := scanner.Err(); err != nil {
// 处理扫描错误（如缓冲区溢出）
}
管道场景下慎用 io.Pipe，优先选 chan string + io.Reader 组合
当你需要把字符串流喂给下游 io.Copy、json.Decoder 或 HTTP body 时，io.Pipe 表面简洁，实则容易卡死：
立即学习“go语言免费学习笔记（深入）”；
-
io.Pipe的写端阻塞在无读端消费时，若下游处理慢或 panic，整条链就 hang 住 - 无法控制缓冲区大小，写入速度远超读取速度时，内存持续上涨
- 真正轻量的方案是：启动 goroutine 逐行
fmt.Fprintln到bytes.Buffer或自定义io.Writer，再用bytes.NewReader提供io.Reader
更推荐直接构造一个可复用的 func() io.Reader 工厂：
func stringLinesReader(lines []string) io.Reader {
var buf bytes.Buffer
for _, line := range lines {
buf.WriteString(line)
buf.WriteByte('\n')
}
return &buf
}
——但注意：这仅适用于已知行列表；对真正“无限流”，必须用 scanner + goroutine + channel 拆流。
并发拆流时，chan []byte 比 chan string 更省内存
如果你在 pipeline 中做多阶段处理（如：解析 → 过滤 → 序列化），每层都用 string 传递，每次赋值都会复制底层字节；而 []byte 只传 header，零拷贝。
- 上游 scanner 用
scanner.Bytes()直接发[]byte到 channel - 下游处理完后，若需转 string（如日志打印），只在必要处做
string(b)转换 - channel 容量建议设为 1–4，避免 buffer 积压；配合
select+default实现非阻塞丢弃
真正难的不是怎么拆，而是怎么让每一环都不囤积、不等待、不意外泄漏——字符串流的高效，本质是节奏感。
