Java - Tony Bai

标签 Java 下的文章

Go并行编程的“第一性原理”：Guy Steele 教你如何“不去想”并行

六月 29, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/06/29/thinking-parallel-programming

大家好，我是Tony Bai。

在多核处理器已成为标配的今天，并行编程能力几乎是每一位后端工程师的必备技能。Go 语言凭借其简洁的 Goroutine 和 Channel 设计，极大地降低了并发编程的门槛，让我们能相对轻松地驾驭并发。但是，写出“能跑”的并发代码，和写出“优雅、高效、可维护”的并行程序之间，往往还隔着一层思维模式的窗户纸。

今天，我想和大家分享一位计算机科学巨匠——Guy L. Steele Jr.——关于并行编程的深刻洞见。在深入探讨之前，有必要简单介绍一下这位大神：他是 Scheme 语言的共同创造者，Common Lisp 标准的核心定义者，Java 语言设计的关键人物，也是 Sun/Oracle 专门为并行计算设计的 Fortress 语言的领导者。他的见解，源于横跨数十年、从学术到工业的深厚语言设计实践。

他早在多年前（其经典 PPT《How to Think about Parallel Programming—Not!》可以追溯到 2009 年甚至更早）就提出了一些颠覆传统认知，但至今依然闪耀着智慧光芒的核心思想。这些思想，对于我们 Gopher 来说，不啻为并行编程的“第一性原理”，能帮助我们从根本上理解如何更好地设计并行系统。

Steele 的核心论点是什么？一言以蔽之：

“编写并行应用程序的最佳方式，就是不必去考虑并行本身。”

这听起来是不是有点反直觉？别急，让我们慢慢拆解 Steele 的智慧。

并行编程的“敌人”：根深蒂固的“累加器思维”

Steele 犀利地指出，我们过去几十年在顺序编程中养成的许多习惯，正在成为并行编程的障碍。其中，“累加器 (Accumulators)”模式首当其冲被他判为“BAD”。

什么是累加器模式？简单来说，就是通过一个共享状态（累加器），不断迭代地用新数据去更新这个状态。一个最经典的例子就是顺序求和：

// 典型的顺序累加求和
func sumSequential(nums []int) int64 {
    var total int64 = 0 // 我就是那个“累加器” total
    for _, n := range nums {
        total += int64(n) // 不断更新自己
    }
    return total
}

这段代码再熟悉不过了，对吧？但在 Steele 看来，这种写法是并行编程的“噩梦”。为什么？

强烈的顺序依赖： 每一步的 total 都依赖于上一步的结果。这种串行依赖使得直接将其并行化变得异常困难。如果多个 Goroutine 同时去更新 total，就需要引入锁或其他同步机制，不仅增加了复杂性，还可能因为锁竞争而严重影响性能，甚至违背了并行的初衷。
鼓励可变状态与副作用： 累加器本身就是一个可变状态，操作带有副作用。这在并行环境下是诸多问题的根源。

Steele 甚至略带调侃地说：DO 循环太上世纪五十年代了！… 当你写下 SUM = 0 并开始累加时，你就已经把自己“坑”了。

那么，我们应该如何摆脱这种“累加器思维”的桎梏呢？

Steele的药方：拥抱“分治”与“结合性”

Steele 提倡的核心思想是 “分治 (Divide-and-Conquer)” 和利用操作的 “代数性质 (Algebraic Properties)”，尤其是 “结合性 (Associativity)”。

分治 (Divide-and-Conquer)： 将大问题分解成若干个独立的、可以并行处理的子问题。每个子问题独立求解后，再将结果合并。这天然地契合了并行的思想。
结合性 (Associativity)： 如果一个操作 ⊕ 满足结合律，即 (a ⊕ b) ⊕ c = a ⊕ (b ⊕ c)，那么在合并子问题的结果时，合并的顺序就不重要了。这给予了并行执行极大的“自由度”。例如，加法 + 和乘法 * 都满足结合律。

让我们用 Go 来实践一下这种思想，改造上面的求和函数。

Go 实践 1：基于 Goroutine 和 Channel 的分块并行求和

我们可以将数组切分成若干块 (chunk)，每个 Goroutine 负责计算一块的和，最后将各块的结果汇总。

