Go 中 os.Signal 捕获 Ctrl+C 有时不生效，因默认仅监听 os.Interrupt（SIGINT），忽略 SIGTERM 等信号；容器或 systemd 下常收 SIGTERM，需显式注册多个信号并使用带缓冲 channel，且 signal.Notify 必须在监听 goroutine 启动前调用。
Go 里用 os.Signal 捕获 Ctrl+C 为什么有时不生效？
因为默认只监听 os.Interrupt（即 SIGINT），而忽略 SIGHUP、SIGTERM 等常见退出信号，尤其在容器或 systemd 环境下，进程收到的往往是 SIGTERM 而非 Ctrl+C。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 显式传入多个信号：
signal.Notify(c, os.Interrupt, syscall.SIGTERM) - 避免只写
signal.Notify(c, os.Interrupt)—— 这在 Docker stop、k8s kill 场景下会卡住不退出 - 确保 channel 是带缓冲的（如
make(chan os.Signal, 1)），否则首次信号可能丢失 - 不要在
signal.Notify前启动 goroutine 监听，否则存在竞态：信号可能在监听 setup 完成前就已发出
为什么 context.WithCancel + signal.Notify 组合后，子任务仍没及时停止？
Context 只是“通知机制”，不自动终止 goroutine；你得在每个长期运行的 goroutine 内部主动检查 ctx.Done() 并退出，否则它根本不知道该停。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有阻塞操作（如
time.Sleep、http.Serve、ch ）都要配合 <code>select+ctx.Done() - 数据库连接、HTTP 客户端等要传入
ctx：比如db.QueryContext(ctx, ...)、http.NewRequestWithContext(ctx, ...) - 别在 defer 里关资源——要先响应 ctx，再清理。错误写法：
go func() { ，这无法保证业务逻辑已退出
signal.Stop 和 signal.Reset 什么时候必须调用？
仅当同一个 signal channel 多次复用（比如测试中反复启停服务），或需要临时屏蔽信号时才需干预；绝大多数常驻服务无需手动调用，反而容易误关监听。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 生产服务一般只做一次
signal.Notify，进程生命周期内不重置 - 测试中若多次启动 server，每次 start 前应
signal.Reset()，否则旧监听残留会导致 panic：signal: already watched -
signal.Stop(c)仅在明确要停掉某 channel 的监听时用，比如热重载场景切换信号处理逻辑 - 切勿在
ctx.Cancel()后顺手调signal.Stop——它和 context 无绑定关系，纯属信号层独立控制
优雅退出时，HTTP server 关闭超时设多少才合理？
没有统一值，取决于下游依赖的响应延迟和你允许的最长停机窗口；设太短会强制断连，设太长则影响发布节奏。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 默认从 5s 起步（
srv.Shutdown(ctx)的 ctx 超时），观察日志里平均请求耗时，留出 2–3 倍余量 - 对有长轮询或 WebSocket 的服务，超时至少 30s，并在 shutdown 前主动关闭新连接：
srv.SetKeepAlivesEnabled(false) - 别依赖
time.Sleep等待，必须用srv.Shutdown；直接srv.Close()会立刻中断活跃连接 - Shutdown 返回 error 不一定代表失败——
context.DeadlineExceeded表示超时，但连接可能仍在关；要结合日志确认实际连接数归零
最易被忽略的一点：信号监听和 context cancel 是两层事——前者负责“谁来喊停”，后者负责“停到哪一步”；漏掉任一环，都会让程序看似退出实则 hang 住。
