本文永久链接 – https://tonybai.com/2025/07/04/everything-i-did-to-become-an-expert-in-golang

大家好，我是Tony Bai。

你是否也有过这样的时刻？

你已经用 Go 写了不少代码，项目也能跑起来，但内心深处总有一种挥之不去的“别扭感”。你写的 Go 代码，看起来更像是“带有 Go 语法的 Java/Python”，充斥着你从旧语言带来的思维习惯。代码或许能工作，但它不优雅，不简洁，总感觉“不对劲”。

最近，Twitch 的一位资深机器学习工程师 Melkey 分享了他从 Go 小白成长为生产级系统开发者的心路历程。他的故事，完美地诠释了如何突破这个瓶颈，完成从“会写”到“写好”Go 的关键一跃。

在这篇文章中，我们就来解读一下这位工程师的Go专家之路，看看从中可以借鉴到哪些有意义的方法。

从“被迫营业”到“感觉不对”的困境

和许多人一样，Melkey 开始学习 Go 并非出于热爱，而是因为工作的“逼迫”。2021年，当他以初级工程师的身份加入 Twitch 时，他还是一个习惯于用 Python 写脚本的“简单小子”，对 Go 一无所知。为了保住这份改变人生的工作，他别无选择，只能硬着头皮学下去。

很快，他熟悉了指针、静态类型和 Go 的基本语法。但问题也随之而来：他感觉自己的 Go 水平停滞不前，写出的代码“干巴巴的”，缺乏神韵。 他只是在完成任务，却丝毫没有感受到这门语言的魅力，更谈不上建立起真正的理解和喜爱。

这正是许多 Gopher，尤其是从其他语言转来的开发者，都会遇到的困境：我们只是在用 Go 的语法，实现其他语言的逻辑。 我们还没有真正进入 Go 的世界。

“顿悟”时刻：《Effective Go》带来的思维重塑

改变发生在 Melkey 偶然读到 Go 官方文档中的一篇文章——《Effective Go》 的那一刻。这篇文章里的几段话，像一道闪电，瞬间击穿了他的迷茫：

“A straightforward translation of a C++ or Java program into Go is unlikely to produce a satisfactory result—Java programs are written in Java, not Go.

In other words, to write Go well, it’s important to understand its properties and idioms. It’s also important to know the established conventions for programming in Go… so that programs you write will be easy for other Go programmers to understand.”

这段话的核心思想振聋发聩：将 C++ 或 Java 程序直接翻译成 Go，不可能得到令人满意的结果。要想写好 Go，就必须理解它的特性和惯用法。

Melkey 恍然大悟：他之前所做的，正是这种“直接翻译”的笨拙工作。他缺少的，是一次彻底的“思维重塑”——停止用过去的经验来套用 Go，而是开始真正地用 Go 的思维方式去思考问题。

什么是“Go 的思维方式”？

那么，这种听起来有些玄乎的“Go 思维”究竟是什么？它不是什么神秘的魔法，而是植根于 Go 语言设计中的一系列核心哲学：

1. 崇尚简洁与可读性

Go 厌恶“魔法”。它倾向于用清晰、直白、甚至略显“笨拙”的代码，来换取长期的可读性和可维护性。相比于某些语言中炫技式的语法糖和复杂的隐式行为，Go 鼓励你把事情的来龙去脉写得一清二楚。

2. 组合优于继承

Go 没有类和继承。它通过接口（interface）实现多态，通过结构体嵌入（struct embedding）实现组合。这种方式鼓励开发者构建小而专注的组件，然后像搭乐高一样将它们组合起来，而不是构建庞大而僵硬的继承树。

3. 显式错误处理

if err != nil 是 Go 中最常见也最富争议的代码。但它恰恰体现了 Go 的哲学：错误是程序中正常且重要的一部分，必须被显式地处理，而不是通过 try-catch 这样的语法结构被隐藏起来。它强迫你直面每一个可能出错的地方。

4. 并发是语言的一等公民

Goroutine 和 Channel 不仅仅是两个原生语法元素，它们是一种构建程序的新范式。正如 Rob Pike 所言，“并发不是并行”。Go 鼓励你从设计的源头，就把程序看作是一组通过通信来协作的、独立的并发单元，而不是在写完一堆顺序代码后，再思考如何用线程池去“并行化”它。

从理论到实践：用项目和资源内化新思维

当然，仅仅理解了这些哲学还远远不够。Melkey 强调，在读完所有文档后，他意识到“阅读所能做的就这么多了”，必须将新学到的思想付诸实践。

理论的顿悟，必须通过刻意的项目练习来巩固和内化。下面，就是他亲身走过的、从入门到精通的“四步实战路径”，以及在这条路上为他保驾护航的“精选资源清单”。

一条清晰的实战路径：用四类项目锤炼 Go 思维

• 第一站：HTTP 服务 (从简单到复杂)

这是 Go 最核心的应用场景，也是梦开始的地方。从最基础的 CRUD、健康检查 API 入手，逐步深入到 OAuth 认证、自定义中间件、利用 context 包进行请求范围内的值传递等。这个过程能让你全面掌握构建生产级 Web 后端所需的各项技能。

