channel管道必须用for range持续消费，不能只接收一次val := <-ch，否则会丢失后续数据、导致goroutine泄漏或阻塞；所有消费者（含中间环节）都须用for range ch安全读取。
channel 管道必须用 for range 持续消费，不是收一次就完事
写完 val := 就以为数据流跑起来了？实际只取第一个值，后续全丢，goroutine 还卡在那儿等下一个——这是最常被忽略的泄漏源头。管道里每个 stage 都得持续读、处理、转发，<code>for range ch 是唯一安全方式。
- 错误现象：下游只收到 1 条数据就停住；
panic: send on closed channel；CPU 空转但无输出 - 所有消费者（包括中间过滤、转换环节）都必须用
for range ch，不能写for { select { case v, ok := 然后漏掉 <code>ok == false后的退出逻辑 - 上游关 channel 的时机要准：必须等所有数据发完、且确认下游已读完才
close(ch)；如果某 stage 过滤掉部分数据，仍要确保输出 channel 被关闭，否则下游range永远等不到 EOF - 多个 stage 必须用不同 channel，别共用一个
chan interface{}—— 类型混杂、生命周期难控、无法单独调优缓冲
缓冲大小不是越大越好，要和下游吞吐对齐
设 make(chan Event, 10000) 看似保险，实则掩盖真实瓶颈：当 handler 处理变慢，消息在 channel 里堆积，新事件被丢弃，OOM 前毫无预警。缓冲不是保命符，而是背压调节器。
- 无缓冲
chan：make(chan T)，天然同步，适合强顺序、低延迟场景（如实时风控决策） - 有缓冲时，容量 = 入流速率 × 单条平均处理耗时 × 安全余量。例如 Kafka 每秒推 500 条、单条耗时 8ms，则理论积压上限为 4，
make(chan Event, 8)足够 - 有缓冲 channel 必须配超时：
select { case ch ，避免 goroutine 永久阻塞 - 别用
chan []byte直接传大 payload；改传*Event或 ID，再异步加载，减轻 GC 压力
Kafka 消费必须关自动提交，手动控制 offset 提交时机
默认 config.Consumer.Offsets.AutoCommit.Enable = true 是丢数据的温床：消息刚推到 channel 就提交 offset，万一 handler panic 或崩溃，这条消息永远丢失。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 关掉自动提交：
config.Consumer.Offsets.AutoCommit.Enable = false - 只在业务逻辑成功后显式提交：
consumer.CommitOffsets([]*sarama.OffsetCommit, nil)，建议每 10 条或每 2 秒批量提交一次 - 务必启用错误通道：
config.Consumer.Return.Errors = true，否则consumer.Errors()不吐错，故障静默 - 消费 goroutine 内部必须
recover()，否则 panic 导致整个 consumer loop 退出，后续消息全卡住 - 启动位点选
sarama.OffsetOldest（不丢历史）还是sarama.OffsetNewest（只处理最新之后），取决于你的语义需求
HTTP SSE 和 gRPC 流式通信要防连接断开与 buffer 积压
SSE handler 返回后连接断开、gRPC 流越推越慢甚至 OOM，问题不在协议本身，而在应用层没做连接健康检查和流控配合。
立即学习“go语言免费学习笔记（深入）”；
- HTTP SSE：禁用 HTTP/2 流复用不够，还要设
w.Header().Set("Connection", "keep-alive")；每次推送前检查if f, ok := w.(http.Flusher); ok { f.Flush() }，否则数据卡在 buffer - gRPC 流式通信：HTTP/2 底层有窗口流控，但默认窗口太大（65535 字节），高吞吐下仍会撑爆内存；应用层需配合
context超时 +select非阻塞写入 + 服务端主动限速（如每秒最多 push N 条） - 客户端断连时，
stream.Context().Done()会触发，此时必须清理对应 goroutine 和 channel，否则泄漏持续累积 - 别在 handler 里狂打
log.Print—— I/O 阻塞会拖慢整个流，改用异步日志或采样输出
真正的难点不在语法，而在于判断哪一环该丢数据、哪一环必须重试、哪个 channel 缓冲该设成 0 —— 这些没标准答案，得看你的 SLA：是宁可延迟也要不丢，还是宁可丢旧也要保新。
