os.exit() 会跳过所有 defer，导致文件写入丢失；必须将写文件作为显式 cleanup 步骤，在信号处理中调用后再退出。
直接用 os.Exit() 会跳过所有 defer，包括文件写入逻辑，数据必然丢失。必须把“写文件”作为显式清理步骤，放在信号捕获之后、进程退出之前执行。
为什么 defer f.Write() + os.Exit() 不行
常见误区是：打开文件 → defer f.Close() → 中间写点东西 → 收到 SIGINT 后调用 os.Exit(0)。这会导致：
-
os.Exit()立即终止进程，defer根本不执行，哪怕你写了defer f.Write()也无效 - 即使用了
defer func(){ f.Write(...) }()，它依然依赖函数返回，而os.Exit()不走返回路径 - goroutine 里开的文件，主 goroutine 退出后整个进程消失，其内部
defer永远不会触发
正确做法：把写文件放进 cleanup 函数，由信号驱动
核心是把“写入最终状态”当作一个同步、可等待、不可跳过的步骤，而不是靠延迟执行机制。示例流程：
- 启动时创建临时文件或状态文件句柄（比如
stateFile, _ := os.Create("/tmp/app.state")） - 定义
cleanup()函数，里面做：stateFile.Write([]byte("shutdown: true\n"))→stateFile.Sync()→stateFile.Close() - 在信号处理分支中，先调用
cleanup()，再等待其他任务结束，最后让main自然返回
注意：Sync() 必须显式调用，否则写入可能还卡在内核缓冲区；Close() 错误也要检查，不能只写不看返回值。
多个文件或写入失败时怎么保底
如果程序要写多个文件（如日志快照 + 状态文件 + PID 文件），且其中一个失败，不能让整个退出卡住或静默忽略：
- 每个文件写入后都检查
err，失败时记录日志但不return或panic，继续下一个 - 用
defer func() { ... }()包裹单个Close()，避免覆盖主错误，例如：defer func() { if cerr := stateFile.Close(); cerr != nil { log.Printf("failed to close state file: %v", cerr) } }() - 对关键文件（如数据库 checkpoint 文件），可加重试逻辑：
for i := 0; i
context 超时下写文件被中断怎么办
如果你在 cleanup() 里用了 context.WithTimeout() 控制整体退出时间，要注意：文件 I/O 本身不响应 ctx.Done()。这意味着：
-
os.File.Write()是阻塞系统调用，不会因ctx取消而提前返回 - 不要把
Write()放进带select的循环里等ctx.Done()—— 它不支持 - 真正可控的是「给写入留多少时间」：在超时 context 触发前，单独为写操作预留窗口，例如：
writeCtx, writeCancel := context.WithTimeout(ctx, 2*time.Second) defer writeCancel() _, err := stateFile.Write(buf) if err != nil && !errors.Is(err, context.DeadlineExceeded) { log.Printf("write failed: %v", err) }但注意：这个context.DeadlineExceeded实际上不会从Write()返回，只是示意你该限制总耗时
最稳妥的方式，是把写文件放在所有耗时协程 WaitGroup 等待之后、退出前的最后一环，并用独立计时器兜底，避免因磁盘卡顿导致整个服务无法退出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
