Go 实际上编译生成的函数只是在语义层面上跟原始类型绑定,而在之后的代码生成过程中,Go 隐式生成了一个对应的函数,这个新的函数跟老的类型是解耦的,并把对象本身作为第一个参数传入。
举个例子来说,考虑你的测试代码,Go 编译器会生成下面的 stub:
```go
func (*A).Run(a *A) {
fmt.Print(a.a)
}
```
这种函数签名是你不能写出来的,因为在用户层面这种语法是 invalid 的,但是你可以调用。尝试在你的 Test 中插入:
```go
func TestA(t *testing.T) {
var a *A
a.Run()
}
func TestAnother(t *testing.T) {
var a *A
(*A).Run(a)
}
```
代码可以正常编译执行,然后报错。
而假如我定义另一个方法,不访问 A 的内部参数,即不依赖 A 的值,你会发现代码能够安全运行,没有任何问题( 16 楼老哥已经有 runnable 了)。
这种情况是不是比较反直觉?而实际上 GCC 和 clang 也是这么做的:
https://godbolt.org/z/xb9WWz53x 。当然,如果你打开 undefined behavior santizer ,你会发现编译器报错了,因为标准并没有对这个情况作出规定。
所以是否需要检查 receiver 是不是 nil ?取决于你。如果这个方法你不想 panic ,那你可以检查 `if p != nil` 并做出恰当报错,但是这会影响大家对于 method call 语义的共识理解(如果 a 为 nil ,我调用它的方法应该 panic 啊?为什么没有 panic ?)。或者直接 let it crash ,也方便查错。