Go中单值类型断言失败会panic，因设计上强制处理类型不匹配；应优先用双值断言v, ok := i.(T)，并注意值类型与指针类型的严格区分。
类型断言失败时 panic 而不是返回零值？
Go 中对 interface{} 做类型断言时，如果用单值形式（v := i.(T)），一旦 i 不是 T 类型或其指针，程序会直接 panic。这不是 bug，是设计选择——它强制你面对类型不匹配的现实。
常见错误现象：传入 nil 接口、传入值类型却断言指针类型（比如接口里存的是 MyStruct{}，却写 i.(*MyStruct)）、或结构体字段导出状态不一致导致反射/断言失效。
- 永远优先用双值断言：
v, ok := i.(*MyStruct)，ok为false时不 panic - 确认原始值是否真的是指针：若源数据来自
json.Unmarshal或map[string]interface{}解析，默认生成的是值类型，不是指针 - 注意嵌套结构：如果接口里存的是
*map[string]interface{}，断言成*MyStruct必然失败
断言到 *T 但原接口里是 T 值类型？
Go 的接口存储的是具体值的拷贝，且类型信息严格绑定。接口中存了 MyStruct{X: 1}（值类型），就不能安全断言为 *MyStruct——它们是两个不同底层类型，内存布局和方法集都不同。
使用场景典型出现在：从配置解析（如 toml.Unmarshal）、RPC 返回值、或泛型函数输入中拿到 interface{} 后想转成结构体指针做修改。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 检查原始赋值逻辑：是不是该用
&myStruct而非myStruct存入接口 - 如果无法改源头，可先断言为值类型，再取地址：
if v, ok := i.(MyStruct); ok { ptr := &v }（注意：v是副本，&v只在当前作用域有效） - 别依赖
reflect.Value.Interface()强转：反射得到的Value若本身不可寻址（比如来自 map 或 json 解析），调用.Addr()会 panic
为什么 json.Unmarshal 后的 interface{} 不能直接断言为 *T？
json.Unmarshal 对任意 interface{} 参数，只会填充值类型（T），不会自动分配堆内存并返回指针（*T）。这是它的行为契约，不是限制。
错误现象：var v interface{}; json.Unmarshal(data, &v); p := v.(*MyStruct) → panic: interface conversion: interface {} is MyStruct, not *MyStruct。
- 正确做法一（推荐）：直接解到目标指针：
var s MyStruct; json.Unmarshal(data, &s) - 正确做法二：先断言为值类型，再显式取地址（仅当必须保持
interface{}中间态时）：if val, ok := v.(MyStruct); ok { ptr := &val } - 避免把
json.RawMessage当作通用容器反复断言：它本质是[]byte，不是结构体，需二次解析
接口含方法时，断言指针类型会影响方法集匹配
Go 中，类型 T 和 *T 的方法集不同：*T 能调用接收者为 T 或 *T 的方法；而 T 只能调用接收者为 T 的方法。接口的实现判定，取决于具体值能否满足接口定义的方法签名。
这意味着：一个实现了某接口的 *MyStruct，其对应的 MyStruct 值未必实现同一接口（尤其当接口方法接收者全为指针时）。
- 断言前先确认接口定义里方法的接收者类型：用
go doc或 IDE 查看，比如io.Reader.Read接收者是*T，所以只有*bytes.Buffer满足，bytes.Buffer{}不满足 - 若断言后调用方法报
cannot call pointer method on ...，说明你拿到了值类型却试图通过它调用指针接收者方法 - 不要靠“看起来像”来断言：即使结构体字段完全一致，
T和*T在接口层面就是两个独立类型
