Go 中错误处理的最佳实践：为何应避免用 panic 替代显式错误检查

在 go 中，显式检查并传递错误是标准且推荐的做法；滥用 panic 会破坏程序的可控性、可测试性和可维护性，仅应在真正不可恢复的异常场景下使用。

Go 的错误处理哲学强调“错误是值”（errors are values），这意味着错误应当被显式返回、检查、记录或转换为用户友好的响应，而非通过 panic 推卸责任。你当前代码中反复调用 rcv.AnyErrors() 的模式虽略显冗余，但本质正确——它体现了清晰的控制流和可预测的错误传播路径。相比之下，将 panic() 强行插入 upload() 等业务方法中，不仅违背 Go 的惯用法，还会带来严重后果：

• 破坏调用栈的语义：panic 本意是应对程序级崩溃（如 nil 指针解引用、数组越界），而非文件未找到、配置解析失败等常规业务错误；
• 阻碍单元测试：panic 需要 recover 捕获，使测试逻辑复杂化，而 if err != nil 可直接断言错误类型与内容；
• 丢失上下文与可恢复性：AddErr("TextError", ...) 是一种结构化错误收集机制，便于统一生成 HTTP 错误响应（如 400 Bad Request + JSON 错误详情）；而 panic 一旦触发，除非上层显式 recover，否则整个 goroutine 终止，无法优雅降级；
• 违反 Go Wiki 明确指南：Go Code Review Comments 明确指出：“Don’t use panic for normal error conditions. Use error values

  

  instead.”

✅ 更优重构建议（保持清晰 + 减少样板）：

func (rcv *ctrl) serveHttp() (types.SuccsJSON, types.ErrorsJSON) {
    if err := rcv.upload(); err != nil {
        return nil, rcv.Errs // 或 rcv.AddErr("UploadError", err.Error())
    }
    if str := rcv.convertToJson(); str != "" {
        return c.Sucss, nil
    }
    return nil, rcv.Errs
}

// upload 改为返回 error，而非静默设置 rcv.Errs
func (rcv *ctrl) upload() error {
    file, err := ini.LoadFile(rcv.getFile())
    if err != nil {
        rcv.AddErr("TextError", err.Error())
        return err // 显式返回，由调用方决策
    }
    rcv.file = file
    return nil
}

func (rcv *ctrl) convertToJson() string {
    js, err := json.Marshal(rcv.file.Section("text/signup"))
    if err != nil {
        rcv.AddErr("ConvertError", err.Error())
        return ""
    }
    return string(js)
}

? 关键原则总结：

• ✅ 业务错误（I/O 失败、解析异常、参数校验不通过）→ 返回 error，由 handler 统一处理；
• ❌ 避免 panic 用于可预期、可恢复的错误；
• ? 若需减少重复检查，可封装为链式调用或使用中间件模式（如 RunSteps([]Step{rcv.upload, rcv.convertToJson})），但绝不以牺牲清晰性为代价；
• ? 所有错误路径必须可被单元测试覆盖——这是 Go 健壮性的基石。