Go os/signal 通道缓冲太小会漏掉哪些信号

在 Go 服务里，signal.Notify 接收退出信号时，channel 缓冲太小确实可能让通知消失。关键原因不是 Go 把信号“排队等待读取”，而是 os/signal 向目标 channel 发送时不会阻塞；当 channel 已满，新的通知就没有位置可放。只监听一种信号、只需要触发一次退出动作时，容量为 1 通常够用；同时监听多种信号或处理函数可能短暂变慢时，不能把 1 当成通用答案。

先看清 Notify 的丢失边界

官方文档明确说明，Notify 不会阻塞向 channel 发送。可以把它理解成一个“尽力投递”的通知入口：channel 有空位就放入信号，满了就跳过这次发送。无缓冲 channel 没有存储位，只有接收 goroutine 正好准备好时才可能接到通知，因此不适合服务启动、日志初始化或关闭清理这些存在时间窗口的场景。

还要注意，操作系统本身对同类信号也不承诺像消息队列一样逐个保留。连续收到多个相同信号时，程序通常只需要知道“退出已被请求”，而不是统计每一次 Ctrl+C。真正不能丢失的业务状态，应写入持久化队列、数据库或由应用状态机记录，不能只放在 chan os.Signal 里。

按信号范围和处理速度确定容量

容量的判断可以先用下面这张速查表：

常见的最小写法如下。代码中的 defer signal.Stop 负责在函数结束时解除注册，避免同一个 channel 在生命周期外继续接收通知：

package main

import (
    "fmt"
    "os"
    "os/signal"
    "syscall"
)

func waitForShutdown() {
    // 容量 1 用来覆盖“注册后、开始接收前”的短暂窗口。
    signals := make(chan os.Signal, 1)
    signal.Notify(signals, os.Interrupt, syscall.SIGTERM)
    defer signal.Stop(signals) // 函数结束后撤销当前 channel 的监听。

    // 这里只关心一次退出请求，不把它当作可恢复的消息队列。
    received := 

如果一个消费者每次处理信号都会执行较慢的清理逻辑，可以让接收循环先把信号转成内部状态，再由另一个流程做清理。这样 channel 的占用时间更短，但也不要盲目把容量改成很大的数字；容量越大，只是延后暴露处理跟不上，并没有增加信号的可靠性。

把接收、退出和不可丢失状态分开

对于服务退出，推荐用一个只触发一次的退出状态。多个信号到达时，第一次通知负责取消上下文，后续重复通知不再启动第二套清理流程：

ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
defer stop() // 释放信号注册和 context 关联的资源。

go func() {
    // 业务 goroutine 只观察取消状态，不直接抢读信号 channel。
    

若必须用显式 channel，至少持续消费并设置退出上限：

for {
    select {
    case sig := 

上线前用四个问题复查

第一，监听的信号是否真的需要逐个计数？若只是退出，通常应该折叠为一个状态。第二，消费者是否可能被慢 I/O、锁或长事务阻塞？如果会，先快速接收再转交。第三，缓冲容量是否只为短暂启动窗口服务，而不是掩盖永久积压？第四，必须保留的业务事件是否已经写入可靠存储？这四问能避免把“偶尔收不到退出通知”和“业务事件丢失”混成一个问题。

常见问题

无缓冲 channel 一定会漏信号吗？

不一定，但发送和接收必须同时匹配；启动或调度稍有间隙就可能没有接收者，因此生产服务不应依赖这个偶然时序。

容量设成 1 能接收 SIGINT 和 SIGTERM 各一次吗？

不能把它当成保证。两种信号都可能到达，而容量 1 只能暂存一个尚未消费的通知；如果只关心退出结果，应尽快消费并折叠状态。

把 channel 容量调到 100 是否就可靠了？

不是。它只能吸收有限的短时积压，不能解决消费者永久变慢，也不能替代数据库、队列或应用状态记录。

一句话总结：Go os/signal 的 channel 缓冲要按“通知是否可能并发到达、消费者多久取走、信号是否允许合并”来定；退出通知可以合并，关键业务事实必须另存。