i.(*T) 要求接口值底层必须是 *T 类型，非指针 T 即使实现接口也会失败；它验证动态类型而非方法集，成功断言后可能返回 nil 指针，需用带 ok 的安全写法。
类型断言 i.(*T) 要求接口值底层确实是 *T 类型
接口值 i 存储的是「动态类型 + 动态值」，i.(*T) 不是“尝试转成指针”，而是严格检查：它存的是否就是一个 *T 类型的值。如果存的是 T（非指针），哪怕 T 实现了接口，断言也会失败。
常见错误现象：panic: interface conversion: interface {} is main.MyStruct, not *main.MyStruct
- 使用场景：从
interface{}或泛型约束为any的参数中提取具体指针类型，比如解包 JSON 后想直接拿到结构体指针 - 如果原值是
T，必须先取地址：&t才能成功断言为*T - 不建议靠断言“修复”类型设计——该传
*T的地方就传*T，别依赖运行时补救
i.(*T) 和 i.(T) 在接收者方法集上的差异
Go 接口实现判定看的是「方法集」，而方法集与接收者类型强相关：(*T) 的方法集包含所有以 T 或 *T 为接收者的方法；但 T 的方法集只包含以 T 为接收者的方法。
所以即使 T 有指针接收者方法，i.(T) 成功也不代表你能调用那些方法——因为 T 类型值本身没实现它们。
立即学习“go语言免费学习笔记（深入）”；
- 如果你看到某个接口变量能被
i.(T)断言成功，但调用.SomePtrMethod()报错 undefined，大概率是这里的问题 -
i.(*T)成功，说明底层是*T，它一定拥有完整方法集（含指针和值接收者方法） - 性能上无差异，但语义完全不同：一个在验类型，一个在验方法集覆盖能力
空指针和 nil 接口值在 i.(*T) 中的表现
i.(*T) 对 nil 接口值（i == nil）会 panic；对非 nil 接口值但内部存储的是 (*T)(nil)（即空指针），断言成功，结果是 nil。
常见错误现象：panic: interface conversion: interface {} is nil, not *main.MyStruct
- 判断是否为 nil 接口：用
i == nil，不是i.(*T) == nil - 安全写法是带 ok 的断言：
if p, ok := i.(*T); ok { ... }，这样即使i是(*T)(nil)也能进分支且p == nil - 不要假设
i.(*T)返回非 nil——它完全可能是合法的空指针，后续解引用前仍需判空
泛型函数里做 v.(*T) 断言需要额外约束
泛型参数 T 默认是任意类型，编译器不允许直接对 any 值做 .(T) 或 .(*T)，除非你明确告诉它 T 是可寻址类型或指针类型。
否则报错：cannot use type T as *T in type assertion
- 正确做法：加约束
type T interface{ ~struct{} }并在函数内用any(v).(*T)？不行——依然不合法 - 真正可行的是：把泛型参数设为指针类型约束，如
func f[T interface{ *struct{} }](i any)，再断言i.(T) - 更常见的是放弃断言，改用反射或重构为接收
*T而非any
i.(*T) 看似简单，但背后连着接口底层表示、方法集规则、nil 语义三层细节，任一层理解偏差都会导致 panic 或静默逻辑错误。 
