Go 信号处理后程序为什么没有退出

已经打印“收到信号”，程序仍在运行，通常说明你只结束了信号接收 goroutine，没有让 main 的等待结束。注册 os/signal 通知后，指定信号不再直接沿原来的默认路径终止进程；应用必须把退出意图传给工作任务，再让 main 完成清理并返回。

另一类问题发生在通知送达之前：无缓冲通道或没有及时接收可能漏掉通知。要分开检查“有没有收到”“有没有停止工作”“main 是否还在等”，不能只靠加一条退出日志下结论。官方文档地址：https://pkg.go.dev/os/signal。

日志出现收到信号，不代表 main 已经返回

考虑一个后台任务程序：单独的协程接收中断，记录日志后 return，但 main 仍停在 select {} 或另一个永远不会关闭的通道上。协程中的 return 只结束那个协程。Go 程序在 main 返回时退出，不会因为某个普通 goroutine 返回而退出，也不会在 main 返回后自动等其他协程收尾。

因此第一项检查是找到 main 的最后一个等待点。若是 WaitGroup，谁负责 Done？若是完成通道，谁负责关闭？若是服务的阻塞调用，谁负责停止该服务？信号处理器的日志只证明到了该代码位置，不能回答这些问题。程序入口规则见 https://go.dev/ref/spec#Program_execution。

核对信号注册和通道接收条件

用 Notify 时，信号包不会为了发送通知阻塞等待你的接收者。若只是需要一次退出通知，容量 1 的通道是常见起点；它不是无限事件队列，也不保证每次连续信号都被保存。

// 局部片段：注册前准备缓冲，结束使用时取消该通道的订阅。
signals := make(chan os.Signal, 1)
signal.Notify(signals, os.Interrupt, syscall.SIGTERM)
defer signal.Stop(signals)
sig := 

这个片段需要 os、os/signal、syscall 导入，面向 Linux/macOS。Signal.Stop 不会关闭 signals，不能在 Stop 之后等待 range 通道自动结束；若还有接收协程，另行给它退出通知。不要在仍订阅时自行关闭信号通道。

先确认注册的是实际发送的信号、发送目标是业务进程 PID，而不是外层 shell、启动工具或旧进程。本文不执行任何发信号命令；读者应在自己的测试进程中检查。SIGKILL 和 SIGSTOP 无法被 Go 信号处理器捕获，不可拿它们测试清理逻辑。

用 NotifyContext 把退出意图交给 main

如果需求只是收到指定信号后停止，NotifyContext 能减少自建接收通道的协调代码。它在信号到达、父 context 取消或 stop 被调用时关闭 Done，所以 Done 关闭并不总能证明来自某一种信号。下面完整示例面向 Linux/macOS、Go 1.16 及以上；示例未在本文运行。

package main

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

func worker(ctx context.Context) {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop() // 工作协程持有的计时器由它自己清理。
    for {
        select {
        case 

ctx 同时提供给工作任务和 main；done 表示工作任务结束；timer 只给 main 的等待设上限。它不会强制让 worker 的阻塞 I/O 返回。这个示例的 worker 自身没有实际阻塞业务；替换成网络或数据库操作后，必须使用相应的 context、deadline 或资源关闭机制。

stop 解除的是本次注册。没有其他同信号订阅且启动前信号行为正常时，后续中断可以恢复默认处理；其他库仍订阅、继承了忽略状态或嵌入非 Go 程序等情形，不能保证第二次信号一定强制退出。它也不会等待 worker，等待责任仍在 done。

已经取消仍不退出，就看清理和等待对象

如果 Done 已关闭而 done 还没收到，问题已经不在信号有没有送达，而在工作任务是否响应取消。重点查阻塞读取、无接收者的发送、锁等待、忘记 Done 的任务和耗时清理。只给外层传 context，不会自动取消不认识它的底层调用。

清理函数若需要一段独立的退出时间，不要直接用已经取消的信号 context 当作清理请求的唯一上下文；根据业务创建单独的有期限 context，并调用其 cancel。已有连接、监听器和文件由谁关闭也必须明确，不能让两个协程互相等待对方先退出。Context 契约见 https://pkg.go.dev/context#Context。

若直接在信号接收协程调用 os.Exit，进程确实会退出，但其他协程没有机会正常收尾，defer 不会由 os.Exit 执行。上例只在 run 已返回错误后选择非零退出码，并明确超时意味着可能丢失清理；不能把这种兜底称为优雅退出。相关契约：https://pkg.go.dev/os#Exit。

用明确的终止条件复查修复

在读者自己的测试进程中，正常分支应能观察到工作结束、main 返回以及进程消失；超时分支应报告失败，不能输出“所有任务清理完成”。还应覆盖清理变慢与任务阻塞的情形，而不是只试一个空循环。这里列的是预期与检查方法，不是实际测试报告。

把信号通道改成容量 100 能解决不退出吗？

不能。增加缓冲只改善通知暂存，不会终止工作或解除 main 的等待，也不能当成可靠事件计数。

为什么 signal.Stop 后接收协程仍然挂着？

Stop 取消订阅，不关闭你的通道。接收协程若没有独立停止条件，仍可能阻塞在接收上。

Windows 可以直接复制 SIGTERM 示例吗？

不能把 Unix 信号假设直接照搬。Windows 的中断和控制事件行为要按 os/signal 的平台章节处理；示例中的 SIGTERM 方案明确限定 Linux/macOS。

最终需要修复的不是一条日志，而是信号订阅、协作取消、完成通知、等待期限和 main 返回之间的责任连接。