Go错误处理：返回内置error类型还是自定义错误类型？

遵循返回内置error类型约定的优势 #

• 兼容性强：Go生态下所有标准库、第三方库都默认遵守该约定，函数返回error类型的话，所有调用方无需额外适配，直接就能用通用错误处理逻辑处理。
• 实现灵活：Go的接口是隐式实现的，内部可以根据场景返回任意实现了Error() string方法的错误类型，对调用方完全透明，后续要调整错误实现逻辑也不用修改函数签名，不会破坏下游兼容性。
• 处理逻辑统一：不需要为每种自定义错误类型单独写处理分支，通用场景下直接判断err != nil就能完成错误检查，只有需要获取错误额外信息的时候，再用类型断言/类型switch转换成对应的自定义错误类型即可，符合Go“简单优先”的设计理念。
• 规避nil陷阱：如果返回自定义错误的具体类型，很容易出现「接口值为nil但类型不为nil」的隐性问题，排查成本极高，返回通用error类型可以从根源上避免这类问题。

直接返回自定义错误类型（比如net.Error）的差异和问题 #

• 耦合度过高：调用方必须提前知晓返回的具体错误类型才能写处理逻辑，一旦后续调整返回的错误类型，所有下游调用方的代码都要同步修改，兼容性极差。
• 扩展性差：函数签名锁死只能返回固定的自定义错误类型后，后续如果要新增其他错误类型返回，要么改签名破坏兼容，要么只能强行往现有类型里塞不相关的字段，代码会越来越臃肿。
• 容易触发nil判断bug：以下是很常见的错误写法，判断逻辑永远不会符合预期：

func doSomething() *net.Error {
    // 逻辑执行无问题返回nil
    return nil
}

err := doSomething()
if err != nil {
    // 这里永远会被执行，因为err的类型是*net.Error、值是nil，接口判断规则要求类型和值都为nil才等于nil
    log.Fatal(err)
}

• 违反生态惯例：所有Go开发者都默认函数返回通用error类型，特立独行返回具体类型会大幅提升其他开发者使用代码的心智负担，属于典型的反模式设计。

内容的提问来源于stack exchange，提问作者geliba187