go 语言无内置实时流处理引擎，但可通过 channel + goroutine 构建低延迟高吞吐链路；应优先使用无缓冲 channel 保证同步与低延迟，有缓冲时容量须匹配处理能力并配超时机制。
Go 语言本身不内置“实时流处理引擎”，但用 channel + goroutine 搭配合适的数据源适配器（如 Kafka、WebSocket、HTTP SSE），完全可以构建低延迟、高吞吐的实时数据处理链路——关键不在“有没有流框架”，而在怎么组织并发和背压。
用 channel 做数据流管道，别直接塞满
很多人一上来就 make(chan interface{}, 10000)，以为缓冲越大越“实时”。实际反而掩盖了下游处理慢的问题，导致内存暴涨或丢失最新数据。
- 默认用无缓冲
chan（make(chan T)）：天然强制同步，适合严格顺序、低延迟场景（如传感器采样点逐个校验） - 有缓冲时，容量必须和处理能力匹配：比如下游
process()平均耗时 5ms，上游每秒推 200 条，则缓冲设为make(chan T, 2)就够（200 × 0.005 = 1），再大就是积压 - 永远配超时：
select { case ch ，避免 goroutine 永久阻塞
从 Kafka 读实时数据，用 sarama 要关掉自动提交
默认 config.Consumer.Return.Errors = true 和 config.Consumer.Offsets.AutoCommit.Enable = true 看似省事，但会导致“数据已消费但处理失败，offset 却已提交”的丢数问题。
- 必须设
config.Consumer.Offsets.AutoCommit.Enable = false - 只在业务逻辑成功后，显式调用
consumer.CommitOffsets() - 注意
sarama.OffsetNewest启动位点：若想处理“最新一条之后”的数据，才用它；想不丢历史，得用sarama.OffsetOldest或手动指定 offset - 分区数量 > goroutine 数量时，一个 goroutine 处理多个 partition 是常态，别硬绑 1:1
HTTP SSE 推送实时事件，http.ResponseWriter 别提前关闭
用 Go 写 SSE 服务时，常见错误是 handler 返回后连接断开，或者日志里反复出现 write: broken pipe。
- 必须禁用 HTTP/2 的流复用：
server := &http.Server{...}; server.SetKeepAlivesEnabled(true)不够，还要在 handler 里设w.Header().Set("Connection", "keep-alive") - 每次推送前检查连接是否活跃：
if f, ok := w.(http.Flusher); ok { f.Flush() }，否则数据卡在 buffer - 别用
log.Print在 handler 里狂打日志——I/O 阻塞会拖慢整个流，改用异步日志或采样输出 - 客户端断连时，
context.Done()会触发，此时应清理对应 goroutine 和 channel
真正的难点不在语法或库调用，而在于判断哪一环该丢数据、哪一环必须重试、哪个 channel 缓冲该设成 0 —— 这些没标准答案，得看你的 SLA：是宁可延迟也要不丢，还是宁可丢旧也要保新。上线前，用 go tool pprof 看一眼 goroutine 数量和 channel 阻塞时间，比读十篇教程都管用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
