defer 中 panic 会覆盖主函数原始 error；应包裹清理函数并检查 err、记录日志而不 panic；多错误用 errors.Join 聚合；context.Cancel 不自动清理资源；需查文档确认 Close 行为。
defer 里 panic 会吞掉原始错误
Go 的 defer 是关资源的常用手段，但很多人没意识到：如果 defer 中调用的清理函数本身 panic（比如 file.Close() 在文件已损坏时返回非 nil error 并触发 log.Fatal），它会覆盖主函数原本要 return 的 error。这不是“优雅”，是掩盖问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远别在
defer里直接调用可能 panic 或需要 error 处理的函数；用匿名函数包裹并显式检查err - 若清理操作失败，应记录日志（
log.Printf），但不 panic、不 return、不覆盖主流程 error - 典型反例：
defer f.Close()—— 看似简洁，实则丢错误；正例：defer func() { if err := f.Close(); err != nil { log.Printf("close failed: %v", err) } }()
多个资源需关闭时，错误不能简单丢弃
打开文件 + 启动 goroutine + 获取数据库连接，三者都可能失败。如果只返回第一个 error，后续资源泄漏或未清理，调试时根本看不出是哪个环节出问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
errors.Join()（Go 1.20+）聚合多个 error，它保留所有底层 error 信息，且支持errors.Is()和errors.As() - 不要用字符串拼接 error（如
fmt.Errorf("a: %v, b: %v", errA, errB)），会丢失类型和栈信息 - 若需兼容旧版本 Go，可用第三方库如
github.com/hashicorp/errwrap，但优先升级 Go 版本 - 示例：
var errs []error; if err := f.Close(); err != nil { errs = append(errs, err) }; return errors.Join(errs...)
context.WithCancel 配合 defer 不等于自动清理
有人以为 ctx, cancel := context.WithCancel(context.Background()); defer cancel() 就能“自动”终止所有子 goroutine，其实 cancel 只是发信号，是否响应、何时响应、是否清理资源，全看你自己写的 goroutine 逻辑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
cancel()本身不关网络连接、不关 channel、不关文件 —— 它只是让ctx.Done()变成 closed channel - 每个长期运行的 goroutine 必须主动 select 监听
ctx.Done()，并在退出前调用对应资源的 Close 方法 - 若 goroutine 持有可关闭资源（如
http.Client、*sql.DB），应在收到 cancel 后显式调用其Close()或类似方法，不能依赖 GC
io.ReadCloser 和 net.Conn 的 Close 行为差异
io.ReadCloser 是接口，不同实现对 Close() 的语义不同：有些只关读端（如 gzip.Reader），有些关整个连接（如 net/http.Response.Body）。误判会导致连接泄漏或 double-close panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远查文档或源码确认具体类型
Close()的行为；例如http.Response.Body.Close()会关底层 TCP 连接，而bytes.Reader的Close()是空操作 - 对
net.Conn类型，Close()后再读写会报"use of closed network connection"，但不会 panic；而 double-close 在某些平台会 panic - 若封装了自定义
ReadCloser，务必在Close()中只 close 一次，并置内部字段为 nil，避免重复调用
defer，而是判断哪些资源必须关、关几次、关完还剩什么状态——这些没法靠工具自动推导，得看上下文。 
