调用 nil 函数变量会 panic，因为 Go 在运行时检查函数指针是否为 nil，发现即抛出“call of nil function”；需在调用前显式判空，如 if fn != nil { fn() }，否则触发 panic。
调用 nil 函数变量为什么会 panic
Go 里函数类型是第一类值，nil 函数变量本身合法，但一旦执行就会触发运行时 panic。这不是编译错误，而是运行时判断：Go 在调用前会检查函数指针是否为 nil，发现是就立即抛出 panic: call of nil function。
常见诱因是忘记初始化回调函数、接口方法未实现、或条件分支中漏写赋值。
- 结构体字段声明为函数类型但没初始化：
func() error字段默认就是nil - 接口实现缺失，比如
http.HandlerFunc赋值了nil而非实际函数 - 使用 map 查找函数后直接调用，没检查是否存在：
fn := handlers["key"]; fn()
如何安全调用可能为 nil 的函数变量
核心原则：调用前必须显式判空。Go 不提供类似 JavaScript 的“可选链”或空合并操作符，得靠手动检查。
推荐写法是用 if 判断 + 提前 return 或 fallback：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
if fn != nil {
fn()
} else {
log.Println("callback not set, skipping")
}
- 不要用
if fn == nil { return }后紧接fn()—— IDE 可能报 unreachable code，且逻辑易错 - 避免把判空和调用拆到不同函数里，除非你明确控制了生命周期（比如封装成方法）
- 如果多个地方都要调用同一函数变量，建议封装成带判空的辅助方法，而不是到处重复
if fn != nil
nil 函数在接口/方法集中的表现差异
当函数作为接口字段或嵌入到结构体中时，nil 值行为不变，但容易因隐式转换产生误判。
例如：var f http.HandlerFunc 是 nil，但 f(nil) 会 panic；而 http.Handle("/path", nil) 却不会 panic —— 因为 http.Handle 内部做了判空处理。
- 标准库多数接受函数参数的地方（如
http.HandleFunc、sync.Once.Do）都会主动检查nil，但不是所有第三方库都这样 - 实现自定义接口时，如果方法签名含函数类型字段，别假设调用方会判空；应在你的方法里自己检查
- 注意
reflect.Value.Call对nil函数的处理：它也会 panic，且错误信息更模糊（call of zero Value.Call），需提前用.IsValid()和.Kind() == reflect.Func过滤
测试 nil 函数路径容易漏掉的点
单元测试常只覆盖“有函数”的 happy path，而忽略 nil 分支。一旦上线，用户传 nil 就直接 crash。
- 测试时必须显式构造
nil场景：比如传nil给接收函数参数的方法，验证是否 panic 或是否被妥善处理 - 用
defer/recover捕获 panic 做断言时，注意 recover 只对当前 goroutine 有效；并发调用中漏掉 recover 就真 panic 了 - 静态检查工具（如
staticcheck）能发现部分明显未判空的调用，但无法覆盖动态赋值场景（如从配置加载函数名再反射调用）
最麻烦的是那种“看起来不可能为 nil”的变量——比如 struct 初始化后被外部修改、或跨包暴露的导出字段，别人可以随时设成 nil。只要类型允许，就得按可能为 nil 来防御。
