Go nil interface 与 typed nil 为什么判断不同

Go中的nil interface与装着typed nil的接口判断不同，是因为接口值为nil时没有动态类型、也没有动态值；把一个值为nil的具体指针赋给接口后，接口已经记录了该指针的类型。因此，指针本身可以等于nil，承载它的接口却不等于nil。这不是比较操作失效，也不是只看指针地址就能判断的事情。

官方地址：https://go.dev/

从具体指针的数据来源看nil

设想一个资料导入组件，解析成功时没有问题对象，失败时返回自定义问题。这里用原创场景解释数据的创建、承载、传递与清理，不声称它来自实际故障经历。我更倾向于先看变量声明，再看接口赋值边界，而不是反复更换打印格式。

var issue *LoadIssue 已经确定具体指针类型，但指针值尚为空。var empty any 则是接口的零值。两者都可以与nil比较，但不是同一种类型的值。typed nil只是对“具有具体类型的nil值”的常用描述，不是Go新增的关键字。

接口承载的是类型和值

理解接口时，可以用“动态类型与动态值”作为语义模型，不必把它当成对所有运行时内存布局的承诺。接口静态类型仍是any或error；动态类型则说明它实际承载的具体值类型。

package main

import "fmt"

type LoadIssue struct {
    Detail string
}

func main() {
    // 指针有明确类型，零值是nil。
    var issue *LoadIssue
    var empty any
    var boxed any = issue

    // 用动态类型和nil比较一起观察，不靠格式化文本猜状态。
    fmt.Printf("issue为nil: %t\n", issue == nil)
    fmt.Printf("empty为nil: %t\n", empty == nil)
    fmt.Printf("boxed类型: %T，boxed为nil: %t\n", boxed, boxed == nil)

    // 断言成功只说明类型匹配，仍要单独检查取出的指针。
    pointer, ok := boxed.(*LoadIssue)
    fmt.Printf("断言成功: %t，取出的指针为nil: %t\n", ok, pointer == nil)
}

这是供读者复现的示例，未附带本地实测输出。按语言规则，issue和empty的nil比较成立，boxed的nil比较不成立；类型断言可以成功，同时得到nil指针。把boxed继续传给另一个any参数，也不会自动去掉其动态类型。

在error返回边界修正状态

error同样是接口。如果函数签名返回error，却在成功路径返回一个nil的自定义错误指针，转换为error时仍会带上动态类型。调用方标准的err != nil判断就会认为存在错误。修正位置应尽量靠近数据产生的地方，成功时明确返回nil。

package main

import (
    "fmt"
    "strings"
)

type LoadIssue struct {
    Detail string
}

func (e *LoadIssue) Error() string {
    // 本例允许nil接收者被调用，但这不会让error接口变成nil。
    if e == nil {
        return "问题对象为空"
    }
    return e.Detail
}

func parseRecord(text string) error {
    if strings.TrimSpace(text) == "" {
        return &LoadIssue{Detail: "记录内容为空"}
    }
    // 成功直接返回接口nil，不返回一个nil的*LoadIssue变量。
    return nil
}

func main() {
    if err := parseRecord("record-alpha"); err != nil {
        fmt.Println("导入失败:", err)
        return
    }
    fmt.Println("该记录可继续处理")
}

这里的空白判断是示例业务约定，不是通用记录格式规则。Error方法中的nil分支只是防止本例访问空接收者字段；它不改变接口相等语义。不要指望Error返回空字符串、特殊文本，或者给类型增加一个方法，就让非nil接口自动被当作成功。

清理与调用时还需哪些约定

接口非nil不能保证调用方法一定安全。指针接收者的方法能否处理nil，由方法实现决定；如果直接访问空指针字段就可能发生panic。值接收者方法经由nil指针使用，也不能简单等同于本例的显式nil接收者处理。

不要为每个调用点都补一个任意类型的反射判空函数来掩盖返回契约。反射API有各自适用类型与前置条件，滥用容易引入新异常。类型已知时明确判断具体指针；返回error时由生产者正确返回nil，通常更容易维护。

两个承载nil的接口都相等吗？

不能仅凭内部值都是nil就下结论，动态类型也参与比较。相同具体指针类型的nil值可以相等，不同指针类型则不同。接口之间比较还受动态类型是否可比较影响，切片等动态值可能让比较panic；本文的nil比较不要泛化成任意接口相互比较。

打印出来像nil，为什么判断不是nil？

打印格式与接口的语义状态不同，自定义格式方法也可能影响显示。观察动态类型和明确的nil比较更直接，不要把显示文本当成程序判断依据。

把原指针变量设为nil，会清空已经保存的接口吗？

不会自动清空。接口赋值保存的是当次具体值，修改另一个变量不会反向重写接口；需要清空该接口变量时，应直接给它赋nil。

参考：Go FAQ中的nil error解释、Go比较运算规范。