必须检查 os.open 和 read 的 Error，因 go 无异常机制，i/o 错误通过返回值传递；忽略会导致生产环境故障，需显式判断 err 并区分 os.isnotexist、os.ispermission 等类型做精准响应。
检查 os.Open 和 Read 的 error 是唯一正解
Go 没有异常机制，I/O 异常不是“抛出来”的，而是函数返回的 error 值。忽略它，等于默认所有文件都存在、都有权限、磁盘永远不坏——这在生产环境必然翻车。
- 常见错误现象：
f, _ := os.Open("config.yaml")忽略err，后续f.Readpanic 或读到空数据却无提示 - 必须显式判断：
if err != nil后立刻决定是返回、重试、降级还是记录后跳过 -
io.EOF不是错误，是正常流程终点：要用errors.Is(err, io.EOF)判断，不能当真错误日志或 panic - 批量处理时（如遍历目录），单个文件出错不应中断整个循环，否则一个坏文件就让程序“半途而废”
用 os.IsNotExist 和 os.IsPermission 区分错误类型
只写 log.Fatal(err) 无法指导运维：到底是路径写错了？权限没配？还是 NFS 挂载掉了？区分错误类型才能做精准响应。
-
os.IsNotExist(err)→ 尝试加载默认配置、创建空文件、或提示用户检查路径 -
os.IsPermission(err)→ 记录警告并退出，避免反复重试浪费资源 -
os.IsTimeout(err)或网络文件系统场景下，可能需配合context.WithTimeout主动超时，而非等系统卡死 - 注意：
os.IsExist在os.Open中几乎不会触发（那是os.Create的事），别误用
用 defer 关闭文件，但别假设 file 一定非 nil
defer file.Close() 很优雅，但前提是 file 真的被成功创建了。如果 os.Open 失败，file 是 nil，调用 Close() 会 panic。
- 安全写法：先判断
err，再defer；或把defer放在if err == nil分支内 - 更健壮做法：用匿名函数包裹
Close并检查返回值，防止关闭失败被吞掉：defer func() { if file != nil { _ = file.Close() } }() - 不要依赖
defer来“兜底”逻辑错误：比如忘记在 error 分支 return，导致后续代码用nilfile 继续执行
小文件用 os.ReadFile，大文件必须流式读 + bufio
os.ReadFile 看似方便，但它会把整个文件一次性加载进内存。100MB 日志文件直接 ReadFile，GC 压力和 OOM 风险陡增，这不是优雅，是偷懒。
立即学习“go语言免费学习笔记（深入）”；
- 小文件（os.ReadFile 简洁安全，错误统一在一步返回
- 大文件或不确定大小：必须用
os.Open+bufio.NewReaderSize(f, 64*1024)，缓冲区设大些（默认 4KB 太小） - 写入同理：
bufio.NewWriter+Flush()能减少 syscall 次数，尤其高频写日志时效果明显 - 别自己造轮子控制
Read循环：除非你真需要精确字节控制，否则优先用Scanner或io.copy
最常被忽略的一点：I/O 异常处理不是写完 if err != nil 就完事。它必须和你的业务语义对齐——文件不存在是致命错误还是可降级？读取中断是重试一次还是放弃整批？这些决策藏在错误检查之后，而不是 error 类型本身里。