go 中嵌入接口不等于实现接口，仅触发方法提升，但字段默认为 nil，调用时 panic；类型断言总成功导致误判；正确做法是避免嵌入接口，改用运行时类型断言检查可选接口。
Go 没有传统意义上的“类”和“继承”，但通过 method 和 interface 能自然表达面向对象的核心思想——封装、多态、解耦。关键不在于模仿语法，而在于理解“行为契约如何被满足”。
为什么 Go 的 method 必须绑定到命名类型？
你不能给 int 或 []string 这类未命名类型直接定义方法，否则会报错：cannot define methods on non-named type。这是因为 Go 要求方法集可明确归属，避免歧义和包间冲突。
实操建议：
- 用
type MyInt int定义命名别名，再为MyInt添加String()方法 - 切片、map、func 等复合类型同理：先命名（如
type UserList []User），再加方法 - 结构体字段若含未导出类型（如
sync.Mutex），注意接收者是否需指针（*T）才能调用其方法
interface{} 和空接口实现多态的边界在哪？
interface{} 是万能接收器，但不是多态的银弹。它只提供“能存任意值”的能力，不提供“能统一调用某行为”的契约。
实操建议：
- 需要统一行为时，定义具体接口（如
type Shape interface { Area() float64 }），而非滥用interface{} -
interface{}常用于泛型前的过渡方案（如日志、反射、JSON 解析），但后续应尽快断言或转换为具体类型 - 过度使用
interface{}会导致编译期检查失效，运行时 panic 风险上升（比如v.(string)断言失败）
方法集与接口实现的隐式关系怎么判断？
一个类型是否实现某个接口，完全由它的方法集决定，且不依赖显式声明。但容易忽略的是：值接收者和指针接收者的方法集不同。
实操建议：
-
T类型的方法集包含所有func (T)方法；*T的方法集包含func (T)和func (*T) - 所以
*T总能实现接口，但T不一定能——尤其当接口方法是func (*T)时 - 常见坑：
var t T; var i Interface = t报错，但var i Interface = &t成功，本质是方法集不匹配
嵌入结构体时，方法提升（promotion）的陷阱有哪些？
嵌入（embedding）不是继承。被嵌入类型的公开方法会被“提升”到外层结构体，但提升后的方法接收者仍是原类型，不会自动转为外层类型。
实操建议：
- 若嵌入类型方法修改了自身字段，而外层结构体字段与之同名，那修改的是嵌入字段，不是外层字段
- 嵌入多个同名方法时（如两个都叫
Close()），外层结构体无法直接调用，必须显式限定：s.File.Close()、s.Network.Close() - 嵌入接口（如
type Server struct { io.Closer }）仅表示“具备该行为”，不提供实现，仍需手动实现方法
真正卡住人的往往不是语法，而是“哪个类型该定义什么方法”“这个接口到底要约束什么行为”。写完一段代码后，不妨反问：如果换掉实现，调用方是否完全无感？如果答案是否定的，说明接口设计或方法集还没对齐。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
