Go 程序收到 SIGINT/SIGTERM 后出现“interrupted system call”错误，是因为标准库函数（如 http.Server.Shutdown、os.Stdin.Read）在信号中断时返回 context.Canceled 或 syscall.EINTR；这非 panic，但需手动捕获信号、触发优雅关闭并等待操作完成；signal.Notify 必须持续监听而非单次读取，以防丢失信号。
Go 程序收到 SIGINT 或 SIGTERM 后为什么常出现 interrupt 错误？
因为 Go 的标准库（比如 net/http.Server.Shutdown、os.Stdin.Read、time.Sleep）在被信号中断时，会主动返回 context.Canceled 或 syscall.EINTR 包装的错误，常见表现为：accept: interrupted system call 或 read: interrupted system call。这不是 panic，而是正常行为——但若不处理，会导致服务“卡住”或连接未清理就退出。
关键点在于：Go 不自动重试被中断的系统调用，也不自动关闭监听器；你得自己捕获信号、触发优雅关闭流程，并等待正在运行的操作完成。
用 signal.Notify 捕获信号时，为什么不能只监听一次？
信号是异步事件，只调用一次 signal.Notify 并读取一次通道，很可能错过后续信号（比如用户连按两次 Ctrl+C）。必须持续监听，直到程序真正退出。
- 用
for循环持续从信号通道读取，而非单次select - 监听
os.Interrupt（对应SIGINT）和syscall.SIGTERM（Kubernetes 停止容器常用） - 避免在信号处理函数里做耗时操作（如写日志到磁盘），应只发通知、设标志或关 channel
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)
go func() {
<-sigChan // 第次信号
log.Println("shutting down...")
shutdownCh <- struct{}{}
}()
http.Server.Shutdown 调用后为什么还会报错？
Shutdown 是非阻塞的：它立即关闭 listener，拒绝新连接，但不会等已有请求结束。如果直接退出，正在处理的 HTTP 请求可能被强制中断，导致客户端收不到响应、中间件（如日志、metric）状态错乱。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须传入带超时的
context.Context，例如context.WithTimeout(context.Background(), 10*time.Second) - 调用
Shutdown后要wait，即检查返回的 error —— 如果是context.DeadlineExceeded，说明有请求超时未结束，需考虑是否强制终止 - 注意：若 server 还没启动（
ListenAndServe没开始），Shutdown会返回ErrServerNotStarted，需判空
如何让 goroutine 和资源清理不漏掉？
信号到来时，除了 HTTP server，还有后台任务（如定时器、数据库连接池、消息消费者）需要协调退出。靠全局变量或裸 channel 容易遗漏或竞态。
- 统一用一个
context.Context（如context.WithCancel(parentCtx)）分发给所有子 goroutine - 每个长期运行的 goroutine 开头加
select { case ，并在退出前清理资源（如 <code>db.Close()、consumer.Close()） - 不要依赖
defer在 main 函数末尾清理 —— 因为 main 可能早于 goroutine 结束而退出 - 特别注意：
time.Ticker必须显式Stop()，否则 goroutine 泄漏
最易忽略的是：多个 shutdown 步骤之间没有顺序依赖判断。比如 DB 连接池关闭前，HTTP handler 还在查库，就会 panic。所以 shutdown 顺序很重要：先停新请求（server.Shutdown），再等活跃请求结束，最后关依赖资源（DB、Redis、Kafka consumer）。
