信号分发

Go 中，同一信号可以通过 signal.Notify 注册到多个不同 channel，各通道独立接收通知副本；它们并不是抢同一条消息。漏收应优先排查通道没有缓冲、缓冲已满、注册太晚或进程提前退出。若多个 goroutine 读取的是同一个 channel，则一次发送只能由其中一个接收，不能据此实现广播。

对于“收到一次退出请求就足够”的场景，每个独立订阅通道可以从容量 1 开始设计。对于“每次信号都要精确计数”的需求，不能把信号通知当作可靠消息队列。

官方文档：https://pkg.go.dev/os/signal

先区分独立订阅与同一通道竞争

排查时先画出实际通道对象，而不只是看变量名。两个变量引用同一个 channel，仍然属于共同消费；分别 make 两个 channel，再分别 Notify，才是独立订阅。

用两个带缓冲的通道接收一次通知

下面的演示只观察一次 os.Interrupt。它先完成两次注册，再启动接收者，并等待两者都结束。示例未在本文制作过程中运行，打印内容仅由代码定义，不作为运行记录。

package main

import (
    "fmt"
    "os"
    "os/signal"
    "sync"
    "time"
)

func main() {
    noticeA := make(chan os.Signal, 1)
    noticeB := make(chan os.Signal, 1)
    // 两次注册完成后，再允许外部发送用于演示的中断。
    signal.Notify(noticeA, os.Interrupt)
    signal.Notify(noticeB, os.Interrupt)
    defer signal.Stop(noticeA)
    defer signal.Stop(noticeB)

    var wg sync.WaitGroup
    receiveOne := func(name string, c 

将代码保存到独立演示项目，构建并直接运行程序；看到“订阅已就绪”后，在该程序所在前台发送一次 Ctrl+C。终端、IDE 和包装进程可能影响信号送达对象，因此应确认观察的是实际程序。两个接收者的打印顺序不应写入断言。

容量 1 的作用是容纳一次尚未被消费的通知，而不是让两个接收者串行等待信号。如果主函数只等 A 收到后立即返回，B 即使已经有通知，也可能来不及完成工作。因此，漏掉日志和没有收到通知是两种不同现象。

缓冲容量不能代替消费设计

signal 包向通道投递时不会等待接收者腾出空间。无缓冲通道在没有接收者准备好的时刻存在漏收风险；有缓冲通道填满后也不能无限积累。慢消费者不会因此给另一个独立通道提供补偿。

消费循环应尽快取走通知，把耗时任务交给有明确并发和合并策略的业务层。比如重载配置时，可以表达“需要再重载一次”的状态，而不是在信号接收循环内无限阻塞。这个取舍减少了对瞬时通知次数的依赖，但不提供逐条事件存档。

调大缓冲只能容纳更多待处理通知，不能保证外部每一次发送都对应一次业务处理。需要确认、重试与精确计数的任务，应使用有响应的接口、IPC 或适合的消息机制，并定义自己的协议。

把停止订阅交给通道拥有者

每个订阅者退出时调用 signal.Stop(c)。Stop 返回后，signal 包不再向该通道投递；但它不会替调用方关闭通道，也不会自动清空之前已入缓冲的通知。消费者还需要自己的结束条件。

不要在 signal 包仍可能发送时直接 close 通道。上面的单次演示无需关闭通道，交给函数结束后回收即可。长期运行的组件若还有其他发送者或接收者，应由拥有者统一安排它们停止，不能只调用 Stop 就认为所有 goroutine 都已结束。

对同一个 channel 多次 Notify 会扩展订阅集合，不会创建多个独立通道。解除该 channel 的订阅使用 Stop；它不是只撤回最近一次 Notify 的“减一”操作。组件只想停止自己时，应操作自己拥有的 channel，避免使用影响同一信号整体行为的全局操作。

多个模块退出时可改成状态广播

若两个模块都只需要知道“服务正在退出”，独立信号订阅通常不是唯一选择。可以由主入口通过 NotifyContext 取得取消状态，将同一个 Context 传给模块，再等待各模块的完成回报。这样模块观察的是持久的取消状态，无需分别消费同一信号事件。

Context 的取消仅是通知，仍不表示模块已经清理完成。主入口需要单独等待完成结果，并给清理设置合理的时间限制。NotifyContext 返回的 stop 也要按拥有关系调用，用来释放信号订阅资源。

独立 Notify 更适合需要观察具体信号值的组件；统一取消状态适合整组任务共同退出。选用哪种结构，应看接收需求，而不是简单地认为通道越多越可靠。官方实现可参考：https://go.dev/src/os/signal/signal.go。

常见问题

两个 channel 中一个收得慢，会阻塞另一个吗？

signal 的投递不等待通道空间；慢通道可能漏通知。各自独立不等于慢通道可以无限缓存。

Stop 之后还能读出一条旧通知吗？

可能。停止新投递不等于清空已有缓冲，应用需明确如何处理遗留通知。

只收到一次退出信号，能让所有模块都退出吗？

可以把退出设计成共同的取消状态，再等待模块分别完成。不能让所有模块竞争读取同一条 channel 消息，并期待它们都取得这条消息。