不能随意互换。Go接口赋值取决于具体类型的方法集：值类型T仅含值接收者方法，T则包含值和指针接收者方法；若接口方法由指针接收者定义，则只有T实现该接口，T会编译报错。
接口赋值时值类型和指针类型是否能互换
不能随意互换。Go 接口变量存储的是 type 和 value 两部分，当具体类型实现接口时，只有该类型（或其指针）**实际实现了接口的所有方法**，才能被赋值给接口。如果一个类型 T 的指针方法集包含接口方法，而值方法集不包含，那么只有 *T 能赋值给该接口，T 会编译报错：cannot use t (type T) as type MyInterface in assignment: T does not implement MyInterface。
- 值类型
T只能调用值接收者方法；指针类型*T既能调用值接收者，也能调用指针接收者方法 - 但接口实现判定只看「方法集」：值类型的方法集 = 所有值接收者方法；指针类型的方法集 = 所有值接收者 + 所有指针接收者方法
- 因此，若接口方法是用指针接收者定义的，只有
*T实现了它，T没有实现 —— 即使你传的是&t，赋值目标也必须是*T类型表达式
传参给接口形参时，值 vs 指针对性能和语义的影响
即使两者都能赋值（比如所有方法都是值接收者），传 T 还是 *T 仍会影响行为：
- 传
T：每次赋值都会拷贝整个结构体。如果T很大（例如含 slice、map 或大量字段），开销明显 - 传
*T：只拷贝 8 字节指针，但后续接口内方法调用若为值接收者，会隐式解引用再拷贝 —— 不改变原值；若为指针接收者，则可修改原值 - 关键点：接口本身不决定是否可修改，真正起作用的是接口方法的接收者类型。例如
func (t *MyStruct) Mutate()在接口上调用时，仍会修改原始实例；而func (t MyStruct) CopyMutate()永远不会影响调用方的值
type Counter struct{ n int }
func (c Counter) Inc() int { c.n++; return c.n } // 值接收者 → 不影响原值
func (c *Counter) IncPtr() int { c.n++; return c.n } // 指针接收者 → 影响原值
var c Counter
var i interface{ Inc() int } = c // OK，但调用 i.Inc() 不改变 c.n
var j interface{ IncPtr() int } = &c // OK，调用 j.IncPtr() 会改变 c.n
空接口 interface{} 是个例外吗
不是例外，而是最宽松的特例。因为 interface{} 没有方法，所以任何类型（包括 T 和 *T）都天然满足它。但这不意味着可以忽略差异：
-
var x interface{} = myStruct存的是myStruct的完整副本 -
var x interface{} = &myStruct存的是指向myStruct的指针，后续类型断言得到的是*MyStruct - 常见陷阱：对
interface{}做reflect.ValueOf(x).Interface后再断言，可能因反射路径丢失原始类型信息导致 panic
() - 更隐蔽的问题：JSON 解码到
interface{}得到的是map[string]interface{}等值类型，不是原始结构体指针，无法反向修改源数据
()如何判断某个类型该用值接收者还是指针接收者实现接口
看两个事实：是否需要修改 receiver 自身状态，以及类型大小是否适合拷贝。
- 只要方法需要修改字段，就必须用指针接收者 —— 值接收者改的是副本，毫无意义
- 如果类型是小结构体（如
type Point struct{ X, Y int }），值接收者更高效且语义清晰（不可变意图明确） - 如果类型含 slice/map/chan/func/interface 字段，或字段较多（> 4 个 int 大小），优先用指针接收者避免拷贝
- 一致性更重要：同一个类型的所有方法最好使用同一种接收者，否则容易在接口赋值时出错。Go 官方建议：“if some methods of a type must have pointer receivers, the rest should too”
最易被忽略的一点：接口变量本身是轻量的，但背后承载的值或指针决定了内存布局和可变性——别只盯着接口声明，要顺藤摸到具体类型的接收者签名。
