Golang链式调用中的错误传递方式

链式调用中error不可忽略，必须每步检查：DoA()→检查err→DoB()→检查err→DoC()→检查err；否则非法状态值可能导致panic或未定义行为。

链式调用中 error 不该被忽略

Go 语言里链式调用（比如 DoA().DoB().DoC()）本身不自带错误传播机制，一旦中间某步返回 error，后续方法若继续执行，大概率会 panic 或产生未定义行为。最常见错误是只检查最后一步的 error，而忽略了前序步骤失败后仍调用了后续方法。

用返回值组合实现安全链式调用

标准做法是让每一步都返回 (T, error)，上一步的 T 作为下一步的输入，同时在每步开头检查前序 error。这不是语法糖，而是显式控制流。

• 不要写 obj.DoA().DoB().DoC() 这类纯链式，除非所有方法都明确声明「不失败」或已做内部错误兜底
• 推荐写法是分步赋值 + 短路判断：

  res, err := New().DoA()
  if err != nil {
      return err
  }
  res, err = res.DoB()
  if err != nil {
      return err
  }
  _, err = res.DoC()
  return err

• 如果想保留链式外观，可封装为接受函数的组合器（如 Then），但底层仍是逐个检查 error，不是魔法

使用泛型辅助减少重复代码（Go 1.18+）

泛型能帮你抽象出通用的错误短路逻辑，但不能绕过「检查每个返回值」这一原则。

• 例如定义 func Then[T any](val T, fn func(T) (T, error)) (T, error)，它只是把 if err != nil 封装了一层，调用时仍要处理最终的 error
• 注意：泛型不会改变错误发生时机，也不会自动跳过后续调用；传入的 fn 若本身没检查入参有效性，依然可能 panic
• 性能上无额外开销，但过度封装会让调试变难——堆栈里多一层闭包，错误位置不如直写清晰

别依赖 defer 或 recover 捕获链式中的 error

defer 和 recover 是针对 panic 的，不是 error 处理机制。把 error 转成 panic 再 recover，属于反模式。

• Go 的 error 是值，设计初衷就是显式传递和判断；转 panic 会丢失原始上下文（比如哪一步返回了什么 error）
• 链式调用中若混用 panic，会导致无法区分是程序员失误（如 nil 指针解引用）还是业务失败（如网络超时），增加排查成本
• 标准库和主流框架（如 sql.DB, http.Client）全部遵循显式 error 返回，模仿它们最稳妥

链式调用本身不解决错误传递，它只是语法形式。真正起作用的是你每次拿到 error 后是否立刻响应——哪怕只写一行 if err != nil { return err }，也比“先链完再统一处理”可靠得多。最容易被忽略的是：**中间步骤返回非 nil error 后，其返回值（如 struct 实例）很可能处于非法状态，此时再拿它调用任何方法，结果不可预测**。