类型断言必须用 v, ok := x.(t)，禁止单值形式；nil 接口断言必 panic，需先判空；指针与值类型不可混断；json 解析后需先检 key 存在性再断言类型；多类型分支优先用 switch v := x.(type)；断言非类型转换，不可强转；接口 nil 与内部值 nil 本质不同。
类型断言必须用 v, ok := x.(T)，别用单值形式
直接 panic 的 x.(T) 在生产环境几乎没理由用——哪怕你“确定”类型对，只要接口变量是 nil，照样崩。Go 不会帮你判空，它只认接口底层是否真存了 T 类型的值。
-
nil接口调用任何断言都会 panic，包括带ok的写法；所以如果上游可能传nil，得先写if x != nil - 指针和值类型不能混断：存的是
string，不能用*string去断；反过来也一样，除非接口里明确存了指针 - 断言失败时，
v是T的零值（0、""、nil），不是上一个有效值的残留，这点常被误以为“断言没生效但 v 还有旧值”
处理 JSON 解析结果时，map[string]interface{} 是高频断言场景
从 json.Unmarshal 得到的 interface{} 嵌套结构，字段类型完全动态，不靠断言根本没法取值。但这里容易漏掉两层：键存在性 + 类型匹配。
- 先检查 key 是否在 map 中：
if val, ok := data["name"]; ok，否则断言val.(string)会 panic（因为val是nilinterface） - 再断言类型：
if name, ok := val.(string); ok，两步缺一不可 - 嵌套结构如
data["user"].(map[string]interface{})["age"]，中间任意一层断言失败都 panic，建议拆成独立变量 + 显式if判断
多类型分支别堆 if-else，用 switch v := x.(type)
当一个 interface{} 可能是 string/int/float64/slice 等多种类型时，连续 if 判断可读性差、易漏 else if 覆盖，switch 是 Go 原生支持的语义化写法。
-
switch里的v在每个case中自动是对应类型，不用再断言，比如case string:下v就是string -
default分支必须有，否则遇到未列类型会静默跳过——这不是 bug，是设计，但容易导致逻辑遗漏 - 注意：不能在
case中重复声明同名变量，比如case string: s := v再写case int: s := v会报错，应统一用v或改名
类型断言不是类型转换，别指望它把 int 变 string
x.(string) 只确认 x 底层是不是 string 类型的值，不是“把别的类型转成 string”。想转，得自己调函数，比如 strconv.Itoa() 或 fmt.Sprintf()。
- 常见错误：
if s, ok := num.(string); ok试图把int断言成string，永远ok == false - 反射也不是万能解药：用
reflect.ValueOf(x).String()得到的是值的调试字符串（如"123"），不是类型转换；且reflect开销大，仅在真正需要泛型式解析（如 ORM 映射）时才考虑 - 如果目标是“安全转成某种类型”，优先写专用函数，比如
ToString(v interface{}) string，内部用 switch 处理已知类型，比到处断言更可控
最常被忽略的一点：接口变量本身为 nil 和它装的值为 nil（比如 *string 指向空）是两回事，前者断言必 panic，后者断言可能成功但值是 nil——这个区别在 HTTP 请求体解析或数据库 scan 场景里，一不留神就炸。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
