go vet 和 staticcheck 可提前发现 panic 前兆，如标签错误、类型错配、nil map/slice 操作；必须强制集成 CI 并启用 IDE 实时检查；error 必须显式处理，禁用裸 panic（仅限启动校验和严重状态不一致）；recover 仅用于顶层中间件，不可滥用；测试须覆盖 error 分支与边界输入。
用 go vet 和 staticcheck 拦住大部分 panic 前兆
很多 panic 其实是编译器不报错、但工具能提前揪出来的确定性问题。go vet 会检查结构体字段标签拼写错误、printf 动词不匹配、未使用的变量等——这些看似小问题，常在运行时触发 panic。比如 json.Unmarshal 遇到字段标签写成 json:"name" 却传了 nil 指针，或 fmt.Sprintf("%d", "hello") 这类类型错配，都可能直接 panic。
更进一步，团队应引入 staticcheck（比 golint 更严格），它能发现如 range 遍历 nil slice、copy 目标为 nil、map 未初始化就写入等高危模式。
- CI 流水线必须包含
go vet ./...和staticcheck ./...，任一失败即阻断合并 - 禁止把
go vet当“可选检查”——它不是锦上添花，而是防止运行时崩溃的第一道闸 - IDE 中启用实时
go vet提示，让开发者在写完第 3 行就看到struct field tag "json:xxx" not compatible with reflect.StructTag.Get
error 处理必须显式分支，禁用裸 panic
Go 的哲学是 “errors are values”，不是 exception。团队规范里要明确：任何业务逻辑路径中，只要函数返回 error，就必须有显式的 if err != nil 分支，且该分支不能只打日志就丢弃——要么返回、要么重试、要么降级，但绝不能沉默。
裸 panic 只允许出现在两类地方：程序启动时不可恢复的配置校验失败（如数据库连接字符串为空），或内部状态严重不一致（如 switch 分支穷举后 default panic）。其他所有场景，包括第三方库返回的 error、HTTP 状态码非 2xx、文件读取失败，都必须走 error 流程。
立即学习“go语言免费学习笔记（深入）”；
- 代码评审时重点盯
err := xxx(); if err != nil { log.Printf(...) }这种“只记录不处理”的写法 - 禁止在 HTTP handler 或 goroutine 内部直接
panic("failed to process")；应统一转为return fmt.Errorf("process failed: %w", err) - 使用
errors.Is和errors.As替代字符串匹配判断错误类型，避免因错误包装导致误判后跳进 panic 分支
defer + recover 只用于顶层防护，不替代错误处理
recover 不是错误处理机制，而是最后防线。它只能在当前 goroutine 生效，且一旦用了，就说明你已经漏掉了前面至少一层错误检查。团队规范必须限制它的使用位置：仅限于 HTTP 中间件、GRPC UnaryServerInterceptor、或 CLI 主函数入口这类“进程边界”处。
常见错误是把 recover 塞进普通工具函数里，比如封装一个 safeJSONMarshal，里面包一层 defer+recover——这反而掩盖了本该暴露的逻辑缺陷（如传入了不可序列化的 struct 字段）。
- 中间件中的
recover必须记录完整 panic stack（用debug.PrintStack()），不能只记r的字符串值 - 禁止在 goroutine 内部写
go func() { defer recover() {...} }()——这会让 panic 消失得无影无踪，且无法定位泄漏源头 - 如果某个函数频繁触发 recover，说明它本身的设计有问题，应该回溯改造成显式 error 返回
测试必须覆盖 error 分支和边界输入
panic 往往藏在没被测到的错误路径里。团队要求每个导出函数的单元测试，必须包含至少一个明确触发 error 返回的 case，并验证其行为符合预期（比如返回特定错误类型、不修改输入参数、不泄露资源）。
特别要注意边界：空 slice、nil interface{}、超长字符串、负数 ID、时间戳为零值等。这些输入在开发时容易被忽略，但上线后常由上游脏数据或恶意请求触发，最终走到未覆盖的 panic 路径。
- 用
go test -race运行所有测试，暴露并发读写 map/slice 导致的 panic - 对涉及 JSON、XML、SQL 构建的函数，用模糊测试（
go test -fuzz）喂随机字节流，看是否 panic - 禁止出现
// TODO: handle error注释——它大概率会在某次上线后变成真实 panic
