Go函数错误主要源于编译失败、error忽略、defer覆盖命名返回值、error包装不当；可通过静态检查、固定模式及工具（如errcheck、gofmt）规避。
Go 函数错误绝大多数不是运行时 panic，而是编译失败、返回值被忽略、命名返回值被 defer 覆盖、或 error 包装不当——这些都可通过静态检查和固定模式规避。
函数编译失败：看报错行号 + 括号/逗号/字符串闭合
Go 编译器报错非常直接，但新手常因格式混乱错过关键线索。比如 ./main.go:23:5: expected ';', found 'if'，实际问题往往不在第 23 行的 if，而在它前面某行少了个右括号 } 或结构体字面量漏了逗号。
- 结构体初始化、map 字面量、切片字面量中，**最后一个字段后必须加逗号**，否则换行后下一行被误判为新语句
- 字符串用双引号开头就必须用双引号结束；反引号（
`）包裹的原始字符串不能含未转义的换行或` - 用
gofmt -w main.go格式化后，缩进错位、括号不成对会立刻暴露
error 返回值被忽略：编译不报错但逻辑崩溃
Go 不强制检查 err，所以 _, err := os.Open("x"); doSomething() 这类写法能通过编译，但一旦 os.Open 失败，doSomething 拿到的是 nil 文件句柄，后续调用立即 panic。
- 禁止用
_丢弃非空 error：哪怕只是log.Printf("warn: %v", err)也比什么都不做强 - HTTP handler、goroutine 入口等非顶层函数里，
if err != nil后必须return，不能只打日志 - 用
errcheck ./...工具可批量扫描未检查的 error 返回值（需提前go install github.com/kisielk/errcheck@latest）
defer 中 Close() 错误被吞：资源泄漏的隐形推手
defer f.Close() 看似稳妥，但 Close() 本身可能返回 error（如磁盘满、网络断连），而 defer 不传播也不中断执行，这个 error 就彻底丢失了。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 不要在 defer 里写
if err := f.Close(); err != nil { ... }——它捕获的是外层作用域的err变量，不是Close()自己的 - 若函数有命名返回值（如
func() (err error)），defer 内部再赋值err = e会覆盖原始错误（比如 Open 失败本该返回 open error，结果被 close error 覆盖） - 推荐做法：显式调用一次
Close()并检查；或封装为closeSafely(f)，内部用log.Printf记录但不修改返回值
error 包装链断裂：errors.Is 判断永远 false
用 fmt.Errorf("load config: %v", err) 替代 %w，会导致原始错误类型丢失。例如 errors.Is(err, fs.ErrNotExist) 在包装后始终返回 false，业务兜底逻辑就失效了。
- 只有
%w才支持错误链追踪；%v、%s、字符串拼接都会切断链 - 包装前务必判空：
if err != nil { return fmt.Errorf("xxx: %w", err) }，否则%w会 panic - 跨包传递错误时，优先在模块边界（如函数出口）包装一次补业务上下文，避免多层嵌套（>3 层）导致调试困难
最易被忽略的一点：Go 的 error 是值，不是异常；它的处理粒度在「每次调用之后」，而不是「整个函数块」。少一次 if err != nil，就可能让一个可恢复的 I/O 错误演变成不可恢复的 panic。