import (
    "runtime"
    "sync"
)

func sumParallelChunks(nums []int, numChunks int) int64 {
    if len(nums) == 0 { return 0 }
    if numChunks <= 0 { numChunks = runtime.NumCPU() } // 默认使用CPU核心数作为块数
    if len(nums) < numChunks { numChunks = len(nums) }

    results := make(chan int64, numChunks)
    chunkSize := (len(nums) + numChunks - 1) / numChunks 

    for i := 0; i < numChunks; i++ {
        start := i * chunkSize
        end := (i + 1) * chunkSize
        if end > len(nums) { end = len(nums) }

        // 每个goroutine处理一个独立的块
        go func(chunk []int) {
            var localSum int64 = 0
            for _, n := range chunk { // 块内部仍然是顺序累加，但这是局部行为
                localSum += int64(n)
            }
            results <- localSum // 将局部结果发送到channel
        }(nums[start:end])
    }

    var total int64 = 0
    for i := 0; i < numChunks; i++ {
        total += <-results // 合并结果，加法是结合的！顺序不重要
    }
    return total
}

Go 实践 2：递归分治的并行求和 (更纯粹地体现分治)

对于分治思想，递归往往是更自然的表达：

// 辅助函数，保持接口一致性
func sumRecursiveParallelEntry(nums []int) int64 {
    // 设定一个阈值，小于此阈值则顺序计算，避免过多goroutine开销
    const threshold = 1024
    return sumRecursiveParallel(nums, threshold)
}

func sumRecursiveParallel(nums []int, threshold int) int64 {
    if len(nums) == 0 { return 0 }
    if len(nums) < threshold {
        return sumSequential(nums) // 小任务直接顺序计算
    }

    mid := len(nums) / 2

    var sumLeft int64
    var wg sync.WaitGroup
    wg.Add(1) // 我们需要等待左半部分的计算结果
    go func() {
        defer wg.Done()
        sumLeft = sumRecursiveParallel(nums[:mid], threshold)
    }()

    // 右半部分可以在当前goroutine计算，也可以再开一个goroutine
    sumRight := sumRecursiveParallel(nums[mid:], threshold)

    wg.Wait() // 等待左半部分完成

    return sumLeft + sumRight // 合并，加法是结合的
}

基准测试：并行真的更快吗？

理论归理论，实践是检验真理的唯一标准。我们为上述三个求和函数编写了基准测试，在一个典型的多核开发机上运行（例如，4 核 8 线程的 CPU）。我们使用一个包含 1000 万个整数的切片作为输入。

// benchmark_test.go
package main

import (
    "math/rand"
    "runtime"
    "testing"
    "time"
)

var testNums []int

func init() {
    rand.Seed(time.Now().UnixNano())
    testNums = make([]int, 10000000) // 10 million numbers
    for i := range testNums {
        testNums[i] = rand.Intn(1000)
    }
}

func BenchmarkSumSequential(b *testing.B) {
    for i := 0; i < b.N; i++ {
        sumSequential(testNums)
    }
}

func BenchmarkSumParallelChunks(b *testing.B) {
    numChunks := runtime.NumCPU()
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        sumParallelChunks(testNums, numChunks)
    }
}

func BenchmarkSumRecursiveParallel(b *testing.B) {
    for i := 0; i < b.N; i++ {
        sumRecursiveParallelEntry(testNums)
    }
}

典型的基准测试结果可能如下 (具体数字会因机器而异)：

$go test -bench .
goos: darwin
goarch: amd64
pkg: demo
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkSumSequential-8                 429       2784507 ns/op
BenchmarkSumParallelChunks-8             520       1985197 ns/op
BenchmarkSumRecursiveParallel-8          265       4420254 ns/op
PASS
ok      demo    4.612s

从结果可以看出：

sumSequential 作为基线，但顺序版本的速度并非最慢。
sumParallelChunks 显著快于顺序版本，它充分利用了多核 CPU 的优势，并在这个特定场景下可能因为更直接的控制和较少的递归开销而略胜一筹，但这取决于具体实现和输入规模。而sumRecursiveParallel虽是并行，但却因为较多的goroutine调度(数量大于机器核数)与递归的开销拖慢了执行的速度。

分治与性能：并非总是“更快”的银弹

