go中无开箱即用推荐系统框架，核心依赖channel+goroutine管线、sarama kafka消费控制及业务逻辑隔离；chan缓冲需匹配下游吞吐，如500条/秒、8ms/条时设为8，过大反致丢数据与oom风险。
Go 没有“开箱即用的推荐系统框架”，所谓“基于框架”容易误导——真正起作用的是 channel + goroutine 构建的处理管线、sarama 消费 Kafka 的可靠性控制、以及业务逻辑层对特征和模型调用的隔离设计。硬套框架反而会增加背压失控、状态不一致、热更新卡死等风险。
chan 缓冲大小怎么设才不丢数据也不 OOM
缓冲不是越大越稳，而是要和下游处理吞吐对齐。比如 Kafka 消费端每秒拉 500 条，单条平均处理耗时 8ms，理论积压上限是 500 × 0.008 = 4 条，make(chan Event, 8) 就够（留一倍余量）。设成 1000 看似保险，实则掩盖真实瓶颈：当 handler 处理变慢，消息在 channel 里堆积，新事件被丢弃，OOM 前毫无预警。
- 无缓冲
chan：适合强顺序、低延迟场景（如实时风控决策），写入即阻塞，天然限速 - 有缓冲
chan：必须配合select { case ch ，不能无条件写入 - 别用
chan []byte直接传大 payload；改传*Event或 ID，再异步加载，避免 GC 压力
sarama 消费 Kafka 时如何避免丢消息
默认配置下丢消息是常态：config.Consumer.Offsets.AutoCommit.Enable = true 会让 offset 在消息推到 channel 后立刻提交，一旦 handler panic 或崩溃，这条消息就永远丢失。
- 关掉自动提交：
config.Consumer.Offsets.AutoCommit.Enable = false - 手动提交必须在业务逻辑成功后：
consumer.MarkOffset(msg, "")，建议每 10 条或每 2 秒批量提交一次 - 务必启用错误通道：
config.Consumer.Return.Errors = true，否则consumer.Errors()不吐错，故障静默 - 消费 goroutine 内部必须
recover()，否则 panic 导致整个 consumer loop 退出，后续消息全卡住
实时特征聚合怎么做到秒级更新又不锁死
用一个全局 sync.Map 存用户行为计数，QPS 上千时 CPU 会卡在 CAS 重试上。更稳的做法是分片 + 定时快照：
- 把 key 哈希到 64 个分片：
shards[hash(key)&63]，每个分片用独立sync.RWMutex - 聚合写入只操作对应分片，读汇总时遍历全部分片（可异步）
- 用
time.Ticker每 5 秒触发一次快照，不是等数据攒够——“实时”是时间驱动，不是数量驱动 - 窗口清理别用
for range全扫，改用container/list存TimedValue，插入时sort.Search定位过期位置，只删头部
HTTP SSE 输出推荐结果时为什么总断连
SSE 不是普通 HTTP 请求，它得保持连接长期打开。断连常见原因是：http.ResponseWriter 被提前关闭、日志阻塞、未设超时、或中间代理（如 Nginx）主动 kill 连接。
- 响应头必须设全：
header.Set("Content-Type", "text/event-stream")、header.Set("Cache-Control", "no-cache")、header.Set("Connection", "keep-alive") - 每次写入后调
flusher.Flush()，且确保 flush 不被日志或中间件阻塞 - 服务端设
http.Server.ReadTimeout和WriteTimeout，但不要设IdleTimeout（SSE 就该 idle） - Nginx 配置需加：
proxy_buffering off;、proxy_cache off;、proxy_read_timeout 3600;
真正的难点不在“怎么搭”，而在“怎么控”：入口流量怎么限、中间态怎么稳、失败怎么降级、模型热更新怎么不卡 pipeline。这些没法靠框架自动解决，得靠对 channel 行为、sarama 生命周期、HTTP 连接状态的精确拿捏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
