Go os/signal 怎么让命令行任务优雅保存进度后退出

命令行任务收到 Ctrl+C 或 SIGTERM 后，最怕的不是“退出”，而是进度停在内存里没有落盘。比较稳的做法是：用 os/signal.NotifyContext 把信号转换成取消事件，让工作循环停止领取新任务；循环返回最后确认完成的位置；主函数再用一个有限的收尾窗口保存进度、关闭资源，最后退出。

把信号接入根 context，让工作循环知道该停

NotifyContext 返回的 context 会在指定信号到达、父 context 取消或调用 stop 时结束。对一次性命令行任务来说，os.Interrupt 对应 Ctrl+C；在 Unix-like 环境还可以加入 syscall.SIGTERM。收到信号后，工作代码只观察 ctx.Done()，这样保存逻辑仍由正常的函数调用完成。

package main

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

type checkpoint struct {
    LastDone int       `json:"last_done"`
    SavedAt  time.Time `json:"saved_at"`
}

func main() {
    // 信号只转换成取消事件，真正的保存动作放在主流程的收尾阶段。
    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
    defer stop()

    lastDone, err := run(ctx, 0)
    if err != nil {
        fmt.Fprintln(os.Stderr, "任务执行失败：", err)
        os.Exit(1)
    }

    // 收尾使用独立 context，避免原 ctx 已取消后保存函数立即失效。
    shutdownCtx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
    if err := saveProgress(shutdownCtx, "./state/progress.json", checkpoint{
        LastDone: lastDone,
        SavedAt:  time.Now(),
    }); err != nil {
        fmt.Fprintln(os.Stderr, "进度保存失败：", err)
        os.Exit(1)
    }
}

func run(ctx context.Context, start int) (int, error) {
    lastDone := start
    for item := start + 1; item 

让工作循环在取消点停止接新任务

取消检查应该放在“领取下一项”之前，并且只有 handle 成功返回后才更新 lastDone。这样中断发生在一项任务中间时，当前项不会被误记为完成；下次启动可以从保存的编号之后继续。

不要把每一项都包在一个无法取消的长调用里。如果单项工作可能阻塞，应把同一个 ctx 传给网络请求、数据库操作或等待函数。若底层函数不支持 context，至少在外层设置明确边界，并把“正在处理的项”与“已确认完成的项”分开记录。

保存最后确认的进度，再关闭资源

保存动作应放在工作函数返回之后。示例使用 JSON 只是为了说明边界，生产环境可以换成数据库事务、检查点表或其他持久化方式。关键不是格式，而是写入顺序：编码状态、写临时文件、成功后替换正式文件。若直接覆盖正式文件，进程在写入中途被终止时，下一次启动可能连旧进度也无法读取。

收尾 context 不应继续沿用已经被信号取消的 ctx，否则保存函数一进入就可能收到取消结果。示例用 context.WithTimeout(context.Background(), 5*time.Second) 给保存和资源关闭留出窗口；窗口大小要按实际写盘和关闭耗时设置，并在超时后记录失败原因。

检查 stop、重复信号和启动方式

NotifyContext 返回的 stop 既负责取消内部 context，也负责停止继续接管信号。用 defer stop() 可以覆盖正常返回和错误返回；如果保存已经完成，也可以立即调用一次 stop，让后续信号恢复默认行为。

第一次 Ctrl+C 通常应进入保存流程，第二次中断则可能意味着用户不想再等。是否立即终止要由命令的产品需求决定；不要在信号接收 goroutine 里并发改写进度文件，否则会产生多次写盘、竞争和难以判断的退出码。Windows 场景优先使用跨平台的 os.Interrupt，Unix 专用的 SIGTERM 需要按构建目标拆分。

常见问题

为什么不能在收到信号后直接调用 os.Exit？

os.Exit 不会等待 defer 执行，进度保存和资源关闭可能根本没有机会完成。更稳妥的是让信号取消工作 context，再由主流程统一收尾。

保存的进度应该是当前任务还是下一个任务？

建议保存“最后确认完成的任务编号”，下次从它之后开始。当前任务尚未完成时不要提前推进，否则可能跳过实际未落盘的数据。

为什么收尾时不能继续使用业务 ctx？

业务 ctx 已因信号结束，所有依赖它的操作都可能立即返回取消。保存阶段应创建独立且有超时的 context，并把取消原因记录到日志。