Go 命令行任务怎么接收退出信号并保存进度

长时间运行的 Go 命令行任务，最怕用户按下 Ctrl+C 后进程直接消失：已经做完的任务没有记账，下一次启动只能从头猜。更稳妥的做法是用 signal.NotifyContext 接收 os.Interrupt 和 syscall.SIGTERM，把退出请求传给任务循环；循环停止接收新任务，等当前项完成后，把最后一个完整检查点写入磁盘。

先决定用哪种退出信号方案

如果任务只需要“收到退出请求就收尾”，NotifyContext 是最短路径：它返回一个会被取消的 Context 和一个必须调用的 stop 函数。若业务必须知道具体收到的是 SIGINT 还是 SIGTERM，才考虑 signal.Notify 加缓冲通道；手动 context.WithCancel 则适合内部按钮、测试或管理接口触发的取消。

把退出信号转换成可传播的 Context

下面的例子把任务抽象成 12 个编号。ctx.Done() 只负责通知，不负责替你保存数据；因此每轮开始前检查一次，当前任务执行期间也把 ctx 传给可以取消的下游操作。

package main

import (
    "context"
    "encoding/json"
    "errors"
    "fmt"
    "os"
    "os/signal"
    "path/filepath"
    "syscall"
)

type checkpoint struct {
    Completed int `json:"completed"`
}

func main() {
    // SIGINT 对应 Ctrl+C，SIGTERM 常见于服务管理器停止进程。
    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
    defer stop() // 任务收尾后恢复信号行为并释放相关资源。

    cp, err := loadCheckpoint("checkpoint.json")
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }

    for cp.Completed 

这个示例的关键不是让 processOne 立刻停止，而是把“已完成”定义在函数成功返回之后。任务返回取消错误时，不能把当前编号提前加一，否则下一次启动会跳过尚未完成的工作。

取消后怎样保存最后一个完整检查点

建议把检查点设计成可重放的业务事实，例如已成功提交的批次号、文件偏移或最后一个稳定主键，而不是“当前正在处理的编号”。写入时先生成临时文件，关闭文件后再用 os.Rename 替换正式文件；这样启动时读到的要么是旧的完整状态，要么是新的完整状态。

如果进度要写数据库，原子性应交给数据库事务；如果要写多个文件，还要考虑目录级提交或日志。信号处理只能告诉程序“该收尾了”，不能把多个外部系统自动变成一个事务。

区分正常完成、主动停止和失败重试

读取 ctx.Err() 可以区分主动取消与正常完成；业务错误则应该保留失败位置并返回非零退出码。下一次启动时只加载已确认提交的检查点：

// 从检查点恢复，completed 表示已经成功提交的任务数量。
start := cp.Completed + 1
for taskID := start; taskID 

正常跑完时检查点等于总数；收到 SIGTERM 时则停在最后一个成功值；处理失败时不应为了“看起来有进度”而写入成功。三种状态都可以在日志中明确打印，便于调度器决定重试还是人工介入。

几个容易忽略的退出边界

• 不要漏掉 stop：NotifyContext 的 stop 会撤销信号行为并释放关联资源，主函数结束前用 defer stop()，收尾完成后也可以尽早调用。
• 不要让信号通道无缓冲：如果使用旧式 signal.Notify，官方示例建议为只接收一个信号的通道留出至少一个缓冲位，并在结束时 signal.Stop(ch)。
• 不要把第二次 Ctrl+C 当成数据保存机制：第一次信号应触发可控收尾；更强制的退出策略应由进程管理器或明确的超时控制实现。
• 不要假设所有阻塞都能被 Context 打断：只有下游真正读取 ctx，取消才会传播；不可取消的调用需要超时、独立进程或其他隔离方案。

常见问题

signal.NotifyContext 会自动保存进度吗？

不会。它只关闭返回 Context 的 Done 通道；进度文件、数据库事务和重试策略仍由业务代码负责。

为什么调用了 NotifyContext，任务还是继续运行？

通常是任务函数没有读取 ctx，或循环在一次不可中断的同步调用里停留太久。把 ctx 传入下游，并在循环边界检查取消。

保存 checkpoint.json 时进程又被终止怎么办？

使用同目录临时文件写完并关闭，再替换正式文件。这样最多回退到上一个完整检查点，不会把半截 JSON 当成新状态。

把退出信号当作“停止领取新工作”的请求，再把检查点定义为“已经成功完成的事实”，命令行任务就能在 Ctrl+C、SIGTERM 和下一次启动之间保持清晰边界。官方 os/signal 文档还特别说明了 stop 的资源释放职责，实际接入时不要省略它。