单值类型断言失败会 panic，双值形式返回零值和 false；必须用双值断言并检查 ok 才能安全使用，否则可能 panic 或误用零值。
类型断言失败时 panic 还是返回零值？
在 Go 中，value.(Type) 这种「单值形式」的类型断言，一旦失败会直接触发 panic，程序崩溃。它不返回错误，也不做兜底，和 Python 的 isinstance() 或 JavaScript 的 instanceof 完全不同。
真正安全、生产环境必须用的是「双值形式」：v, ok := value.(Type)。此时断言失败不会 panic，而是把 v 设为 Type 对应的零值（比如 0、""、nil），ok 为 false。
为什么不能只依赖单值断言？
单值断言只适合你 100% 确定接口值一定属于目标类型——这种场景极少。实际中，接口变量常来自函数返回、channel 接收、map 查找或用户输入，类型不确定是常态。
- HTTP handler 中从
context.Context取自定义值，可能根本没存过 - 使用
interface{}做泛型兼容（Go 1.18 前常见），传入int却尝试断言为string - 反射调用后返回的
reflect.Value.Interface()，类型需动态判断
一旦断言失败，panic: interface conversion: interface {} is int, not string 就会炸出来，且无法被 recover() 拦截（除非你在同一 goroutine 里显式 defer+recover）。
立即学习“go语言免费学习笔记（深入）”；
双值断言的典型写法与易错点
正确写法不是「先断言再用」，而是「断言即校验，ok 为 true 才进入逻辑」。漏掉 ok 判断或把它放在 if 外面，等于白写。
var i interface{} = 42
s, ok := i.(string) // ok == false, s == ""
if !ok {
// 必须在这里处理失败：log、return、fallback...
fmt.Println("not a string")
return
}
// 此时 s 才能安全使用
fmt.Println("got string:", s)
常见错误：
-
s := i.(string)—— 单值，失败就 panic -
s, ok := i.(string); if ok { ... use s ... }—— 看似对，但若s在 if 外被误用（比如日志打错位置），依然可能用到零值 - 嵌套断言如
v.(io.Reader).(io.Closer)—— 第二层断言仍可能 panic，应拆成两步并检查每步的ok
断言 nil 接口值会发生什么？
如果接口变量本身是 nil（即底层 type 和 value 都为 nil），任何类型断言都会失败，ok 为 false，不会 panic。
但注意：接口为 nil ≠ 底层值为 nil。例如 *os.File(nil) 赋给 interface{} 后，接口非 nil（有具体类型 *os.File），只是 value 是 nil 指针。此时断言为 *os.File 成功，但解引用会 panic。
var w io.Writer = (*os.File)(nil) f, ok := w.(*os.File) // ok == true, f == nil f.Close() // panic: nil pointer dereference
所以断言通过只是第一步，后续还需检查具体值是否可安全使用。
