Go虽无class，但通过struct、method、接口和组合实现封装、多态与抽象；接口是多态唯一载体，强调小而专、调用方定义；嵌入实现代码复用而非继承，属“has-a”关系；设计模式常被简化为函数或接口；nil接口易致panic。
Go没有class，但有面向对象的实质行为
Go语言不提供class、继承、重载等传统OOP语法，但它通过struct、method、接口（interface）和组合（embedding）实现了面向对象的核心能力：封装、多态、一定程度的抽象。关键不在于“有没有class”，而在于“能否表达对象职责与协作关系”。
常见误解是把“无继承”等同于“非OOP”。实际上，Go用接口解耦行为契约，用组合替代垂直继承链，更贴近现实建模——比如File和NetworkConn都实现io.Reader，但彼此无关；它们不是“子类”，却是同一角色的合格参与者。
接口即契约：Go中多态的唯一载体
Go的多态完全依赖接口。一个类型只要实现了接口所有方法，就自动满足该接口，无需显式声明implements。这带来高度灵活性，也埋下隐式依赖风险。
-
io.Writer只定义一个Write([]byte) (int, error)，os.File、bytes.Buffer、http.ResponseWriter都实现它，却互不继承 - 接口应小而专注（如
Stringer仅含String() string），避免大接口导致实现负担过重 - 定义接口的位置很重要：调用方（consumer）定义接口，而非实现方（provider）——否则容易出现“为实现而接口”的反模式
组合优于继承：嵌入（embedding）不是“父类复用”
Go用struct嵌入实现代码复用，但嵌入不是继承。被嵌入字段的方法被“提升”（promoted）到外层结构体，仅此而已；没有虚函数表、没有运行时方法覆盖、没有super调用语义。
立即学习“go语言免费学习笔记（深入）”；
例如：
type Logger struct{ /* ... */ }
func (l *Logger) Log(msg string) { /* ... */ }
type Server struct {
Logger // 嵌入
port int
}
此时server.Log("start")可调用，但Server并未“成为”Logger的子类型；它只是拥有了Log方法的快捷访问路径。若Logger和Server各自都有Close()，则Server.Close()不会自动调用Logger.Close()——必须显式写s.Logger.Close()。
- 嵌入用于“has-a”或“uses-a”，不是“is-a”
- 多个嵌入字段方法名冲突时，必须显式限定：
s.Logger.Close()或s.Conn.Close() - 嵌入指针（
*Logger）可避免值拷贝，也便于后续替换实现
设计模式在Go中常被“降维”实现
很多经典OOP设计模式在Go里不需要完整骨架。因为接口和组合天然支持解耦，不少模式退化为几行代码或根本无需模式。
-
策略模式 → 直接传入函数或接口实例：
Sort(data []int, less func(i, j int) bool)，比定义LessStrategy接口+多个实现更轻量 -
装饰器模式 → 用包装结构体+接口转发，例如
type LoggingWriter struct{ w io.Writer }，实现Write时先log再调w.Write -
工厂模式 → 多数场景只需一个返回接口的函数：
func NewReader(src string) io.Reader，无需抽象工厂类层级 -
观察者模式 → 常用
chan或回调函数代替事件总线，避免维护订阅列表和生命周期
真正容易被忽略的是：Go中接口的零值是nil，而nil接口变量不等于nil底层值——当接口变量存储了*T且T为nil时，接口本身非nil，但调用其方法会panic。这是最常踩的空指针坑，比传统OOP语言更隐蔽。
