管道模式比单goroutine串行快，因其通过channel实现I/O与CPU计算错峰并行：读取下一批数据时上一批正解析，解析完即发往写入协程，无需等待落盘；channel天然缓冲解耦，但缓冲区过小会阻塞读取、过大易OOM；需三段独立goroutine配合带缓冲channel，并用sem:=make(chan struct{}, N)控制活跃并发数防压垮下游。
为什么用 channel 实现管道比单 goroutine 串行快
因为 I/O（如读文件、解析 JSON、写数据库）和 CPU 计算（如结构体转换、校验）天然可以错峰：读取下一批数据时，上一批正在解析；解析完立刻发给写入协程，不用等磁盘落盘。channel 天然承担缓冲和解耦角色，但buffer size设太小会卡住读取，太大则内存浪费甚至 OOM。
常见错误是直接用 for range 无缓冲 channel 接收，导致解析协程一阻塞，整个流水线就停摆。实际要分三段独立 goroutine + 带缓冲 channel：
-
reader：从文件/HTTP 流中批量读[]byte或string，发到inCh chan []byte -
parser：从inCh收，反序列化为[]User等结构体，发到outCh chan []interface{} -
writer：从outCh收，批量调db.Exec或log.Printf
如何控制并发数避免压垮下游
不是“越多 goroutine 越快”。比如写 PostgreSQL，连接池默认只有 10，开 50 个 writer 协程只会排队等连接，还增加调度开销。关键在限制「活跃」协程数，而不是总 goroutine 数。
推荐用带缓冲的 channel 当信号量：
立即学习“go语言免费学习笔记（深入）”；
sem := make(chan struct{}, 10) // 最多 10 个 parser 同时跑
for _, line := range lines {
sem <- struct{}{} // 获取令牌
go func(l string) {
defer func() { <-sem }() // 归还令牌
parsed := parseLine(l)
outCh <- parsed
}(line)
}注意：sem 必须在 goroutine 外定义，且 defer 写法要确保 panic 时也释放；若用 sync.WaitGroup 控制总数，容易漏 Done() 导致主流程 hang 住。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
怎么处理解析失败的数据不中断整条流水线
流水线里一个 json.Unmarshal panic，整个 goroutine 就退出，后续数据全丢。必须在每个环节加 recover，但不能简单 log 后忽略——得把错误上下文传出去，供后续重试或告警。
建议定义统一错误通道：
type ParseError struct {
Line string
Err error
Offset int
}
errCh := make(chan ParseError, 100)
// 在 parser 中：
if err := json.Unmarshal(data, &u); err != nil {
errCh <- ParseError{Line: string(data), Err: err, Offset: i}
return // 跳过这条，继续下一条
}错误通道要独立缓冲，否则 writer 卡住会导致 parser 也卡；同时主流程需另起 goroutine 消费 errCh，比如写入本地 error.log 或发 Sentry。
什么时候该用 sync.Pool 缓存解析中间对象
如果每条记录都 new 一个 map[string]interface{} 或 bytes.Buffer，GC 压力会明显上升，尤其 QPS > 1k 时。但 sync.Pool 不是银弹：对象生命周期必须可控，且类型要固定。
典型适用场景：
- 反复使用的
json.Decoder（绑定到bytes.Reader） - 预分配的
[]byte缓冲区（如固定 4KB） - 解析后暂存的
struct{}指针（需确保不逃逸到全局）
不适用情况：含指针字段的结构体（Pool 无法保证内存安全）、生命周期跨 goroutine（比如从 parser 传到 writer 后才释放）。用之前先跑 go tool pprof 看 heap profile，确认 runtime.mallocgc 是瓶颈再加。
