<p>Go中不能用闭包直接实现安全的发布者模式，因闭包会掩盖channel关闭、goroutine泄漏、竞态等问题；真正可用方案是使用单向通道（chan<- / <-chan）配合显式生命周期管理。</p>
Go 里不能用闭包直接实现安全的发布者模式，尤其当涉及多 subscriber、异步消费、生命周期管理时，闭包会掩盖 channel 关闭、goroutine 泄漏、竞态等核心问题。真正可用的方案是：用单向通道（chan）做发布接口，把闭包限制在初始化阶段，而非消息分发逻辑中。
为什么 chan
看到 chan 或 <code>chan 包裹函数值，基本可以判定设计已偏离 Go 并发哲学。闭包捕获的变量（如 <code>map、slice、*struct）一旦被多个 goroutine 并发调用，极易触发 fatal error: concurrent map writes；更隐蔽的是，闭包引用的栈变量可能已回收，而接收方还在调用 —— 这类 panic 往往只在高负载下偶发，调试成本极高。
-
func() { m[key] = val }若m是共享 map，无 mutex 就是裸奔 - 闭包里用了
time.AfterFunc或http.Client.Do，但没绑定独立context.Context，超时/取消无法传递 - 发送方关闭 channel 后，接收方仍可能从
chan 中取出已失效闭包并执行
正确做法：发布者只暴露 chan
发布者对外只提供一个只写单向通道（chan、<code>chan），所有订阅逻辑由消费者自行决定——是起 goroutine 处理，还是同步调用，或是转发到其他系统。这样发布者完全不感知 handler 生命周期，也不参与执行。
- 定义不可变事件类型：
type Event struct { Topic string; Payload []byte; Timestamp int64 }，避免传指针 - 发布者结构体只含
pub chan 字段，构造时由外部传入（比如来自 <code>make(chan Event, 100)） - 发布方法仅做非阻塞发送：
select { case p.pub ，绝不阻塞调用方 - 关闭责任明确交给 channel 创建者（通常是启动发布者的顶层 goroutine），发布者自身不调用
close()
闭包该用在哪？仅限初始化上下文
闭包唯一安全的使用位置，是启动 consumer goroutine 时捕获不变量 —— 比如配置、连接池、logger 实例。它不参与消息路由，也不封装业务逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
go func() { for e := range ch { handler(e) } }()——handler是闭包，但若它内部修改共享状态，就引入竞态 - 正确写法：
go func(logger *zap.Logger, db *sql.DB) { for e := range ch { process(e, logger, db) } }(log, db)—— 闭包只固定依赖，process是纯函数或方法 - 每个 subscriber 的 goroutine 都应有独立
context.WithTimeout，不能复用同一个ctx，否则一个超时会 kill 全部
Unsubscribe 必须 close 对应 channel，且 goroutine 要退出
如果用 chan Event 为每个 subscriber 分配独立管道，Unsubscribe 不只是从 map 删除 key，必须显式 close(ch)，并确保 consumer goroutine 能检测到关闭后退出。
- consumer 必须用
for e := range ch，而不是for { e := —— 前者在 channel 关闭后自动退出循环 - 若 consumer 内部还有 select 等待其他 channel（如
done），需在case 分支里检查是否为零值，并配合 <code>ok判断：if e, ok := - 切忌在
Subscribe返回的函数里直接go f()—— 这会让外部无法控制 goroutine 生命周期，泄漏风险极高
最易被忽略的点：发布者和订阅者之间没有“执行权”交接。只要把函数值、闭包、handler 当作消息内容来传递，就等于把同步责任推给接收方，而 Go 的 channel 本身不提供执行语义 —— 它只负责传递数据。真正的安全，来自清晰的职责切割：发布者管投递，订阅者管执行，中间用不可变数据和单向通道划清边界。
