Go程序需显式调用signal.Notify并前置到主goroutine长期运行逻辑前，用带缓冲chan os.Signal接收SIGINT/SIGTERM等信号，否则进程直接终止跳过defer等清理；须持续读取通道并手动处理退出逻辑。
Go 程序不调 signal.Notify 就收不到 SIGINT 或 SIGTERM，按 Ctrl+C 或 kill -15 会直接终止进程，所有 defer、连接关闭、日志 flush 全部跳过。
signal.Notify 必须显式调用且放对位置
signal.Notify 不是注册回调，它只是把内核信号转发到你给的 channel。它本身不阻塞、不清理、不退出——这些全得你手动安排。
- 必须在主 goroutine 启动长期运行逻辑（比如
http.ListenAndServe、for循环）之前 调用，否则信号可能在监听注册前就已到达，被内核静默丢弃 - 不能写在
go func() { ... }()里然后让main立即返回，那样整个进程立刻退出，监听 goroutine 根本没机会调度 - 别只写
signal.Notify(sigChan)：它默认只监听SIGINT和SIGQUIT，漏掉SIGTERM是生产环境高频翻车点（Kubernetes、systemd 发的都是它）
通道必须带缓冲且持续读取
用 make(chan os.Signal, 1) 是硬性要求。无缓冲通道在第一次信号到达时就会阻塞；缓冲区大于 1 则容易掩盖设计缺陷（比如 goroutine 挂了没人读，信号越积越多）。
- 必须是
chan os.Signal类型，用chan int或chan string接收会静默失败 - 不能只写一次
sig := 就结束——后续信号写入满缓冲后会被 Go 运行时静默丢弃 - 正确做法是用
for range sigChan或for { sig := 持续消费 - 缓冲设为 1 已足够：信号是事件通知，不是数据流；我们只需要知道“有事发生了”，不需要记录历史
收到信号后不能直接 os.Exit
在 signal handler goroutine 里调 os.Exit 是典型陷阱：它跳过所有 defer、不关闭 listener、不 flush 日志、不等数据库连接归还，还会导致 panic: send on closed channel（因为其他 goroutine 还在往已关 channel 写）。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是让主 goroutine 自己控制退出流程：收到信号后发通知（比如 close
donechannel 或设原子标志），主流程检查状态、调server.Shutdown、等资源释放、再统一os.Exit -
server.Shutdown必须配超时 context，例如ctx, cancel := context.WithTimeout(context.Background(), 25*time.Second)，否则可能无限等待卡住的 DB 查询或 HTTP client 请求 - 所有外部调用（DB、HTTP、RPC）必须显式传
ctx并设 timeout，不能依赖默认值；否则Shutdown一定等不到它们
多信号怎么区分处理但共用一个通道
一个 chan os.Signal 可以同时监听 SIGINT、SIGTERM、SIGHUP 等多个信号，但处理逻辑要按语义拆开：终止类信号走关机流程，配置类信号走重载流程，混在一起会逻辑耦合、难测试。
- 注册时写
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM, syscall.SIGHUP)，别漏syscall导入 - 在
for循环里用switch sig分支判断：case syscall.SIGINT:、case syscall.SIGTERM:、case syscall.SIGHUP: -
SIGHUP和SIGUSR1适合做热重载，但重载逻辑也得异步、非阻塞，不能在 signal handler 里做耗时操作（如 HTTP 请求、文件读写） - 绝对不要监听
syscall.SIGKILL（信号 9）——它根本捕获不到，写了也白写
最容易被忽略的是信号注册时机和 channel 缓冲：它们不报错，但会让程序在线上「看起来能停，实际一杀就丢数据」。真要验证，别只 Ctrl+C，一定要用 kill -15 $PID 模拟真实环境。
