类型断言失败时，value.(T) 形式直接 panic，而 v, ok := value.(T) 形式返回目标类型的零值和 false；前者应避免用于不可控输入，后者是安全首选，且需配合 ok 检查与错误处理。
类型断言失败时 panic 还是返回零值？
Go 中的类型断言有两种写法：value.(T) 和 value.(T) 的双返回值形式 v, ok := value.(T)。前者在断言失败时直接 panic，后者只返回零值和 false —— 函数内处理 interface{} 参数必须用后者，否则任何不匹配的调用都会崩掉整个 goroutine。
常见错误是写成 str := arg.(string)，一旦传入 int 或 nil 就 panic。尤其在 HTTP handler、中间件或通用工具函数里，输入不可控，必须兜底。
- 永远优先用
v, ok := arg.(string)形式 - 如果
ok为false，应明确返回 error 或走默认逻辑，不能忽略 -
arg == nil时，arg.(string)一定失败（nil不是string类型），但arg.(*string)可能成功（nil指针可属于*string）
如何处理多种可能类型（比如支持 string / []byte / io.Reader）
单层断言只能匹配一种类型，但实际中常需兼容多个底层类型。这时不能靠嵌套 if，而要用 type switch —— 它本质是多路类型断言，比一连串 if v, ok := x.(T); ok { ... } 更清晰、更高效，且 Go 编译器会对 type switch 做优化。
注意：type switch 中的 case 是精确匹配，string 和 fmt.Stringer 不会命中同一分支；若需接口行为，应先断言接口，再调方法。
立即学习“go语言免费学习笔记（深入）”；
- 用
switch v := arg.(type) { case string: ... case []byte: ... default: return fmt.Errorf("unsupported type %T", arg) } - 不要在
case中重复声明变量名（如case string: s := v），直接用v即可，其类型已在该分支内确定 - 没有
default分支时，漏掉类型会导致运行时 panic（因为v未初始化），务必覆盖所有预期类型或加default
指针类型断言容易忽略的 nil 问题
断言 *T 类型时，nil 接口值和 nil *T 是两回事。例如 var p *string，把 p 传给 interface{} 后，arg.(*string) 成功（v == nil，ok == true）；但若传的是未初始化的 interface{} 变量（即 var arg interface{}），则断言失败（ok == false）。
这个差异导致很多 bug：你以为拿到了指针，结果是空接口的零值，却没检查 ok 就解引用，panic 在所难免。
- 对指针类型断言后，仍需判断
v != nil才能安全解引用 - 不要依赖
arg != nil推断v != nil——arg是接口，v是底层值，二者 nil 状态独立 - 若函数语义要求非空指针，应在断言成功后立即校验：
if v == nil { return errors.New("expected non-nil *T") }
性能敏感场景下避免重复断言
同一个 interface{} 参数在函数内多次断言同一类型（比如先判 string 做日志，再判一次做处理），会触发多次动态类型检查。虽然单次开销小，但在高频路径（如网络包解析、日志中间件）里累积起来可观。
Go 不会自动缓存断言结果，必须手动保存。
- 一次断言，多次使用：
if s, ok := arg.(string); ok { log.Println(s); process(s) } - 避免写成：
log.Println(arg.(string)); process(arg.(string))—— 第二次断言完全多余 - 如果分支逻辑复杂，可提前提取：
switch v := arg.(type) { case string: handleString(v); case int: handleInt(v) }，v在各 case 内已带类型信息