看到上面的基准测试，你曾经认为的“分治 + 并行”总是能带来性能提升的结论是不成立的。然而，这里需要强调：分治策略本身是为了“能够”并行化，而不是保证在所有情况下都比聪明的顺序算法更快。

这是因为并行化是有成本的：

任务分解与合并开销： 将问题分解、分发给 Goroutine、以及最后合并结果都需要时间。
Goroutine 创建与调度开销： 虽然 Go 的 Goroutine 很轻量，但创建和调度百万个 Goroutine 仍然有不可忽视的开销。这就是为什么在 sumRecursiveParallel 中我们设置了一个 threshold，当问题规模小于阈值时，退化为顺序执行。
通信开销： Channel 通信比直接的函数调用要慢。
同步开销： 如果子问题间不是完全独立，或者合并过程复杂，可能需要额外的同步（如 sync.WaitGroup 或互斥锁），这也会引入开销。

因此，“分治”的性能优势通常在以下情况才能显现：

问题规模足够大： 大到足以摊平并行化的固定开销。
子问题真正独立： 减少或避免同步需求。
合并操作高效： 合并步骤不能成为新的瓶颈。
有足够的并行资源： 即拥有足够的多核 CPU 来同时执行子任务。

如果问题规模很小，或者并行化引入的开销大于节省的时间，那么精心优化的顺序算法可能反而更快。Steele 的核心观点在于，采用分治和关注独立性的设计，使得你的程序具备了“可并行化”的潜力，当资源允许且问题规模合适时，就能获得加速。更重要的是，这种设计往往更清晰、更易于推理和维护。

“独立性”是核心，而非“并行”本身

Steele 强调：“问题的核心并非并行本身，而是独立性。”

如果我们能够将问题分解成独立的部分，并且定义出具有良好代数性质（如结合性）的合并操作，那么并行化就成了一件相对自然和简单的事情。语言和运行时可以更好地帮助我们调度这些独立的任务。

这里，你可能会觉得 Steele 的思想与另一位 Go 圈尽人皆知的思想领袖 Rob Pike 的名言“Concurrency is not Parallelism”有异曲同工之妙。确实如此！

他们都在强调开发者应将关注点从底层执行细节提升到更高层次的程序结构设计上。一个结构良好的程序，自然就具备了高效执行的潜力。

Pike 说： 不要去想“并行”(Parallelism)。去想“并发”(Concurrency)——如何把你的程序组织成一组可独立执行、通过通信来协作的组件（Goroutines）。
Steele 说： 不要去想“并行”(Parallelism)。去想“独立性”(Independence)——如何把你的问题分解成独立的子问题，并找到一个满足结合律的合并操作。

他们的思想完美互补：

Pike 的思想为我们提供了构建程序的“骨架”：我们使用 goroutine 和 channel 来搭建并发结构。
Steele 的思想则为我们填充了“血肉”：我们确保每个 goroutine 的工作是真正独立的，并且我们用来合并结果的操作是结合性的。

例如，我们的并行求和示例，正是用 Goroutine（Pike 的工具）来执行独立的求和任务（Steele 的独立性原则），然后用 + 这个结合性操作来合并结果。一个优秀的 Gopher，脑中应该同时有这两个声音在对话。

Gopher 的思维重塑：从“怎么做”到“是什么”

Steele 的思想，鼓励我们从更本质的层面思考问题：

关注“是什么 (What)”而非“怎么做 (How)”： 就像数学家写 Σxᵢ 一样，先声明意图（求和），而不是一开始就陷入具体的循环和累加步骤。Fortran 90 的 SUM(X) 就是这种思想的体现。
寻找结合性的合并操作： 对于一个问题，思考能否将其分解，并找到一个满足结合律的合并方法。这往往需要对问题域有更深的理解。Steele 在 PPT 中展示了如何通过定义 WordState 及其结合性的 ⊕ 操作来并行化“字符串分词”问题，非常精彩。
拥抱不可变性与纯函数： 尽可能使子问题的处理函数是纯函数（无副作用，相同输入总有相同输出），这能极大地简化并行程序的推理。
可复现性至关重要： Steele 强调，为了调试，可复现性极其重要，甚至值得牺牲一些性能。具有结合性的操作通常更容易保证结果的可复现性（即使并行执行顺序不同，最终结果也应一致）。

