本文深入解析 go 语言中复合字面量（如 cncrt{3} 和 &cncrt{3}）如何满足接口要求，阐明其底层方法集规则、接口值的 (type, value) 表示机制，并结合规范条款说明为何两者均可赋值给同一接口。
本文深入解析 go 语言中复合字面量（如 cncrt{3} 和 &cncrt{3}）如何满足接口要求，阐明其底层方法集规则、接口值的 (type, value) 表示机制，并结合规范条款说明为何两者均可赋值给同一接口。
在 Go 中，一个类型是否实现某个接口，完全取决于其方法集（method set）是否包含该接口声明的所有方法。这与值是“值类型”还是“指针类型”密切相关——但并非简单等价于“必须是指针才能实现接口”。关键在于 Go 规范中对方法集的明确定义。
The method set of the corresponding pointer type *T is the set of all methods declared with receiver *T or T (that is, it also contains the method set of T).
The method set of any other type T consists of all methods declared with receiver type T.
这意味着：
- 类型 cncrt 的方法集仅包含接收者为 cncrt 的方法；
- 类型 *cncrt 的方法集则同时包含接收者为 cncrt 和 *cncrt 的所有方法。
在你的示例中，rx() 方法的接收者是 cncrt（值接收者）：
func (c cncrt) rx() int { return c.x }因此：
- cncrt 的方法集 ✅ 包含 rx() → 实现 ntfc 接口；
- *cncrt 的方法集 ✅ 也包含 rx()（因继承了 cncrt 的全部方法）→ 同样实现 ntfc 接口。
这就是为什么以下两个函数均能合法返回 ntfc 接口：
func rtrnsNtfca() ntfc { return &cncrt{3} } // *cncrt 值 → 接口动态类型为 *cncrt
func rtrnsNtfc() ntfc { return cncrt{3} } // cncrt 值 → 接口动态类型为 cncrt二者返回的都是 ntfc 接口值，但内部表示不同：
✅ rtrnsNtfca() 返回的接口值中，*动态类型为 `cncrt，动态值为指向新分配结构体的指针**； ✅rtrnsNtfc()返回的接口值中，**动态类型为cncrt`，动态值为栈上（或逃逸分析决定的）结构体副本**。
当调用 rtrnsNtfc().rx() 时，Go 运行时直接以 cncrt{3} 作为接收者执行 rx()；
当调用 rtrnsNtfca().rx() 时，接收者是 *cncrt，Go 会自动解引用该指针（即 (*ptr).rx()），而由于 rx() 是值接收者，它仍能正常工作。
? 补充：反向自动取址（Auto-dereferencing / Auto-addressing）
若 rx() 改为指针接收者 func (c *cncrt) rx() int，则只有 *cncrt 能直接实现 ntfc；但若有一个可寻址的 cncrt 变量（如 var x cncrt），你仍可写 x.rx() —— 编译器会自动插入 &x 转换（见 Spec: Calls）。然而，复合字面量 cncrt{3} 默认不可寻址，因此不能用于触发此规则（即 cncrt{3}.rx() 在指针接收者下会编译失败）。
✅ 正确实践建议：
- 若方法需修改接收者状态，优先使用指针接收者；
- 若方法只读且结构体较小，值接收者更高效且语义清晰；
- 只要方法集匹配，值或指针字面量均可直接赋值给接口——这是 Go 接口设计的优雅之处，而非“隐式转换”陷阱。
最后，关于代码分享：Playground 链接（如 play.golang.org/p/...）非常便于快速复现，但在正式文档或教程中，仍应内联关键代码片段。原因有三：① 确保内容自包含、长期可读；② 避免外部链接失效导致信息丢失；③ 方便读者离线查阅与本地调试。Playground 应作为辅助验证手段，而非唯一代码源。
