Go go vet 怎样发现指针错误类型包装

项目升级到 Go 1.27 后，如果 go vet 在 fmt.Errorf 的 %w 附近提示指针错误类型包装，不要把它当成普通格式化问题。它关注的是错误的动态类型：某个类型本身已经实现了 error，但代码又把它的指针作为被包装对象，后续用值类型查询时就可能匹配不到。

官方地址：https://go.dev/doc/go1.27

本文只讨论 Go 1.27 的 vet printf 规则、fmt.Errorf("%w") 与 errors.As 的关系。配套检查命令是 go vet ./...，它能发现静态类型契约问题，但不会替代运行时错误路径设计。

问题现场：为什么升级后才看到提示

这类问题常出现在错误类型定义已经存在、包装代码也能编译的项目里。比如一个错误类型用值接收者实现了 Error，因此值和指针都满足 error；调用方却习惯性地把指针放入 %w。旧版本可能没有把这个组合明确提示出来，Go 1.27 的发布说明则把它列为 printf 分析器的新检查边界。

package payment

import "fmt"

type CodeError struct {
    Code int
}

// 值接收者让 CodeError 和 *CodeError 都满足 error 接口。
func (e CodeError) Error() string {
    return fmt.Sprintf("payment code=%d", e.Code)
}

func wrapFailure() error {
    e := &CodeError{Code: 502}
    // 这里包装的是 *CodeError，而不是 CodeError 值。
    return fmt.Errorf("upstream failed: %w", e)
}

关键点不是“指针一定不能包装”，而是返回值的动态类型必须和团队约定一致。若调用方准备按 CodeError 查询，返回 *CodeError 就会形成类型边界不一致。

为什么指针包装会让错误类型查询失效

%w 会保留被包装错误，errors.As 再沿着包装链查找可赋值的目标类型。它比较的是动态类型，而不是只看错误结构体的字段是否相同。下面的查询目标是 CodeError 值，因此只能匹配包装链中真正的 CodeError 值。

package payment

import (
    "errors"
    "fmt"
)

func findCode(err error) (int, bool) {
    var target CodeError
    // 查询目标是值类型，包装链里若只有 *CodeError 就不会命中。
    if !errors.As(err, &target) {
        return 0, false
    }
    return target.Code, true
}

func demo() {
    err := wrapFailure()
    code, ok := findCode(err)
    // 这里的判断表达“按值类型查找”，不是对 vet 输出做运行时验证。
    fmt.Println(code, ok)
}

如果设计就是返回指针，那么查询端可以声明 var target *CodeError，再传入 &target。不过在一个稳定的库接口里，最好先决定错误类型是值语义还是指针语义，再让构造、包装和查询全部遵守同一约定。

go vet 到底检查了哪一层

go vet 不会替你推断业务上应该返回哪种错误。它检查的是已知调用和类型信息：格式字符串里有 %w，操作数又是一个指向错误类型的指针，而该错误类型本身已经实现了 error。这通常意味着代码可能把本来要查询的值类型变成了指针类型。

# 扫描当前模块及其子包，输出 vet 能识别的静态问题。
go vet ./...

如果项目的测试命令启用了默认 vet，或 CI 单独执行了这条命令，提示会在编译测试之前暴露。诊断出现后先看错误类型的 Error 接收者，再看 %w 操作数和所有 errors.As 目标，不要只把 &E 改成 E 而不检查接口契约。

修复方式：让构造、包装和查询保持同一种语义

若 CodeError 的字段是值语义、不会被调用方修改，可以直接包装值：

func wrapFailure() error {
    // 值接收者对应值语义，包装链里保留 CodeError 动态类型。
    e := CodeError{Code: 502}
    return fmt.Errorf("upstream failed: %w", e)
}

func findCode(err error) (int, bool) {
    var target CodeError
    // 目标变量的类型与被包装值保持一致。
    if !errors.As(err, &target) {
        return 0, false
    }
    return target.Code, true
}

若错误对象必须保持指针语义，例如包含可变状态或只用指针接收者实现 Error，就统一使用指针构造和指针查询：

func findPointerCode(err error) (int, bool) {
    var target *CodeError
    // errors.As 的第二个参数是“目标指针”，因此这里是 **CodeError 的形态。
    if !errors.As(err, &target) || target == nil {
        return 0, false
    }
    return target.Code, true
}

最后，把 go vet ./... 放进提交前检查，并在代码评审中记录错误类型契约：返回的是值还是指针、包装后按哪种类型查询、是否需要保留底层错误。这样它就不只是一次升级修复，而是一条可以防回归的工程规则。

常见问题

看到 vet 提示后，所有 %w 都应该改成 %v 吗？

不应该。%v 会失去包装语义，调用方不能再通过 errors.Is 或 errors.As 访问底层错误。应先统一动态类型，再保留 %w。

指针错误类型一定是错误吗？

不一定。指针可能是正确的设计；真正需要避免的是“包装端使用一种动态类型，查询端却按另一种类型查找”，以及值接收者让两种形态都满足接口后产生的模糊约定。

结论

这条 vet 提示的重点是错误类型契约，不是格式字符串语法。先确认 Error 的接收者，再决定包装值或指针，并让 errors.As 的目标类型与包装链保持一致。Go 1.27 把这类潜在问题提前暴露出来，修复后继续用 go vet ./... 作为持续检查即可。