Go 接口为 nil 时调用方法 — 运行期 panic

症状

错误“Go 接口为 nil 时调用方法 — 运行期 panic”指向一个明确的失效模式。下面依次给出症状、定位该原因的检查命令、根本原因、修复方案，以及证明修复有效的验证步骤。

可观察到的症状包括：

• panic: runtime error: invalid memory address or nil pointer dereference
• 堆栈指向对接口值的方法调用
• 日志显示接口“并非 nil”，但方法仍 panic

诊断

先在隔离环境中复现故障，再按顺序执行以下检查，逐步缩小范围。

步骤 1

fmt.Printf("%T %v\n", iface, iface)

显示出非 nil 的类型加 nil 值即为 typed nil，解释了为何“非 nil”判断通过而调用仍 panic。

步骤 2

go run - <<'EOF'
package main
import "fmt"
type I interface{ Do() }
type T struct{}
func (T) Do(){ fmt.Println("do") }
func bad() I { var p *T; return p } // typed nil
func main(){ i := bad(); if i != nil { i.Do() } }
EOF

该最小程序在 nil 判断之后仍 panic，证明 typed nil 陷阱。

常见诱因（按出现频率排序）：

• typed nil (*T)(nil) 存入了接口，接口本身非 nil，但方法解引用了 nil
• 函数返回的接口没有有效实现，调用方却调用了方法
• 依赖以 nil 注入，使用前未加防护

根因

接口值只有在类型与值都为 nil 时才是 nil。返回 typed nil 指针会给接口赋予具体类型，使接口非 nil，而底层接收者仍为 nil，于是方法调用解引用 nil。

修复

在依赖缺失处返回真正的 nil 接口（return nil，而非 typed nil），并改用 comma-ok 或小型哨兵实现，而不是拿接口与 nil 比较。

注意：把接口与 typed nil 常量比较虽能编译却永不匹配，防护会静默失效。

type Store interface{ Save() error }

func newStore(enabled bool) Store {
	if !enabled {
		return nil // true nil interface, not (*kvStore)(nil)
	}
	return &kvStore{}
}

s := newStore(false)
if s != nil { // correct: s is a genuine nil interface
	_ = s.Save()
}

验证

重跑最小程序，确认不再 panic 且执行到防护分支；补充测试断言构造函数在缺失路径返回 nil 接口。

修复后补充一条回归测试，复现原始症状，防止问题再次出现。

这类故障通常是环境问题而非纯逻辑错误，因此在缺陷记录中应写明完整命令、环境变量与工作目录。请用最小的脚本复现，待最小用例清楚后再扩大范围。为这类故障准备一份简短的排查清单，能显著减少下次排障时间。