go 通道是“一次性消费”机制，同一数据只能被一个接收者读取；若需多个协程响应同一事件，需借助观察者模式等显式分发机制，而非直接并发接收同一通道。
go 通道是“一次性消费”机制，同一数据只能被一个接收者读取；若需多个协程响应同一事件，需借助观察者模式等显式分发机制，而非直接并发接收同一通道。
在 Go 中，通道（chan）本质上是一个同步/异步的消息队列，其核心语义是：发送到通道的数据，仅能被一个 goroutine 成功接收一次。这并非 bug，而是 Go 并发模型的设计哲学——强调明确的所有权转移与通信安全。您原代码中 watcher 和 watcher2 同时阻塞在 上，但当 <code>timeout 发送 true 后，仅有一个 goroutine（通常是先抢到的）完成接收，另一个将永久阻塞（除非通道关闭或带超时），导致 watcher2 看似“未运行”。
❌ 错误写法：多 goroutine 直接竞争接收
go watcher(duration, data) // 竞争接收 go watcher2(duration, data) // 竞争接收 → 永远收不到
此时 data 是无缓冲通道（make(chan bool)），发送方 timeout 在 ch 处会阻塞，直到有<strong>且仅有一个</strong>接收者就绪；一旦完成，该值即从通道中消失，第二个 <code> 将无限等待。
✅ 正确方案：使用观察者模式广播事件
若需多个监听器响应同一信号（如超时通知），应由单一消费者接收原始事件，再主动分发给所有注册的观察者：
package main
import (
"fmt"
"os"
"time"
)
// 观察者接口：定义接收通知的能力
type Observer interface {
Notify(msg string)
}
// 具体观察者：可扩展为不同行为
type Watcher struct {
name string
}
func (w Watcher) Notify(msg string) {
fmt.Printf("[Watcher %s] %s\n", w.name, msg)
}
func main() {
// 创建事件通道（仅用于原始事件传递）
eventCh := make(chan string, 1) // 缓冲通道避免发送阻塞
// 注册多个观察者
watchers := []Observer{
Watcher{name: "Primary"},
Watcher{name: "Backup"},
Watcher{name: "Logger"},
}
// 启动广播中心：接收一次，分发多次
go func() {
for msg := range eventCh {
fmt.Println("→ Broadcasting event:", msg)
for _, w := range watchers {
w.Notify(msg)
}
}
}()
// 模拟触发事件（如超时）
time.AfterFunc(2*time.Second, func() {
eventCh <h3>⚠️ 关键注意事项</h3>
-
不要滥用
close(ch)替代广播：关闭通道后，所有会立即返回零值（如 <code>false），但这无法区分“真实数据”与“关闭信号”，且不适用于需多次广播的场景。 -
缓冲通道仅缓解阻塞，不解决广播问题：
make(chan bool, 1)允许发送不阻塞，但仍只能被一个接收者消费。 -
考虑
sync.WaitGroup或context：对于更复杂的生命周期管理（如取消多个监听器），建议结合context.WithCancel实现优雅退出。 - 性能提示：观察者数量极多时，分发循环可能成为瓶颈，可引入异步分发或消息中间件。
总之，理解 Go 通道的“单次消费”本质，是写出健壮并发程序的第一步。当业务需要“一对多”通知时，请主动设计分发逻辑，而非依赖通道的隐式行为。
