因为main函数返回即进程终止，signal.Notify是异步监听，信号到达时若未阻塞主goroutine并完成清理，程序会直接退出；Windows不支持多数POSIX信号，需用os.Interrupt兜底。
为什么 signal.Notify 不能直接用在 main 函数退出路径里？
因为 Go 的 main 函数返回即进程终止，而 signal.Notify 是异步监听——信号来了，你还没来得及执行清理逻辑，程序就已退出。尤其在 Windows 上，SIGINT/SIGTERM 行为不一致，甚至某些信号根本不可用，硬写跨平台信号处理大概率导致 Linux 正常、Windows 静默失败或 panic。
关键不是“能不能收到信号”，而是“收到后能否可靠阻塞主 goroutine 直到清理完成”。所以必须用包装器函数把主逻辑包起来，并主动等待信号+退出确认。
-
signal.Notify必须搭配sync.WaitGroup或chan struct{}控制生命周期，不能只靠select+os.Interrupt - Windows 不支持
SIGUSR1/SIGUSR2，连SIGTERM都是模拟的，实际应优先监听os.Interrupt和syscall.SIGINT - goroutine 泄漏常见于：清理函数里启动新 goroutine 却没加超时或等待机制
如何用包装器函数统一管理信号监听与退出流程？
核心是把业务主逻辑（比如 http.ListenAndServe）作为参数传入一个封装函数，该函数负责注册信号、启动监听、接收信号后触发关闭，并阻塞等待关闭完成。这样业务代码完全不感知平台差异。
示例包装器：
func RunWithSignalShutdown(mainFunc func() error, shutdownFunc func() error) error {
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)
// Windows 下 SIGTERM 可能无效，所以 os.Interrupt 是兜底
<pre class="brush:php;toolbar:false;">done := make(chan error, 1)
go func() {
done <p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6460" title="Golang Naming"><img
src="https://img.php.cn/upload/skill/000/000/081/179094616043400.jpg" alt="Golang Naming" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="overflowclass">Golang Naming</a>
<p class="overflowclass">Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。</p>
</div>
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 必须用带缓冲 channel（
make(chan os.Signal, 1)），避免信号丢失；信号发送时若无人接收会丢弃 -
shutdownFunc应包含资源释放（如http.Server.Shutdown）、连接等待、日志刷盘等，且需设超时（例如ctx, _ := context.WithTimeout(context.Background(), 10*time.Second)） - 不要在
shutdownFunc中调用os.Exit—— 它会绕过 defer 和 panic 恢复，导致清理不完整
Windows 上 syscall.Kill 和 os.FindProcess 为什么不能用于优雅退出判断？
因为 Windows 没有 POSIX 信号语义，syscall.Kill 实际调用的是 TerminateProcess，属于强制杀进程，和“优雅退出”目标完全冲突。而 os.FindProcess 在 Windows 上无法可靠判断进程是否仍在响应，仅能说明 PID 是否存在。
- 跨平台唯一可靠的退出触发源只有：
os.Interrupt（Ctrl+C）和用户手动发送的SIGTERM（Linux/macOS） - Windows 服务场景要用
golang.org/x/sys/windows/svc包，而不是通用信号机制 - 测试时别依赖
kill -SIGTERM $(pidof myapp)验证 Windows 行为——它根本不起作用
HTTP Server 关闭时为什么 srv.Close() 不够，必须用 srv.Shutdown()？
srv.Close() 立即关闭 listener 并中断所有活跃连接，不符合“优雅”定义；srv.Shutdown() 才会先拒绝新请求，再等待已有请求完成（或超时），是真正安全的退出方式。
-
Shutdown必须传入非空 context，否则会永久阻塞（例如context.WithTimeout(context.Background(), 5*time.Second)） - 如果主逻辑里用了
http.Serve而非http.ListenAndServe，记得在Shutdown前先ln.Close()，否则Shutdown可能卡住 - 第三方 HTTP 框架（如 Gin、Echo）通常封装了
Shutdown，但底层仍依赖标准库行为，务必查清其关闭逻辑是否真等价于http.Server.Shutdown
跨平台信号安全退出的关键不在“捕获得多”，而在“退出控得稳”——包装器函数本质是把不确定性（信号到达时机）转为确定性流程（监听 → 触发 → 等待 → 结束）。最容易被忽略的是：Windows 下压根不该指望 SIGTERM，以及任何未设超时的 Shutdown 都可能让程序 hang 在退出阶段。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
