interface{} 本身不提供类型安全，真正的类型安全依赖后续的断言、判断与处理；常见错误包括误用 if v == nil 判断空值，正确方式是结合反射或类型断言；类型断言必须用 comma-ok 模式，避免 panic；处理不确定类型时应支持多种可能并避免重复断言。
空接口 interface{} 本身不带来类型安全，它只是“能装任何东西”的容器；真正的类型安全，全靠你后续怎么断言、怎么判断、怎么处理。
interface{} 不等于 nil 的常见错觉
很多人写 if v == nil 判断一个 interface{} 变量是否为空，结果逻辑出错。因为 v 可能内部存的是 (*int)(nil) 或 (*string)(nil) —— 这些值本身是 nil 指针，但作为 interface{} 时，它的动态类型非空，所以 v != nil。
- 正确做法是先用反射或显式类型检查：比如
reflect.ValueOf(v).Kind() == reflect.Invalid表示真 nil - 更实用的判断方式是结合类型断言：先
v, ok := i.(**int)，再检查v != nil && *v != nil - 如果只是想避免 panic，不如跳过“是否为 nil”这层判断，直接走安全断言分支
类型断言必须用 comma-ok 模式
写 v := i.(string) 是危险操作，一旦 i 实际不是 string，运行时直接 panic。生产代码里几乎不该出现这种写法。
- 一律用双值形式：
v, ok := i.(string)，然后if !ok分支做 fallback - 不要在
ok为 false 时还继续用v（此时v是string零值""，容易掩盖逻辑错误） - 若需链式判断多个类型，优先用
switch v := i.(type)，比嵌套 if 更清晰、不易漏 case
从 interface{} 转 string 时的典型陷阱
你以为 i 是 string，但实际可能是 fmt.Stringer 实现、[]byte、甚至 json.Number，直接断言成 string 必然失败。
- 先确认来源：如果是 HTTP query 参数或 JSON 解析结果，大概率是
string或float64，而不是你想当然的类型 - 对不确定输入，别只断言一种类型；比如处理 API 返回字段，要同时支持
string、float64（数字转字符串）、bool（"true"/"false"） - 避免重复断言：一次
v, ok := i.(string)后，把v存为局部变量反复用，别在多个地方重写断言
最常被忽略的点是：interface{} 的“空”不是布尔意义上的空，而是一个带类型信息的包装体；断言失败不是语法错误，而是运行时逻辑分叉点——它需要你主动设计 fallback 路径，而不是指望编译器帮你兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