小结：让并行“自然发生”——Go 做到了吗？

Guy L. Steele Jr. 的思想提醒我们，真正的并行编程高手，不是那些能玩转各种复杂锁和同步原语的“技巧大师”，而是那些能洞察问题本质，将其分解为独立单元，并用优雅的代数方式重新组合的人。他的理想是让并行性像内存管理（垃圾回收）一样，成为语言和运行时为我们处理好的事情，让开发者可以更专注于业务逻辑本身。

那么，Go 语言在“让并行自然发生”这条路上走了多远呢？

显著进步： 相比于 C/C++/Java 等需要手动管理线程、锁、条件变量的语言，Go 通过 go 关键字启动 Goroutine，并通过 Channel 进行通信和同步，极大地简化了并发编程的门槛和心智负担。可以说，Go 让“思考独立性”和“实现基本并发”变得前所未有地容易。
尚未完全“自动化”： 尽管如此，Go 的并行还远未达到像垃圾回收那样“开发者无感知”的程度。开发者仍然需要：
- 主动设计并行策略： 如何分解问题（如分块、递归分治），如何选择合适的并发原语（Channel, WaitGroup, Mutex）。
- 管理并发单元： 决定启动多少 Goroutine，如何处理它们的生命周期和错误。
- 关注数据竞争： 虽然 Channel 有助于避免数据竞争，但如果共享了内存且没有正确同步，数据竞争依然是 Gopher 需要面对的问题（Go 的 race detector 是一个好帮手）。
- 理解并选择合并策略： 如何设计具有良好代数性质的合并操作，这仍依赖于开发者的洞察力。
与其他语言的比较：
- Erlang/Elixir (Actor Model)： 在进程隔离和消息传递方面与 Go 的 CSP 有相似的哲学，也致力于简化并发。它们在容错和分布式方面有独特优势。
- 函数式语言 (Haskell, Clojure)： 它们强调的不可变性和纯函数天然适合并行化，并提供了一些高级的并行集合与抽象。
- Rust： 通过其所有权系统和 Send/Sync trait，在编译期提供了强大的内存安全和线程安全保证。其 async/await 提供了另一种并发模型。Rust 在追求极致性能和安全性的同时，其并发的学习曲线也相对陡峭。

Go 的优势在于其务实的平衡： 它提供了足够简单且强大的并发原语，使得开发者能够以较低的成本实现高效的并发和并行，尤其适合构建网络服务和分布式系统。它鼓励开发者思考任务的独立性，但将“如何并行”的许多细节交由开发者根据具体场景来设计。

最终，要达到 Steele 的理想境界——让并行编程像呼吸一样自然，还需要语言、运行时甚至硬件层面的持续进化。但 Go 毫无疑问地在这个方向上迈出了坚实而重要的一大步，它为我们 Gopher 提供了一套强大的工具，去实践“不去想并行（细节），而去思考独立性与组合”的编程智慧。

你对 Guy Steele 的这些观点有什么看法？在你的 Go 并行编程实践中，是否也曾遇到过“累加器思维”带来的困扰，或者通过“分治”获得了更好的解决方案？欢迎在评论区分享你的经验和思考！

参考资料地址 – https://www.infoq.com/presentations/Thinking-Parallel-Programming/

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

Gopher视角：Java 开发者转向 Go 时，最需要“掰过来”的几个习惯

六月 27, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/06/27/from-java-to-go

大家好，我是Tony Bai。

各位Gopher以及正在望向Go世界的Java老兵们，近些年，我们能明显感觉到一股从Java等“传统豪强”语言转向Go的潮流。无论是追求极致的并发性能、云原生生态的天然亲和力，还是那份独有的简洁与高效，Go都吸引了无数开发者。然而，从Java的“舒适区”迈向Go的“新大陆”，绝不仅仅是学习一套新语法那么简单，它更像是一场思维模式的“格式化”与“重装”。

作为一名在Go语言世界摸爬滚打多年的Gopher，我见过许多优秀的Java开发者在初探Go时，会不自觉地带着一些“根深蒂固”的Java习惯。这些习惯在Java中或许是最佳实践，但在Go的语境下，却可能显得“水土不服”，甚至成为理解和掌握Go精髓的绊脚石。

