Go 文件读写错误必须显式检查，不能忽略；os.Open/os.Create后需立即判断err，区分os.IsNotExist等具体错误类型，Write/Close错误也需检查，并用%w包装错误保留上下文。
Go 文件读写错误必须显式检查，不能忽略；错误不是异常，而是返回值，不处理就会导致 panic 或静默失败。
os.Open / os.Create 后必须立刻检查 err
打开文件失败时，file 是 nil，后续调用 file.Read() 或 file.Write() 会直接 panic。这是新手最常踩的坑。
- ✅ 正确做法：每次调用后立即判断
if err != nil，并决定是返回、记录、还是 fallback - ❌ 错误写法：
file, _ := os.Open("x.txt")—— 忽略错误等于放弃诊断能力 - 注意：
os.Create在路径父目录不存在时也会失败，不是只看文件权限
file, err := os.Open("config.json")
if err != nil {
if os.IsNotExist(err) {
log.Println("配置文件未提供，使用默认值")
return loadDefaults()
}
return nil, fmt.Errorf("打开配置文件失败: %w", err)
}
defer file.Close()
区分 os.IsNotExist 和 os.IsPermission 等具体错误类型
统一用 log.Fatal(err) 打印所有错误，对运维和用户毫无帮助。不同错误需要不同响应策略。
-
os.IsNotExist(err)→ 可自动创建、提示用户初始化、或加载内置默认 -
os.IsPermission(err)→ 应明确提示“请检查文件权限或以 sudo 运行” -
errors.Is(err, syscall.ENOSPC)（需导入syscall）→ 表示磁盘已满，可清理临时目录或拒绝写入 - 避免字符串匹配错误信息（如
strings.Contains(err.Error(), "permission")），不可靠且跨平台失效
写入过程中也要检查 Write 和 Close 的错误
文件成功打开 ≠ 写入一定成功。磁盘满、NFS 挂载断开、只读文件系统等，都可能在 Write 或 Close 阶段才暴露问题。
-
Write返回n, err，即使n > 0也可能err != nil（比如部分写入后设备断开） -
Close可能触发底层 flush，尤其用bufio.Writer时，错误必须检查 - 常见误区：只 defer
Close()却不捕获其错误 —— 导致数据丢失却无感知
file, err := os.Create("log.txt")
if err != nil {
return err
}
defer func() {
if closeErr := file.Close(); closeErr != nil {
log.Printf("关闭日志文件失败: %v", closeErr)
// 注意：这里不覆盖主 err，仅记录
}
}()
_, err = file.WriteString("start\n")
if err != nil {
return fmt.Errorf("写入日志失败: %w", err)
}
用 %w 包装错误，保留原始错误链
只写 fmt.Errorf("xxx failed") 会丢掉底层错误细节（比如到底是 permission denied 还是 no such file），让调试变成猜谜。
- ✅ 使用
%w：支持errors.Unwrap和errors.Is，可精准判断原始错误类型 - ❌ 不要用
%s或fmt.Sprint(err)拼接，那只是字符串，不是可展开的错误链 - 典型场景：封装
os.ReadFile时，必须用%w包装，否则上层无法识别os.IsNotExist
真正难处理的，从来不是“怎么写错”，而是“错误发生后，你有没有足够的上下文知道它为什么发生、该不该重试、要不要告警”。少一次 %w，就少一层定位能力。
