bufio.scanner不适合流式无限行处理，因其默认单行上限64kb，超长行直接panic；底层切片拼接且内存不释放，长时间运行易oom；应改用bufio.reader.readbytes或readstring配合手动缓冲管理。
为什么 bufio.Scanner 不适合流式无限行处理
它默认单次扫描上限是 64KB，遇到超长行直接 panic：bufio.Scanner: token too long；底层用切片拼接，内存不释放，跑几个小时就 OOM。真要处理日志流、CDC 变更流这种理论上无限的文本源，得绕开 Scan()，自己控制缓冲和分界。
实操建议：
- 用
bufio.NewReader+ReadBytes('\n')或ReadString('\n')，手动管理 buffer 复用（Reset()） - 对每行做清洗前先做长度预检，比如
if len(line) > 10*1024*1024就丢弃或截断，防恶意长行 - 别用
strings.TrimSpace——它会复制整行；改用原地 trim：先找首尾非空白索引，再切片line[start:end]
如何安全启动并行 goroutine 读取多路文本流
不是起一堆 go func() { ... }() 就叫并行——没限速、没错误传播、没上下文取消，上游一卡，下游全堵死。关键在调度层抽象和错误隔离。
实操建议：
- 每个流用独立
context.WithCancel，上游关闭时自动终止对应 goroutine - 用带缓冲的 channel（如
make(chan []byte, 100)）做行数据中转，缓冲大小按吞吐压测调，太小易阻塞，太大吃内存 - 清洗逻辑必须封装成纯函数：输入
[]byte，输出[]byte或nil（表示丢弃），禁止在清洗里操作外部 map 或 channel - 错误统一走单独的
errChan := make(chan error, 10)，主流程 select 拦截，避免 panic 泄露
清洗规则怎么热加载又不中断流处理
硬编码正则或字符串替换规则，每次改都要重启服务，流式场景根本不可行。但直接 reload *regexp.Regexp 实例会导致并发 panic——Regexp 非线程安全。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 把规则定义为结构体，含
Pattern string和Replace string，用sync.RWMutex包一层，写时 lock，读时 RLock - 每次更新规则，都重新
regexp.Compile新实例，原子替换指针（atomic.StorePointer），旧实例由 GC 回收 - 避免在清洗 goroutine 里做
Compile——耗时且可能失败；提前编译好，只做指针切换 - 提供 HTTP 接口接收新规则 JSON，校验通过后再触发切换，失败返回 400 + 原因
怎么测出真实吞吐瓶颈是 IO 还是 CPU 清洗
本地跑着快，上线就卡，往往不是代码问题，而是没区分瓶颈类型。比如 SSD 上读 100MB/s 日志，但清洗正则太重，CPU 全占满，IO 反而闲置。
实操建议：
- 用
pprof抓/debug/pprof/profile，看火焰图里runtime.mach_semaphore_wait占比高 → IO 等待；regexp.(*Prog).Machine高 → 正则太重 - 临时把清洗函数替换成
return line，对比吞吐变化：如果提升不大，瓶颈在读取层（考虑换mmap或调整os.File.Readbuffer size） - 用
go tool trace查 goroutine 阻塞点，重点关注GC assist和chan send/receive的 wait 时间
真正难的不是并发模型，是让每一行从磁盘到清洗完成的路径上，没有一处隐式锁、没有一次意外分配、没有一个未设限的 buffer —— 这些细节漏掉一个，流跑两小时就崩。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
