文件写入失败（如磁盘满、Ctrl+C）不触发panic，而是返回error，故recover无效；应通过error判断、defer清理和signal监听实现安全中断处理。
文件写入过程中的 panic 不该靠 recover 拦截，而应靠 error 判断 + defer 清理 + 信号感知来应对中断
为什么 recover 捕获不了 Ctrl+C 或磁盘满导致的写入失败
Go 的 panic 只由程序内部错误（如空指针、切片越界）触发，而文件写入失败（如 write: no space left on device、broken pipe、interrupted system call）全部走 error 返回路径，不会触发 panic。你写个 defer func() { recover() }() 完全没用——它连一次都不会被调用。
常见误判是把系统级中断（比如用户按 Ctrl+C，或容器被 kill -15）当成 panic。其实这些会发 SIGINT/SIGTERM 信号，Go 默认行为是终止进程，但不会经过 panic 流程。
- 写入返回
err != nil是常态，必须用if err != nil显式处理 -
recover()对os.WriteFile、file.Write等返回的错误完全无效 - 真正需要 recover 的场景极少：比如你在写入前动态生成了非法 UTF-8 字符串，又用
json.Marshal导致 panic —— 这属于编码逻辑 bug，不是 I/O 中断
如何正确响应 Ctrl+C 或 kill -15 并安全停止写入
关键不是“恢复写入”，而是“及时释放资源 + 避免脏数据”。需用 os/signal 监听信号，在收到中断时主动关闭文件句柄、退出 goroutine。
立即学习“go语言免费学习笔记（深入）”；
示例：一个持续追加日志的 goroutine
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func startLogger(filename string) {
f, err := os.OpenFile(filename, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
log.Fatal(err)
}
defer f.Close()
sigs := make(chan os.Signal, 1)
signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM)
go func() {
<-sigs
log.Println("received interrupt, closing file...")
f.Close() // 确保 flush 和释放 fd
os.Exit(0)
}()
for {
_, err := f.Write([]byte("log line\n"))
if err != nil {
log.Printf("write failed: %v", err)
return // 不重试，不 panic
}
time.Sleep(time.Second)
}
}
- 不能依赖
defer f.Close()单独收尾：Ctrl+C 会直接终止主 goroutine，defer来不及执行 - 必须显式监听
SIGINT/SIGTERM，并在 handler 中调用f.Close() - 写入失败后不要
panic，应记录错误并退出或降级（比如切到内存 buffer）
写入中途崩溃时，如何保证文件不损坏
Go 本身不提供原子写入或事务回滚，得靠策略规避：用临时文件 + os.Rename 替换，这是唯一能接近“要么全写完、要么原样保留”的方式。
典型流程：
- 写入到
out.txt.tmp - 调用
os.Rename("out.txt.tmp", "out.txt")—— 在同一文件系统下是原子操作 - 若程序在 rename 前崩溃，
out.txt.tmp可被清理，out.txt不受影响
注意：os.Rename 跨文件系统会失败，此时需 fallback 到 copy + remove；且 Windows 下对打开的文件 rename 会报错，要确保目标文件未被占用。
recover 在文件操作中唯一合理的使用场景
仅限于你明确知道某段代码可能 panic（比如第三方库调用、反射、模板渲染），且你愿意为它兜底——但绝不用于 I/O 错误本身。
例如：你用 text/template 渲染日志内容，模板里用了未定义变量，会 panic：
func writeWithTemplate(f *os.File, data interface{}) error {
defer func() {
if r := recover(); r != nil {
log.Printf("template render panic: %v", r)
}
}()
t := template.Must(template.New("log").Parse("{{.Msg}}\n"))
return t.Execute(f, data)
}
- 这个
recover是为了防止模板错误拖垮整个写入流程 - 但它不解决磁盘满、权限不足等真实 I/O 问题——那些仍要靠
err != nil处理 - recover 后不能继续写入原文件，因为状态已不确定；应返回错误并让上层决定是否重试或切换输出目标
最易被忽略的一点：哪怕你做了所有信号监听和临时文件保护，只要没在写入前检查磁盘空间（unix.Statfs）或提前预分配 buffer，就仍可能在 Write 调用中途被系统 kill —— 此时唯一能做的，是接受“部分写入”并设计好下游的数据校验机制。
