go 的 channel + goroutine 不足以支撑高频行情分发，因缺乏解耦与背压控制；需用 sync.map 存订阅者通道、为每个订阅者启独立 goroutine 并设超时 select。
为什么 Go 的 channel + goroutine 不足以支撑行情分发
高频交易系统里，chan 直接广播行情数据看似简单，但一遇到多订阅者、不同处理耗时（比如一个做风控校验、一个写磁盘）、某订阅者卡住，整个 pipeline 就堵死。这不是并发模型不行，而是缺乏解耦和背压控制——观察者模式补的就是这一环。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map存储subscriberID → chan *Quote，避免 map 并发读写 panic - 每个 subscriber 单独起 goroutine 拉取
chan，不共享同一接收 loop - 必须设
select { case 防止单个慢消费者拖垮全局 - 别把
*Quote指针直接塞进 channel —— 一旦上游复用结构体，下游可能读到脏数据；用Quote{...}值拷贝更安全
如何让 Observer 注册时自带过滤能力
行情分发不是“全量广播”，而是“按 symbol / type / level2 depth 精准投递”。硬编码 if-else 过滤逻辑会导致 Observer 耦合严重，也难动态增删规则。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Observer 接口定义为
type Observer interface { ShouldHandle(*Quote) bool; OnQuote(*Quote) } - 注册时传入闭包：
reg.AddObserver("risk-engine", func(q *Quote) bool { return q.Symbol == "BTC-USD" && q.Level == 2 }) - 避免在
ShouldHandle里做耗时操作（如查 DB、调 HTTP），否则会拖慢整个分发循环 - 用
unsafe.Sizeof(Quote{})确认结构体大小，超过 128 字节建议只传 ID + 时间戳，由 Observer 自行拉详情
panic 后 Observer 不退出导致内存泄漏
常见错误现象：OnQuote 方法里 panic，goroutine 崩溃，但 channel 没关、引用没清，sync.Map 里残留 dead observer，持续接收行情却无人消费，内存缓慢上涨。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有
OnQuote调用必须包在defer func() { if r := recover(); r != nil { log.Warn("observer panic", "id", id) } }() - Observer 注册时提供
Done() ，主分发 loop 用 <code>select监听该 channel，关闭后主动从sync.Map中 delete - 定期运行清理协程：
go func() { for range time.Tick(30*time.Second) { reg.cleanupDead() } }()，检查各chan是否已满或阻塞
Go runtime trace 显示大量 goroutine 处于 chan send blocked
这说明下游 Observer 消费速度远低于行情到达速度，典型表现是延迟突增、丢帧，trace 中能看到几百个 goroutine 堆在 runtime.chansend。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 给每个 subscriber channel 加缓冲：
make(chan *Quote, 1024)，但别盲目调大——缓冲区越大，内存占用越高，且掩盖真实性能瓶颈 - 启用背压反馈：当 channel 缓冲区 > 80% 满时，向 Observer 发送
BackpressureEvent{Level: High}，让它降频或跳过非关键字段解析 - 用
runtime.ReadMemStats定期采样，若Mallocs每秒增长 > 50k，大概率是 Quote 对象分配太频繁，考虑对象池复用sync.Pool
真正麻烦的从来不是注册几个 Observer，而是当 200+ 订阅者里混着 C++ 低延迟策略、Python 回测模块、WebSockets 推送服务时，怎么让它们互不干扰又不丢精度——这时候，类型安全的接口契约比任何文档都管用。
