用channel做实时数据流时，应避免直接发送大数组；写入端须加超时或非阻塞判断，如select { case ch
用 channel 做实时数据流，别直接塞大数组
Go 里实时处理不是靠轮询或定时拉取，核心是让数据“推”进来、协程“接”得住。channel 是唯一自然的流式载体，但很多人一上来就开 make(chan []byte, 1000)，结果内存暴涨或丢数据。
- 写入端必须带超时或非阻塞判断，否则生产者卡住会拖垮整个流水线：
select { case ch - 消费者别用
for range ch无脑收——一旦 channel 关闭，循环就停了；实时场景往往要持续运行，改用for { select { case x := - 缓冲区大小不是越大越好：
make(chan int, 1)适合高响应低延迟（如事件触发），make(chan int, 64)更平衡；超过 256 容易掩盖背压问题
sync.Pool 避免高频对象分配，但别在流中间层滥用
每秒几万条 JSON 日志？反复 json.Unmarshal 会触发大量小对象 GC。用 sync.Pool 复用 []byte 或结构体指针能省掉 30%+ CPU，但池子本身不是银弹。
- 只对生命周期明确、大小稳定的对象建池，比如固定结构的日志结构体；别池化
map[string]interface{}这种动态结构 - 从池取对象后必须清空字段（尤其是 slice 的
len和cap），否则上次残留数据会污染下一次处理：obj.Data = obj.Data[:0] - 池对象不能跨 goroutine 长期持有——它按 P（处理器）本地缓存，跨 P 传递等于没池
用 context.Context 控制流生命周期，而不是靠 close(ch) 硬关
实时流常驻运行，但升级、配置变更、下游故障时得优雅中断。靠 close(ch) 会让所有接收方立刻退出，无法做清理或 flush 缓冲数据。
- 所有 goroutine 启动时传入
ctx，用select { case 响应取消 - 别在多个 goroutine 里重复调用
ctx.WithTimeout——每次调用都新建一个 cancel 函数，泄漏 goroutine；统一在入口处派生一次 - 下游服务超时返回
context.DeadlineExceeded时，不要立即重试，先 sleep 再检查ctx.Err()是否已取消
JSON 流解析用 json.Decoder，别用 json.Unmarshal 解整包
实时日志、MQ 消息、WebSocket 数据大多是连续 JSON 对象流（一行一个或换行分隔），json.Unmarshal 要求完整字节切片，意味着你得攒够一整条才开始解析，延迟不可控。
- 直接包装
io.Reader到json.NewDecoder(r)，然后循环dec.Decode(&v)，它自动按 token 边界切分，一条解析完立刻进下一条 - 如果消息混在二进制协议里（如 Kafka key/value），先用
bytes.NewReader(payload)构造 reader，再传给json.NewDecoder - 注意
Decode遇到语法错误会返回io.EOF或具体错误；别把io.EOF当异常处理——它只是流结束信号
真正难的不是单点技术，而是各环节的背压传导：上游发太快，下游 decode 慢，channel 堆满，pool 分配不出新对象……这些地方不加监控和熔断，跑几天就静默降级。别等报警才看 runtime.ReadMemStats 里的 Mallocs 和 PauseNs。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
