Interface{} 能接收指针但本身不是指针，无 *interface{}；其 nil 判断需同时满足动态类型和动态值为 nil，否则需类型断言后判空。
interface{} 能接指针，但“接了指针”不等于“接口本身是指针”——这是最常被误解的起点。go 中没有 *interface{} 这种用法，也不该有；真正需要的是：让具体类型以指针形式实现接口，或把指针赋给 interface{} 变量。
为什么不能写 *interface{}？
因为 interface{} 是一个值类型，它内部存的是 （类型，值）二元组。当你写 var i *interface{}，你得到的是“指向一个空接口变量的指针”，而这个指针本身不带任何方法——i.MyMethod() 会直接编译失败，因为 *interface{} 没定义任何方法。
-
interface{}的方法集只在其值类型上定义，不在其指针类型上 - 想让接口能修改原始数据？不是让接口变指针，而是让实现它的结构体方法用指针接收者
- 想避免大结构体拷贝？把结构体指针（如
&MyStruct{}）赋给interface{}即可
指针赋给 interface{} 后，== nil 判断为何失效？
这是生产环境高频踩坑点：一个 nil 指针赋给 interface{}，接口变量本身不为 nil。
var p *String = nil var i interface{} = p fmt.Println(i == nil) // false！ fmt.Printf("%+vn", i) // (*string)(nil)- 原因：
i的动态类型是*string，动态值是nil；接口只有在“动态类型和动态值都为nil”时才等于nil - 安全判空必须先断言再检查：
if v, ok := i.(*string); ok && v == nil { ... } - jsON 反序列化常见场景：
json.Unmarshal(data, &obj)中若obj是nil指针，Unmarshal会 panic；应确保传入非 nil 指针或用new(T)
什么时候必须用指针实现接口？
当接口方法需要修改接收者状态，或结构体较大时，必须用指针接收者——否则值拷贝会导致修改无效，或带来性能损耗。
立即学习“go语言免费学习笔记（深入）”；
type Counter struct{ n int } func (c *Counter) Inc() { c.n++ } // 指针接收者 func (c Counter) Value() int { return c.n } var i interface{ Inc(); Value() int } = &Counter{} // ✅ 正确：*Counter 实现了接口 // var i interface{ Inc(); Value() int } = Counter{} // ❌ 编译错误：Counter 没有 Inc 方法
- 值接收者方法可被值和指针调用；指针接收者方法只能由指针调用
- 一旦某个方法用了指针接收者，整个类型要统一用指针赋值给接口，否则编译失败
- 结构体字段含 slice/map/chan 等引用类型时，即使不修改状态，也建议用指针接收者，避免意外浅拷贝
实际场景：JSON 解析、反射、通用容器怎么用？
这些场景本质都是“需要运行时操作任意类型，并可能写回原值”，所以几乎总是依赖指针 + interface{} 组合。
-
json.Unmarshal第二个参数必须是interface{}，且内部类型必须是指针（如*Person），否则解析结果无法写入目标变量 - 反射中修改结构体字段：
reflect.ValueOf(&s).Elem().FieldByName("Name").SetString("Bob")—— 必须从指针开始，否则.Elem()panic - 通用缓存或中间件封装函数时，若需修改传入对象，签名应为
func Do(v interface{})，但调用方必须传&obj，并在函数内做reflect.ValueOf(v).Elem()判断
Go 的指针与接口关系，核心就一条：接口不决定内存模型，实现它的具体类型才决定。你控制的是“谁来实现”，而不是“接口是不是指针”。
最容易被忽略的，是那个看似无害的 i == nil 判断——它背后藏着类型信息的存在感，而这点，在日志、错误处理、配置加载等环节一旦出错，往往难以复现。