Go文件写入操作（如os.WriteFile、file.Write、io.WriteString）不会触发panic，只返回error；recover无法捕获磁盘满、Ctrl+C等系统级错误，因其本质是error而非panic。
Go 语言里，os.WriteFile、file.Write、io.WriteString 这类文件写入操作**根本不会触发 panic**，也就谈不上“捕获异常”——它们只返回 error。你试图用 recover() 拦截磁盘满、Ctrl+C、broken pipe 等问题，注定失败。
为什么 recover 对文件写入失败完全无效
文件 I/O 失败（如 write: no space left on device、interrupted system call、broken pipe）是系统调用层面的错误，Go 将其封装为 error 值返回，不经过 panic 流程。
recover() 只能捕获由 panic() 主动引发的、在当前 goroutine 栈上发生的中断。用户按 Ctrl+C 发送的是 SIGINT，内核通知进程终止，Go 运行时直接退出，不走 panic 路径。
-
os.Open("missing.txt")返回nil *os.File+ 非 nilerror；后续调用file.Read()会 panic —— 但这不是 I/O 异常，是空指针解引用 -
io.WriteString(file, "x")成功只表示写入内核缓冲区，落盘失败要等到file.Close()才暴露 - 在
defer中调用recover()却没写panic()，它永远不会被触发
正确处理文件写入失败：检查每个 error
必须显式判断每一步的 error，尤其不能忽略 Close() 的返回值——写缓存失败就发生在这里。
- 小文件优先用
os.WriteFile()：原子写入，错误集中返回，但父目录不存在仍报no such file or directory - 大文件或流式写入，用
os.OpenFile()+ 显式Close()，并在defer中检查关闭错误 - 用
errors.Is(err, syscall.ENOSPC)或os.IsNotExist(err)做类型判断，而非字符串匹配
示例：安全关闭并传播 Close 错误
file, err := os.OpenFile("log.txt", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
return fmt.Errorf("open log file: %w", err)
}
defer func() {
if closeErr := file.Close(); closeErr != nil && err == nil {
err = fmt.Errorf("close log file: %w", closeErr)
}
}()
_, writeErr := file.Write([]byte("data\n"))
if writeErr != nil {
return fmt.Errorf("write to log: %w", writeErr)
}
如何响应 Ctrl+C 或 kill -15 并安全停止写入
这不是“捕获异常”，而是监听信号、主动清理。核心目标是：避免脏数据 + 及时释放 fd + 不卡死。
- 用
signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM)接收中断信号 - 收到信号后，立即
file.Close()（确保 flush 缓冲区），然后退出 goroutine 或主流程 - 不要在 signal handler 里做耗时操作（如重试写入），只做快速清理
- 若写入在单独 goroutine 中，需配合
context.Context传递取消信号，避免 goroutine 泄漏
关键点在于：文件写入的“异常”本质是可控的系统错误，不是不可预测的崩溃。真正容易被忽略的是 Close() 的错误和信号处理中对 file.Close() 的遗漏——这两处出问题，轻则日志丢失，重则句柄泄漏、磁盘持续占满。
