文件打开失败时需区分错误类型：用os.IsNotExist(err)判断是否创建默认配置，用os.IsPermission(err)提示权限问题；os.ReadFile替代已弃用的ioutil.ReadFile，但需注意大文件内存限制。
文件打开失败时，os.Open 返回的 error 不能只判 nil
很多新手看到 os.Open 返回 error 就只写 if err != nil，但实际中要区分错误类型：是文件不存在（os.IsNotExist(err)），还是权限不足（os.IsPermission(err)），或是路径是目录却当文件打开（os.IsNotExist(err) || os.IsPermission(err) 可能掩盖后者）。这些判断直接影响重试逻辑或用户提示。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.IsNotExist(err)判断是否该创建默认配置文件 - 用
os.IsPermission(err)提示“请检查文件读取权限”而非泛泛的“打开失败” - 避免直接打印
err.Error()给终端用户——它可能含绝对路径或系统细节
ioutil.ReadFile 已弃用，改用 os.ReadFile 并注意内存限制
ioutil.ReadFile 在 Go 1.16+ 已被标记为 deprecated，应切换至 os.ReadFile。二者行为一致，但后者归属更清晰。真正容易踩坑的是：它会把整个文件读进内存，对大文件（如 >100MB）可能触发 OOM 或显著拖慢 GC。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 小配置文件（os.ReadFile 最简洁
- 处理日志、导出数据等大文件时，改用
os.Open+bufio.Scanner或io.Copy流式处理 - 若必须全量读取大文件，先用
os.Stat检查Size()，超阈值则提前返回错误
写文件时，os.Create 和 os.OpenFile 的标志位差异影响错误语义
os.Create 等价于 os.OpenFile(name, os.O_RDWR|os.O_CREATE|os.O_TRUNC, 0666)，它总会清空原文件。而很多场景需要“仅追加”或“存在则失败”，这时必须用 os.OpenFile 显式传参，否则错误类型会变：比如用 os.Create 打开只读挂载点，报错是 permission denied；而用 os.OpenFile(name, os.O_WRONLY|os.O_CREATE, 0644)，可能报 read-only file system，更贴近真实原因。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 写日志用
os.OpenFile(name, os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644) - 原子写入配置文件，先写临时文件再
os.Rename，避免写到一半崩溃导致损坏 - 写入前检查父目录是否存在，用
os.MkdirAll(filepath.Dir(name), 0755)，否则open /path/to/file: no such file or directory实际是目录缺失
关闭文件的 Close 错误常被忽略，但它可能携带关键信息
很多人认为 f.Close() 只是释放资源，错误可忽略。但某些文件系统（如 NFS、FUSE）在 close 阶段才真正提交写入，此时若磁盘满、网络断开，Close 会返回非 nil error。跳过它等于静默丢数据。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有显式
os.Open/os.Create后，务必检查Close返回值，尤其写操作 - 用
defer f.Close()时，无法直接处理其 error——应改用defer func() { if err := f.Close(); err != nil { /* 记录或上报 */ } }() - 使用
os.WriteFile这类封装函数时，它内部已处理Close，无需额外调用
文件 I/O 错误处理最麻烦的不是语法，而是每个 error 背后对应的真实系统状态——文件是否存在、权限如何、存储介质是否就绪、挂载选项是否限制操作。不深挖 os.Is* 系列函数和具体 syscall 错误码，很容易把“磁盘只读”当成“路径错”。