今天，我就从Gopher的视角，和大家聊聊那些Java开发者在转向Go时，最需要刻意“掰过来”的几个习惯。希望能帮助大家更顺畅地融入Go的生态，体会到Go语言设计的精妙之处。

习惯一：接口的“名分”执念 -> 拥抱“能力”驱动

Java的习惯：

在Java世界里，接口（Interface）是神圣的。一个类要实现一个接口，必须堂堂正正地使用 implements 关键字进行声明，验明正身，告诉编译器和所有开发者：“我，某某类，实现了某某接口！” 这是一种名义类型系统（Nominal Typing）的体现，强调“你是谁”。

// Java
interface Writer {
    void write(String data);
}

class FileWriter implements Writer { // 必须显式声明
    @Override
    public void write(String data) {
        System.out.println("Writing to file: " + data);
    }
}

Go的转变：

Go语言则推崇结构化类型系统（Structural Typing），也就是我们常说的“鸭子类型”——“如果一个东西走起来像鸭子，叫起来像鸭子，那么它就是一只鸭子。” 在Go中，一个类型是否实现了一个接口，只看它是否实现了接口所要求的所有方法，无需显式声明。

更重要的是Go社区推崇的理念：“Define interfaces where they are used, not where they are implemented.”（在使用者处定义接口，而非实现者处）。

// Go
// 使用者（比如一个日志包）定义它需要的Write能力
type Writer interface {
    Write(data string) (int, error)
}

// 实现者（比如文件写入模块）
type FileWriter struct{}

func (fw *FileWriter) Write(data string) (int, error) {
    // ... 写入文件逻辑 ...
    fmt.Println("Writing to file:", data)
    return len(data), nil
}

// 无需声明 FileWriter 实现了 Writer，编译器会自动检查
// var w Writer = &FileWriter{} // 这是合法的

为什么要“掰过来”？

解耦大师：Go的隐式接口使得实现方和使用方可以完全解耦。使用方只关心“我需要什么能力”，而不关心“谁提供了这个能力，以及它还提供了什么其他能力”。这使得代码更加灵活，依赖关系更清晰。
测试的福音：你可以轻易地为你代码中的依赖定义一个小接口，并在测试中提供一个轻量级的mock实现，而无需修改被测试代码或依赖的原始定义。
避免臃肿接口：Java中常为了通用性设计出庞大的接口，而Go鼓励定义小而美的接口，按需取材。

Gopher建议：

放下对 implements 的执念。在Go中，开始思考你的函数或模块真正需要依赖对象的哪些行为（方法），然后为这些行为定义一个小巧的接口。你会发现，代码的扩展性和可维护性瞬间提升。

习惯二：错误处理的“大包大揽” -> 转向“步步为营”

Java的习惯：

Java的 try-catch-finally 异常处理机制非常强大。开发者习惯于将可能出错的代码块包裹起来，然后在一个或多个 catch 块中集中处理不同类型的异常。这种方式的好处是错误处理逻辑相对集中，但有时也容易导致错误被“吞掉”或处理得不够精确。

// Java
public void processFile(String fileName) {
    try {
        // ... 一系列可能抛出IOException的操作 ...
        FileInputStream fis = new FileInputStream(fileName);
        // ... read from fis ...
        fis.close();
    } catch (FileNotFoundException e) {
        System.err.println("File not found: " + e.getMessage());
    } catch (IOException e) {
        System.err.println("Error reading file: " + e.getMessage());
    } finally {
        // ... 资源清理 ...
    }
}

Go的转变：

Go语言对错误处理采取了截然不同的策略：显式错误返回。函数如果可能出错，会将 error 作为其多个返回值中的最后一个。调用者必须（或者说，强烈建议）检查这个 error 值。

// Go
func ProcessFile(fileName string) error {
    file, err := os.Open(fileName) // 操作可能返回错误
    if err != nil {                // 显式检查错误
        return fmt.Errorf("opening file %s failed: %w", fileName, err)
    }
    defer file.Close() // 优雅关闭

    // ... use file ...
    _, err = file.Read(make([]byte, 10))
    if err != nil {
         // 如果是 EOF，可能不算真正的错误，根据业务处理
        if err == io.EOF {
            return nil // 假设读到末尾是正常结束
        }
        return fmt.Errorf("reading from file %s failed: %w", fileName, err)
    }
    return nil // 一切顺利
}