• 第二站：CLI 工具

许多优秀的 Go 开源项目，如 Docker、Kubectl，都是强大的 CLI 工具。通过使用 Cobra、Bubble T 等流行库，去构建自己的命令行应用，你会深刻理解 Go 作为“云原生时代的 C 语言”的工具属性，并学会如何优雅地处理命令行参数、标志和应用状态。

• 第三站：gRPC 服务

当你感觉 HTTP 服务已驾轻就熟时，就该迈向微服务了。学习 gRPC 和 Protocol Buffers，构建服务间的通信。这将迫使你的思维从处理“用户-服务器”交互，转变为处理“服务-服务”间的交互，是成为分布式系统架构师的关键一步。

• 第四站：管道作业与脚本

真正的精通，是把一门语言用成“肌肉记忆”。尝试用 Go 替代你过去的脚本语言（如 Python），去编写一些数据处理的管道作业或日常运维脚本，比如批量清洗数据库中的脏数据。这会极大提升你对 Go 标准库的熟练度，让它成为你工具箱里最顺手的那一把。

注：Melkey是机器学习工程师，因为他的第四站中，更多是数据处理相关的实战路径。

良师益友：来自一线的精选资源清单

在这条充满挑战的实践之路上，你不是一个人在战斗。Melkey 也分享了那些曾给予他巨大帮助的“良师益友”。这份清单的宝贵之处在于，它经过了生产一线工程师的真实筛选：

• Web 后端实战圣经：《Let’s Go Further》 by Alex Edwards

这本书被誉为 Go Web 开发的经典之作。即便时隔数年，其中的原则和实践依然极具价值。我也极力推荐这本书，Alex 的代码风格非常清晰，对初学者极其友好，能帮你打下坚实的基础。

• 测试驱动开发双璧：《Learn Go with Tests》 & 《Writing an Interpreter in Go》

前者是优秀的在线教程，手把手教你如何通过测试来学习 Go。后者则通过编写一个解释器的过程，让你在实践中深刻理解测试驱动开发（TDD）的精髓。它们不仅教测试，更在教 Go 语言本身。

• 避坑与最佳实践指南：《100 Go Mistakes and How to Avoid Them》

这是一本能让你快速提升代码质量的“速查手册”。通过学习别人踩过的坑，你可以少走很多弯路，写出更地道、更健壮的 Go 代码。

小结：真正的精通，是一场思维的迁徙

Melkey 的故事告诉我们，精通一门编程语言，从来都不只是学习语法和 API 那么简单。它更像是一场思维的迁徙——你必须愿意放下过去的地图，学习新大陆的规则和文化，并最终成为这片土地上地道的“原住民”。

如果你也感觉自己写的 Go 代码“不对劲”，不妨停下来，问问自己：我是在用 Go 的方式思考，还是在用过去的经验翻译？

或许，你的“顿悟”时刻，也正隐藏在重读一遍《Effective Go》的字里行间，或是开启下一个实战项目的决心之中。

你是否也有过类似的“顿悟”时刻？又是哪篇文章、哪个项目或哪位导师，帮助你完成了 Go 思维的重塑？欢迎在评论区分享你的故事。

资料地址：https://www.youtube.com/watch?v=wr8gJMj3ODw

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

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

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

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

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

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

本文永久链接 – 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)”。

1. 分治 (Divide-and-Conquer)： 将大问题分解成若干个独立的、可以并行处理的子问题。每个子问题独立求解后，再将结果合并。这天然地契合了并行的思想。

2. 结合性 (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调度(数量大于机器核数)与递归的开销拖慢了执行的速度。

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

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

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

1. 任务分解与合并开销： 将问题分解、分发给 Goroutine、以及最后合并结果都需要时间。
2. Goroutine 创建与调度开销： 虽然 Go 的 Goroutine 很轻量，但创建和调度百万个 Goroutine 仍然有不可忽视的开销。这就是为什么在 sumRecursiveParallel 中我们设置了一个 threshold，当问题规模小于阈值时，退化为顺序执行。
3. 通信开销： Channel 通信比直接的函数调用要慢。
4. 同步开销： 如果子问题间不是完全独立，或者合并过程复杂，可能需要额外的同步（如 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 的思想，鼓励我们从更本质的层面思考问题：

1. 关注“是什么 (What)”而非“怎么做 (How)”： 就像数学家写 Σxᵢ 一样，先声明意图（求和），而不是一开始就陷入具体的循环和累加步骤。Fortran 90 的 SUM(X) 就是这种思想的体现。
2. 寻找结合性的合并操作： 对于一个问题，思考能否将其分解，并找到一个满足结合律的合并方法。这往往需要对问题域有更深的理解。Steele 在 PPT 中展示了如何通过定义 WordState 及其结合性的 ⊕ 操作来并行化“字符串分词”问题，非常精彩。
3. 拥抱不可变性与纯函数： 尽可能使子问题的处理函数是纯函数（无副作用，相同输入总有相同输出），这能极大地简化并行程序的推理。
4. 可复现性至关重要： 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技能再上一个新台阶！

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