Go中需用v, ok := x.(T)显式断言interface{}的具体类型，优先双值形式防panic；JSON解析后须逐层检查key存在性和类型；type switch可清晰处理多类型；接口间断言要求动态类型完整实现目标接口。
用 type assertion 从 interface{} 拿出具体类型值
Go 里没有隐式类型转换，interface{} 是万能容器，但要操作里面的数据，必须显式断言。语法是 v, ok := x.(T)，其中 x 是 interface 类型变量，T 是你想转成的具体类型。
安全写法永远优先用双值形式（带 ok），避免 panic。如果确定类型一定匹配（比如刚放进 map 的值又立刻取出来），才考虑单值形式 v := x.(T)，但生产代码里基本不推荐。
- 常见错误：直接写
x.(string)而没检查ok，一旦x实际是int就 panic - 空接口
interface{}和自定义接口都支持 type assertion，但只能断言为它实际存储的类型或其底层类型兼容的接口 - 断言失败时，
v是目标类型的零值（如""、0、nil），ok是false
断言失败时 panic 的典型场景
最常踩坑的是在 JSON 解析后对 map[string]interface{} 做嵌套断言。比如 data["user"] 看起来像 map，但其实可能是 nil、float64（JSON 数字默认转成 float64），或者根本不存在这个 key。
示例：
立即学习“go语言免费学习笔记（深入）”；
userMap := data["user"].(map[string]interface{}) // 危险！data["user"] 可能是 nil 或 float64
正确做法是逐层检查：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先确认 key 存在：
if user, ok := data["user"]; ok - 再断言类型：
if userMap, ok := user.(map[string]interface{}); ok - 每一步都用
ok控制流程，别链式调用
用 type switch 处理多种可能类型
当一个 interface{} 可能是 string/int/bool/slice 等多种类型时，硬写一堆 if v, ok := x.(T) 很啰嗦。用 switch 更清晰：
switch v := x.(type) {
case string:
fmt.Println("string:", v)
case int, int64:
fmt.Println("number:", v)
case []interface{}:
fmt.Println("array len:", len(v))
default:
fmt.Println("unknown type:", reflect.TypeOf(x))
}
注意：type switch 的 v 在每个 case 分支里作用域独立，不能跨 case 使用；default 分支不是可选的，建议加上，避免漏掉类型。
- 别在
case里对v做二次断言（比如v.(string)），它已经是该类型的值了 - 如果需要同时处理指针和值类型（如
*MyStruct和MyStruct），得分开写两个case - 性能上，
type switch和多个if差不多，不用刻意避讳
interface 断言到另一个 interface 的限制
不能直接把一个接口变量断言成另一个接口，除非它的动态类型**实现了**那个接口。比如你有一个 io.Reader 变量 r，想断言成 io.ReadCloser，只有当 r 底层值同时实现了 Read 和 Close 方法才行。
常见误解：以为只要两个接口方法集有交集就能转。错。Go 看的是动态类型的完整实现，不是静态方法签名匹配。
- 错误示例：
var r io.Reader = bytes.NewReader([]byte("x")); rc := r.(io.ReadCloser)→ panic，因为bytes.Reader没实现Close - 正确做法：用
io.NopCloser(r)包一层，或者换用真正实现了ReadCloser的类型（如os.File） - 断言失败时不会自动“升级”类型，也不会触发任何构造逻辑
断言本质是运行时类型检查，不是类型转换。底层数据没变，只是 Go 告诉你“现在可以按这个类型用了”。最容易被忽略的是：断言成功只代表那一刻类型匹配，如果原值是 map 或 slice，后续修改仍会影响所有引用——它不是深拷贝。
