defer 不能直接用 os.Close() 是因为若 file 为 nil（如 os.Open 失败未检查），defer file.Close() 会 panic；正确做法是先判空再 defer，且多个文件需按打开逆序释放，并优先使用 io.ReadCloser 等接口统一管理。
defer 为什么不能直接用 os.Close()？
因为 defer 执行时，文件句柄可能已经失效或被提前关闭——比如在函数中途 return 前没显式调用 Close()，或者多个 defer 依赖同一变量但作用域混乱。最常见错误是这样写：
file, err := os.Open("data.txt")
if err != nil {
return err
}
defer file.Close() // 看似正确，但若后续操作 panic 或 return，这里仍会执行；问题不在这里，而在更隐蔽处...
真正风险在于：如果 file 是 nil（比如 os.Open 失败后未检查就 defer），file.Close() 会 panic。所以必须先判空。
带错误检查的 safe defer 模式
释放文件资源的关键不是“有没有 defer”，而是“defer 的对象是否有效、是否允许重复调用”。os.File.Close() 本身是幂等的（多次调用无副作用），但前提是 file != nil。
- 总是先检查
err，再决定是否 defer - 避免对可能为 nil 的
*os.File直接 deferClose() - 如果打开失败，
file是 nil，此时 defernil.Close()会 panic
正确写法：
file, err := os.Open("data.txt")
if err != nil {
return err
}
defer func() {
if file != nil {
file.Close()
}
}()
多个文件资源怎么 defer？顺序很重要
Go 中 defer 是 LIFO（后进先出），和调用栈逆序。如果你同时打开读写两个文件，释放顺序反了可能引发资源竞争或逻辑错误（比如先关写入句柄，但读取还没完）。
- 按「打开顺序相反」的顺序释放，通常符合资源依赖关系
- 不要把多个
defer file.Close()写在一起，容易混淆谁对应谁 - 对每个文件单独做非空检查 + defer，比统一写一个闭包更清晰
示例：
src, err := os.Open("input.txt")
if err != nil {
return err
}
defer func() { if src != nil { src.Close() } }()
dst, err := os.Create("output.txt")
if err != nil {
return err
}
defer func() { if dst != nil { dst.Close() } }()
用 io.ReadCloser 和 io.WriteCloser 统一管理
当封装成函数或方法时，返回接口类型比裸指针更安全。例如 os.Open 返回 *os.File，它实现了 io.ReadCloser；但你传参时应尽量用接口，避免暴露具体类型。
- 接收参数用
io.ReadCloser而非*os.File，调用方可以传bytes.Reader、gzip.Reader等，统一用Close() - 函数内部不假设实现类型，只调用
Close()，自然兼容 defer - 注意：有些
io.ReadCloser实现（如http.Response.Body）必须 Close，否则连接不释放
典型模式：
func process(r io.ReadCloser) error {
defer r.Close() // 安全，因为 r 不可能是 nil（调用方保证）
// ...读取逻辑
}
文件资源释放最麻烦的从来不是语法，而是「谁负责关、什么时候关、关之前还剩多少数据没读完」——defer 只解决“一定执行”，不解决“执行时机是否合理”。尤其在错误路径、early return、panic 场景下，要靠显式判空和闭包包裹来兜底。 