为什么要“掰过来”？

错误也是一等公民：Go的设计哲学认为错误是程序正常流程的一部分，而不是“异常情况”。显式处理让开发者无法忽视错误，从而写出更健壮的代码。
控制流更清晰：if err != nil 的模式使得错误处理逻辑紧跟在可能出错的操作之后，代码的控制流一目了然。
没有隐藏的“炸弹”：不像Java的checked exceptions和unchecked exceptions可能在不经意间“爆炸”，Go的错误传递路径非常明确。

Gopher建议：

拥抱 if err != nil！不要觉得它啰嗦。这是Go语言深思熟虑的设计。学会使用 fmt.Errorf 配合 %w 来包装错误，形成错误链；学会使用 errors.Is 和 errors.As 来判断和提取特定错误。你会发现，这种“步步为营”的错误处理方式，能让你对程序的每一个环节都更有掌控感。

习惯三：包与命名的“层峦叠嶂” -> 追求“大道至简”

Java的习惯：

Java的包（package）名往往比较长，层级也深，比如 com.mycompany.project.module.feature。类名有时为了避免与SDK或其他库中的类名冲突，也会加上项目或模块前缀，例如 MyProjectUserService。这在大型项目中是为了保证唯一性和组织性。

// Java
// package com.mycompany.fantasticdb.client;
// public class FantasticDBClient { ... }

// 使用时
// import com.mycompany.fantasticdb.client.FantasticDBClient;
// FantasticDBClient client = new FantasticDBClient();

Go的转变：

Go的包路径虽然也可能包含域名和项目路径（例如 github.com/user/project/pkgname），但在代码中引用时，通常只使用包的最后一级名称。Go强烈建议避免包名和类型名“口吃”（stuttering）。比如，database/sql 包中，类型是 sql.DB 而不是 sql.SQLDB。

// Go
// 包声明: package fantasticdb (在 fantasticdb 目录下)
type Client struct { /* ... */ }

// 使用时
// import "github.com/mycompany/fantasticdb"
// client := fantasticdb.Client{}

正如附件中提到的，fantasticdb.Client 远比 FantasticDBClient 或 io.fantasticdb.client.Client 来得清爽和表意清晰（在 fantasticdb 这个包的上下文中，Client 自然就是指 fantasticdb 的客户端）。

为什么要“掰过来”？

可读性：简洁的包名和类型名让代码读起来更流畅，减少了视觉噪音。
上下文的力量：Go鼓励你信任包名提供的上下文。在 http 包里，Request 自然就是 HTTP 请求。
避免冗余：Go的哲学是“A little copying is better than a little dependency”，同样，一点点思考换来清晰的命名，好过冗余的限定词。

Gopher建议：

在Go中，给包和类型命名时，思考“在这个包的上下文中，这个名字是否清晰且没有歧义？”。如果你的包名叫 user，那么里面的类型可以直接叫 Profile，而不是 UserProfile。让包名本身成为最强的前缀。

习惯四：代码复用的“继承衣钵” -> 推崇“灵活组装”

Java的习惯：

Java是典型的面向对象语言，继承（Inheritance）是实现代码复用和多态的核心机制之一。”is-a” 关系（比如 Dog is an Animal）深入人心。开发者习惯于通过构建复杂的类继承树来共享行为和属性。

Go的转变：

Go虽然有类型嵌入（Type Embedding），可以模拟部分继承的效果，但其核心思想是组合优于继承 (Composition over Inheritance)。”has-a” 关系是主流。通过将小的、专注的组件（通常是struct或interface）组合起来，构建出更复杂的系统。

// Go - 组合示例
type Engine struct { /* ... */ }
func (e *Engine) Start() { /* ... */ }
func (e *Engine) Stop() { /* ... */ }

type Wheels struct { /* ... */ }
func (w *Wheels) Rotate() { /* ... */ }

type Car struct {
    engine Engine // Car has an Engine
    wheels Wheels // Car has Wheels
    // ...其他组件
}

func (c *Car) Drive() {
    c.engine.Start()
    c.wheels.Rotate()
    // ...
}

为什么要“掰过来”？