编写命令行程序时，忽略退出清理几乎等于给自己埋雷。比如程序在退出前本该把缓冲区内容写入磁盘，或者关闭一个正在写入的数据库连接，结果用户直接按下了Ctrl+C，进程瞬间终止，数据只写了一半，文件句柄也没释放。Go语言标准库提供的os/signal包可以帮我们捕获操作系统信号，但很多开发者只处理SIGINT，却忘了Ctrl+D这个同样常见的结束输入方式。实际上，当程序从标准输入读取数据时，EOF（在终端表现为Ctrl+D）也代表着一种退出指令，如果不做特殊处理，读取循环会直接结束，后续的清理代码依然可能被跳过。
本文会围绕两个典型的场景展开：交互式终端程序需要同时响应Ctrl+C和Ctrl+D；管道输入场景下EOF会先于信号到达。我们逐一分析信号监听、EOF检测、channel协同以及defer的配合方式，最终给出一个能直接复用的资源清理框架。
理解SIGINT与EOF的本质区别
SIGINT是操作系统向进程发送的一个中断信号，默认行为是立即终止进程。用户在终端按下Ctrl+C时，终端驱动会向前台进程组广播SIGINT。在Go中，只要通过signal.Notify把SIGINT注册到channel里，程序就能截获信号，自己决定后续逻辑。而Ctrl+D（或Ctrl+Z在某些系统上，但Unix系终端默认是Ctrl+D）并不会产生任何信号，它只是让终端把当前输入缓冲立即发送给程序，并且当行缓冲为空时，读取端会得到一个EOF标记。
换句话说，SIGINT是异步的、随时都可能到达的；EOF则是同步的、只会在读取标准输入时出现。如果程序使用bufio.Reader或者fmt.Scan从stdin逐行读取，那么遇到EOF后，ReadString或ReadLine会返回io.EOF错误，这是一个正常的读取终止信号，不会触发panic，也不会自动调用清理函数。很多开发者误以为EOF会让进程正常退出从而自动执行defer，实际上如果读取循环结束但主函数还没结束，清理逻辑可能处于一个不确定的执行顺序中。
正因如此，我们需要设计一个统一的退出通道，无论是收到SIGINT还是读到了EOF，都往这个通道发送一个事件，主逻辑收到事件后按部就班地完成资源清理，再退出进程。下面看几种实现路径。
用channel串联信号与EOF事件
最直接的方案是定义两个channel：一个用于接收操作系统信号，另一个用于传递EOF读取结果。主goroutine通过select监听这两个channel，一旦任意一个就绪，就进入清理流程。伪代码大致如下：
sigCh := make(chan os.Signal, 1)
signal.Notify(sigCh, syscall.SIGINT, syscall.SIGTERM)
eofCh := make(chan struct{})
go func() {
reader := bufio.NewReader(os.Stdin)
for {
line, err := reader.ReadString('\n')
if err != nil {
if err == io.EOF {
close(eofCh)
return
}
// 其他读取错误也当作退出处理
close(eofCh)
return
}
processLine(line)
}
}()
select {
case <-sigCh:
fmt.Println("收到中断信号，开始清理")
cleanup()
case <-eofCh:
fmt.Println("标准输入已关闭，开始清理")
cleanup()
}
上面这段代码有个问题：cleanup被调用两次可能造成重复释放。虽然实际情况下select只会命中一个分支，但如果两个事件几乎同时发生，另一个分支不会再次执行，因为select退出后整个main可能已经返回。但更稳妥的做法是让清理函数具备幂等性，或者使用sync.Once确保只执行一次。很多项目会选择把清理逻辑封装成一个defer调用放在主函数开头，然后select分支只负责触发退出，比如通过一个done channel来通知主流程。
还有一点要注意：signal.Notify的channel缓冲区大小建议设为1，否则信号可能被丢弃。同样，EOF的读取goroutine在完成工作后要关闭eofCh或者发送一个空结构体，主select才能感知到。如果读取循环结束但主select还没执行，那么程序会一直阻塞等待，除非用time.After兜底。
借助context实现优雅退出与超时控制
当清理步骤本身可能耗费较长时间时，直接调用cleanup()会让程序在用户按下Ctrl+C后迟迟不退出，体验很差。更合适的做法是引入context.Context，由主流程创建一个带超时的context，清理函数接收这个context，并在其中检查是否已超时。例如：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
cleanupDone := make(chan struct{})
go func() {
defer close(cleanupDone)
cleanup(ctx)
}()
select {
case <-sigCh:
fmt.Println("收到SIGINT，启动清理")
case <-eofCh:
fmt.Println("收到EOF，启动清理")
}
select {
case <-cleanupDone:
fmt.Println("清理完成，退出")
case <-ctx.Done():
fmt.Println("清理超时，强制退出")
os.Exit(1)
}
这样，即使用户连续按Ctrl+C，程序也只会触发一次清理流程，并且清理函数内部可以通过ctx.Err()判断是否需要提前终止。如果清理涉及数据库事务回滚或者大文件删除，给出超时机制能避免程序卡死。还可以设置一个全局的sync.WaitGroup来等待所有后台goroutine完成，不过对于短小命令行工具来说，直接退出也是可接受的。
在标准输入管道场景下处理EOF的特殊性
当程序通过管道接收输入时，比如cat data.txt | myprogram，EOF会在数据全部读完时立即到达，而用户一般不会按Ctrl+C。这时程序需要能够在处理完全部数据后自动执行清理并退出，而不是等待SIGINT。前面提到的channel方案天然支持这种场景，因为读取goroutine会先关闭eofCh，主select立刻触发清理。但需要注意：如果你在读取循环中使用了scanner.Scan()并在scanner.Err()为nil且Scan返回false时退出，那么退出的原因可能是EOF或者内部缓冲达到上限，最好显式判断一下。
反过来，如果程序不读取stdin，纯粹是一个后台服务，那么EOF就无从谈起，只需要关注SIGINT和SIGTERM。但很多开发者写的工具既支持交互模式又支持管道模式，那么同时监听两类事件是最稳妥的。另外，Windows系统上标准输入模拟的Ctrl+D行为与Unix不同，通常使用Ctrl+Z，Go的os.Stdin读取EOF的方式类似，但信号处理有些差异，实际开发时需要考虑跨平台兼容性。
最后提醒一点：不要在信号处理函数里做过多的业务逻辑，signal handler应该轻量快速，把真正的清理工作交给主流程或者独立的清理goroutine。保持信号channel只用来传递“该退出了”这个信息，具体的资源释放、日志打印、文件写入全部放到主流程的清理阶段，这样代码结构清晰，也便于测试。