很多人第一次看到 var a *A 明明还是 nil，却能直接执行 a.Foo()，都会下意识把它归类成“Go 的特殊魔法”。其实这里没有绕开空指针，只是 Go 对方法调用的处理方式和不少语言不同。顺着“类型信息在哪里、调用时到底传了什么、什么时候才会真正解引用”这三步看下来，就能判断哪些 nil 调用是安全的，哪些一定会在运行时出错。
Go 的 nil 为什么能调用方法：先看“带类型”这件事
先看最常见的例子：
package main
import "fmt"
type A struct {}
func (a *A) Foo() {
fmt.Println("调用了A的Foo方法")
}
func main() {
var a *A // a是nil
a.Foo() // 正常输出：调用了A的Foo方法
}这段代码之所以能跑通，关键不是 nil 本身，而是变量 a 的类型已经明确为 *A。在 Go 里，nil 不是一个可以脱离类型独立存在的“万能空值”，它必须依附于具体类型来使用。
也就是说，虽然 a 的值是 nil，编译器仍然知道它是“指向 A 的指针”。因此执行 a.Foo() 时，方法集合是明确的，编译器可以直接定位到 *A 上定义的 Foo 方法。
这一点也能从反例看出来：
var n nil // 编译错误：use of untyped nil如果 nil 没有类型，编译器就无法决定它属于哪一类值，更不可能继续做方法调度。Go 在这里的约束非常直接：类型必须先明确，后续的调用语义才成立。
所以第一层结论可以记住一句话：Go 里能调用方法的不是“裸 nil”，而是“有确定静态类型的 nil 值”。
方法调用的本质：语法糖展开后只是传了一个 nil 参数
再往下一层看，Go 里的方法调用本质上是函数调用的语法糖。也就是说，像 a.Foo() 这样的写法，编译器会把接收者一起改写成普通函数调用。
例如下面这个方法：
func (a *A) Foo() {
fmt.Println("调用了A的Foo方法")
}从理解上，可以把它看成类似下面的普通函数：
func Foo(a *A) {
fmt.Println("调用了A的Foo方法")
}于是 a.Foo() 在效果上就相当于 Foo(a)。这里传进去的是一个值为 nil 的 *A 参数，而不是先去访问 a 指向的内存。
这也是为什么示例代码不会立刻崩溃：只要方法体里没有真正解引用这个指针，传入 nil 本身并不会触发异常。
但一旦方法内部开始访问字段，情况就变了：
type User struct {
Name string
}
func (u *User) GetName() string {
// 没做nil检查，操作字段会panic
return u.Name
}
func main() {
var u *User // nil
u.GetName() // 运行时错误：nil pointer dereference
}这里的问题不是“不能调用方法”，而是调用之后，u.Name 这一步需要解引用 u，于是触发 nil pointer dereference。
实际开发里，这一点非常重要。一个指针接收者方法是否能接受 nil，取决于它的方法体是否把 nil 当成合法状态处理。如果方法只做日志输出、状态判断或返回默认值，那么完全可以让 nil 成为一种可用输入；如果要访问字段，就应该显式检查。
什么时候应该主动做 nil 检查
对外暴露的方法，只要存在“调用方可能传来 nil”的场景，最好把行为定义清楚。常见做法是先判断接收者是否为空，再决定返回默认值还是继续执行：
func (u *User) GetName() string {
if u == nil { // 先做nil检查
return "默认名称"
}
return u.Name
}这样做的好处是，调用方不需要在每次调用前都写一遍判空逻辑，方法本身也更容易形成稳定语义：nil 到底代表“缺失对象”还是“空配置”，由方法来统一处理。
真正容易误判的地方：接口里的 nil 陷阱
比“nil 指针能调方法”更容易让人踩坑的，其实是接口场景。看下面这段代码：
package main
import "fmt"
type Reader interface {
Read()
}
type File struct {}
func (f *File) Read() {
fmt.Println("File Read")
}
func main() {
var f *File = nil
var r Reader = f // 把nil的*File赋值给接口
fmt.Println(r == nil) // 输出：false
r.Read() // 正常输出：File Read
}很多人看到这里会困惑：f 明明是 nil，为什么赋给接口后，r == nil 却是 false？
原因在于，接口值的底层并不只是一个“数据指针”。从理解上看，它至少包含两部分信息：一部分记录动态类型，一部分记录实际数据。你可以把它理解成一个类似 iface 的结构，里面有类型信息和数据指针。
当执行下面这句时：
var r Reader = fr 的“数据”部分确实是 nil，但它的“类型”部分已经被填成了 *File。因此这个接口值整体并不为空。只有当类型和数据都为 nil 时，接口变量才真正等于 nil。
这也解释了后面的调用为什么还能成功：编译器或运行时仍然可以根据接口里保存的动态类型，找到 *File 对应的 Read 方法，然后把那个 nil 指针作为接收者传进去。只要方法体里不解引用它，调用就能继续完成。
因此，接口判空不能只看“它里面是不是装了一个 nil 指针”，而要看“这个接口值本身是否为空”。这是 Go 中非常典型、也非常高频的误判来源。
不是所有 nil 调用都安全：这两类情况一定会 panic
说到这里，需要把边界收紧一下。Go 并不是“只要是 nil 都能调用”，下面两种情况就明确不安全。
1. nil 函数值直接调用
如果变量本身是函数类型，默认值同样可能是 nil，这时直接调用会在运行时报错：
var fn func(int) int // 函数类型的nil
fn(3) // 运行时panic：call of nil function这里和方法调用不是一回事。函数值如果是 nil，就意味着根本没有可执行目标，自然无法完成调用。
2. 方法内部解引用 nil 指针
第二类就是前面已经提到的情况：方法虽然能进，但只要内部访问了字段、调用了依赖有效对象状态的操作，本质上就会发生解引用，最终触发 panic。
所以判断标准并不复杂：
- 能不能调用，先看类型是否明确、方法是否可调度；
- 会不会崩，关键看方法体有没有实际解引用这个
nil。
把这两层分开之后，很多看上去“反直觉”的行为其实都很好解释。
理解这件事后，实际开发里要记住什么
把整件事压缩成几个判断点，会比死记结论更有用。
Go 的
nil必须依附于具体类型存在，var a *A这样的值虽然为空，但类型信息完整，方法集合也就完整。方法调用本质上会把接收者作为参数传入，因此“传一个
nil指针”本身不等于“立刻空指针崩溃”。真正触发问题的通常是解引用动作，例如访问字段、依赖对象内部状态等操作。
接口判空要额外小心。接口里只要还带着动态类型，即使内部数据是
nil，接口值本身也不等于nil。
这套设计也体现了 Go 一贯的取向：编译期尽量把类型说清楚，运行期则允许你把 nil 当成一种可处理状态，而不是统一粗暴地禁止调用。写库代码或公共接口时，是否接受 nil 接收者，最好在方法语义上提前定义清楚。
最后再看原文留下的这个问题：
package main
import "fmt"
type B struct {}
func (b B) Bar() {
fmt.Println("调用了B的Bar方法")
}
func main() {
var b *B = nil
b.Bar()
}这段代码值得单独推一遍，因为它涉及值接收者方法和自动解引用的规则。表面上看是 *B 调用了 Bar()，但 Bar 的接收者类型其实是 B，这里会不会触发隐式解引用、最终是否会因为 b 为 nil 而报错，正是理解值接收者与指针接收者差异的一个典型练习题。
