Go语言中用类型断言处理错误是否合规？为何switch+类型断言未被广泛推荐？

你提到的两种错误处理写法，一种是基于errors.As的链式判断：

if err != nil {
    if errors.As(err, &QueryErr{}) {
        log.Println("query error : ", err)
        return http.StatusInternalServerError
    } else if errors.As(err, &QueryDataExtractionErr{}) {
        return http.StatusNotFound
    } else {
        log.Println(err.Error())
        return http.StatusInternalServerError
    }
}

另一种是用switch err.(type)的类型断言分支：

if err != nil {
    switch err.(type) {
    case QueryErr:
        log.Println("query error : ", err)
        return http.StatusInternalServerError
    case QueryDataExtractionErr:
        return http.StatusNotFound
    default:
        log.Println(err.Error())
        return http.StatusInternalServerError
    }
}

为什么后者没有被更多使用或推荐，核心原因如下：

• 无法处理错误包装链：Go 1.13引入错误包装机制后，很多错误会被多层嵌套（比如用fmt.Errorf("%w", err)包装）。errors.As可以穿透所有包装层级，找到目标错误类型；但switch err.(type)只能匹配当前err的直接类型，一旦错误被包装，就会匹配失败直接走到default分支。
• 灵活性远不如errors.As：errors.As不仅能匹配具体结构体类型，还能匹配实现了特定接口的错误。比如你定义一个QueryError接口，只要某个错误实现了该接口的方法，errors.As就能识别；而类型断言只能严格匹配具体的类型，无法做到接口层面的匹配。
• 官方与社区的习惯导向：官方文档和标准库示例更推崇errors.As、errors.Is这类工具函数，它们是为Go的错误设计量身打造的。社区长期使用后也形成了共识，这类写法扩展性更强，能适配更多复杂的错误场景。
• 容易踩类型匹配的坑：如果你的错误类型是指针类型（比如*QueryErr），switch里必须写case *QueryErr:才能匹配；如果不小心写成值类型QueryErr，就会匹配失败。而errors.As只需要传入对应类型的指针，无需区分值或指针，容错性更高。

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