Go语言自定义错误为何采用指针接收器？与常规规则的疑问

这是个非常好的问题，我当初刚学Go的时候也有过同样的疑惑——明明不需要修改接收器，结构体也不大，用值接收器写起来更简洁，为啥官方示例都偏爱指针接收器呢？下面我来拆解几个核心原因：

• 保持方法集的一致性
  很多时候你的自定义错误类型（比如appError）不会只有Error()这一个方法。如果后续你给它添加其他需要修改内部状态的方法（比如给错误加堆栈信息），这些方法必然要用指针接收器。提前把Error()也设为指针接收器，能让整个类型的方法集保持统一，避免出现「值类型实现了error接口，但指针类型又有额外方法」这种割裂的情况，减少后续维护的心智负担。

• 规避值拷贝的潜在陷阱
  虽然现在你的appError体积很小，但如果未来扩展了结构——比如加入[]string类型的错误详情、或者map类型的上下文信息——值拷贝就可能引发意外问题：拷贝后的实例和原实例会共享这些引用类型的数据，修改拷贝体可能会影响原实例。用指针接收器从一开始就避免了这种风险，不用等到出问题再重构代码。

• 符合Go社区的惯例与标准库风格
  你可以看看标准库中的错误类型，比如os.PathError、fmt.Errorf返回的错误实例，本质上都是指针类型。官方示例遵循这种惯例，一是为了和标准库保持风格统一，让其他Go开发者一眼就能看懂；二是因为error通常被当作「一次性传递的消息」，用指针传递更符合大家对「错误对象」的直觉——毕竟你很少会需要拷贝一个错误实例，大多是把它从函数返回出去或者传递给其他处理逻辑。

• 接口匹配的隐性细节
  这里有个容易被忽略的点：如果用值接收器实现Error()，那么appError值类型和*appError指针类型都能满足error接口；但如果用指针接收器，只有*appError能实现error。那为啥官方选后者？因为很多时候我们会定义全局的错误常量（比如var ErrNotFound = &appError{...}），用指针的话可以直接复用这个实例，而值类型的常量每次传递都会拷贝新的实例，虽然功能没问题，但不符合「错误实例复用」的常见场景。

总结一下：虽然用值接收器实现error接口完全合法，代码也更简洁，但指针接收器在一致性、扩展性和社区惯例上更有优势，这也是官方示例普遍采用它的原因。

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