标签 Golang 下的文章

我的 Gopher “长期主义”:从《Go语言第一课》新书说起

本文永久链接 – https://tonybai.com/2025/08/28/go-primer-published

大家好,我是Tony Bai。

前不久,在知乎上看到一个关于 Go 社区的帖子,其中一条评论让我感慨良多:

“GopherChina 都没了,国内还有几人坚持?Tony Bai好像还在更新”

短短一句话,道尽了社区的变迁与坚持的不易。这句来自读者的回答,让我内心欣慰,也让我有机会停下来,审视自己在这条路上走了多远,以及为什么还要继续走下去。

答案或许很简单,就是三个字:长期主义

我的个人博客 tonybai.com,从 2004 年断断续续更新至今,已经走过了二十个年头。而我在 Go 语言这条路上的“长期主义”,则始于 2011 年。那时,Go 尚处襁褓,在国内几乎无人问津。我凭借着一股直觉和热爱,一头扎了进去,成为了国内最早一批的 Go 语言探索者。

十余年来,这份坚持从未间断。从早期的博客分享,到后来出版的《Go语言精进之路》;从 GopherChina 大会的讲台,到几乎每日更新的 GopherDaily,我一直在尽我所能地为社区贡献。

这份坚持也延续到了今年。从年初开始,我在公众号上陆续推出了多个“微专栏”系列,深入探讨 Go 源码与实践的细节;与此同时,我的新课程Go语言进阶课也已在极客时间上线,希望能带领大家向更深层次迈进。

布道,其实是一件极具价值的事情——传递自己的观点,影响一群人,做成一件事。

今天,我的这份“长期主义”清单上,又将增添新的一项。我想借此机会,向一直支持我的朋友们,正式宣布一个喜讯。

官宣喜讯:历时一年半,2.4w 人订阅的《Go语言第一课》成书!

四年前,我在极客时间开设了专栏《Go语言第一课》。令我欣慰的是,这个专栏得到了广大 Gopher 的认可和喜爱。截至今日,它已经影响了超过 2.4 万名订阅者(截至2025.8),在编程语言类专栏里取得了相当不错的成绩。

为了让这份经过市场检验的优质内容,能以一种更经典、更触手可及的方式,帮助更多人踏入 Go 语言的大门,我与人民邮电出版社异步图书合作,历时一年多的精心打磨,终于将它变成了纸质书 — 我的第二本“小黄书”:

我必须强调,这本书并非专栏的简单复制。在近一年多的时间里,我倾注了大量心血,进行了一次彻底的精修与增补:

  • 内容与时俱进:全书内容与最新的 Go 1.24 版本 同步(注:交稿时的最新版本为Go 1.24),确保知识的前沿性与准确性。
  • 知识体系更完整:我特别补充和深化了专栏中因篇幅所限未能详尽展开的关键内容,如指针类型的深入探讨、测试的最佳实践、以及泛型的全面讲解,使其作为一本入门读物更加系统和完备。
  • 全面精炼与优化:基于三年来数万读者的宝贵反馈,我对全书的结构、文字表述、示例代码和图示进行了地毯式的优化,力求为读者提供“保姆级”的丝滑阅读体验。

为了让大家更直观地感受这本书是如何从“道”到“术”,构建一个完整而系统的知识体系的,我在这里分享本书的核心目录结构:


《Go语言第一课》核心目录概览

  • 第一部分:建立宏观认知 (打好地基)

    • 第1章 Go的那些事儿 (追本溯源,深入理解Go的诞生背景、演进历史与核心设计哲学:简单、显式、组合、并发、面向工程)
  • 第二部分:基础与工程化 (工欲善其事)

    • 第2章 建立Go开发环境
    • 第3章 第一个Go程序
    • 第4章 Go包、模块与代码组织结构
    • 第5章 Go的依赖管理 (从演化到Go module实战)
  • 第三部分:核心语法精讲 (深入肌理)

    • 第6章 变量与类型
    • 第7章 基本数据类型
    • 第8章 常量 (深入理解无类型常量等创新)
    • 第9章 复合数据类型 (数组、切片、map、结构体)
    • 第10章 指针类型 (新增与深化章节,彻底搞懂Go指针)
    • 第11章 控制结构
  • 第四部分:Go编程思想与范式 (提升境界)

    • 第12章 函数 (一等公民、defer的妙用与代价)
    • 第13章 错误处理 (Go独特的错误处理哲学与实践)
    • 第14章 方法 (深入理解Receiver的选择原则)
    • 第15章 接口类型 (小接口、组合思想与底层实现)
  • 第五部分:Go核心竞争力 (决胜未来)

    • 第16章 并发编程 (Goroutine、Channel与CSP并发模型)
    • 第17章 泛型 (与Go 1.24同步,从设计演化到语法实践)
    • 第18章 测试 (表驱动测试、示例测试、性能基准测试等最佳实践)

从这份目录中大家可以看到,本书的路径设计清晰:从建立对 Go 的整体认知和哲学认同开始,到掌握扎实的工程基础,再到深入语言的核心语法与编程范式,最终聚焦于并发、泛型和测试这三大核心竞争力。 这是一条为初学者量身打造的、平滑而陡峭的学习曲线,旨在帮助你不仅学会 Go,更能学好 Go。

当然这份精益求精的背后,离不开人民邮电出版社异步图书编辑老师们的辛勤付出。在长达一年的审校过程中,他们以极高的专业素养和一丝不苟的态度,对书稿的每一处细节进行推敲和打磨。从章节结构的优化,到遣词造句的斟酌,再到每一个标点符号的校对,都倾注了大量心血。

下面这张布满批注的审稿截图,只是责任编辑秦健老师无数次打磨与推敲的一个缩影。正是因为有了这样认真负责的合作伙伴,这本书才能以更好的面貌呈现给大家。在此,向编辑老师们致以我最诚挚的谢意!

简单来说,这本书凝结了我十余年的 Go 语言实战经验和布道心血,旨在为所有初学者提供一条清晰、高效的 Go 语言入门路径,不仅能快速上手,更能从一开始就建立起扎实的工程思维,为后续的进阶和实战打下坚实的基础。

灵魂拷问:AI 时代,我们为什么还需要一本入门书?

官宣完毕,我想和你探讨一个更深层次的问题。

在 ChatGPT、Claude、Gemini、DeepSeek、Copilot 等 AI 工具已经能“秒答”任何技术问题的今天,我们为什么还需要静下心来,系统地去阅读一本厚重的、入门级的纸质书?

这是一个极其现实的挑战。作为一名同样深度使用 AI 的工程师,我的答案是:越是在这个时代,我们越需要一本好的入门书。

1. AI 提供“答案”,书籍构建“体系”

AI 的强大之处,在于它能针对你提出的具体问题,迅速给出一个看起来可行的“答案”(代码片段)。它能高效地帮你解决“术”层面的问题。

但一本好的入门书,为你构建的是一张捕鱼的“”——一个结构化、系统化的知识体系。它从语言的“前世今生”与设计哲学讲起,为你建立宏观认知;然后层层递进,系统讲解语法、并发、泛型等核心知识点。

没有体系的知识是脆弱的、零散的。你或许能用 AI 拼凑出一个能运行的程序,但在面对复杂、未知的问题时,你将因为缺乏坚实的知识框架而寸步难行。而这本书,正是为你打造这张网。

2. 对抗“能力空心化”,修炼真正的“内功”

我在之前的文章中反复提及一个概念——警惕 AI 带来的“能力空心化”。过度依赖 AI,会让初级工程师陷入“知其然,而不知其所以然”的困境

系统地学习一本入门书,恰恰是修炼“内功”的最佳方式。它强迫你去理解每一行代码背后的设计哲学、核心原理、以及那些微妙的权衡取舍

  • 为什么 Go 的错误处理是这样的?
  • interface{} 的底层实现是怎样的?
  • CSP 并发模型的核心思想是什么?

这些问题的答案,无法通过简单的 Prompt 获得。它们需要你沉下心来,跟随作者的思路,一步一个脚印地去理解和内化。这个过程,正是在构建你作为一名工程师,那份不可被 AI 替代的核心竞争力。

3. 纸质书,一种无可替代的沉浸式学习体验

最后,让我们回归阅读本身。

在信息过载的今天,纸质书提供了一种稀缺的、主动的、专注的、沉浸式的学习体验。它能帮助我们暂时摆脱屏幕上无尽的通知和干扰,让大脑进入一种更深度的思考状态。你可以随时在书页上圈点、批注,与作者进行一场跨越时空的对话。这种物理的交互感和知识的“拥有感”,是任何数字媒介都无法比拟的。

布道者的心声:传递观点,影响他人

回首这十几年的 Go 之旅,我愈发觉得,布道本身就是一件极具价值的事情。它不仅仅是分享知识,更是传递一种观点,影响一群人,最终一起做成一件事情。

我写博著书和开设专栏的初衷,也正是如此。我希望传递的,不仅仅是 Go 语言的“术”——那些语法和技巧;更是 Go 语言的“道”——那种“简单、显式、组合、并发、面向工程”的编程哲学与乐趣。

在此,我要特别感谢极客时间平台,感谢人民邮电出版社异步图书的专业与付出,但最想感谢的,是四年来那 2.4w+ 的专栏订阅者,以及所有在我的博客、公众号、社区中与我交流、给我反馈的每一位读者。是你们的支持,才让这份“长期主义”有了最坚实的意义。

行动号召:即刻拥有你的《Go语言第一课》

现在,这本凝结了无数心血的《Go语言第一课》纸质版,已正式上市!

在本书的定价阶段,我和出版社的编辑老师们有一个共同的坚持:希望能让更多的 Go 语言爱好者,能够以更低的门槛,轻松地获取这份系统化的知识。为此,我们将这本书的定价一再压缩,最终定在了 79.8 元

而为了感谢大家一直以来的支持与耐心等待,我们特别为大家申请了首发专属福利。在活动期间,大家可以通过下方的专属链接,以【五折优惠】的价格——算下来仅需不到 40 元——将这本300多页的硬核知识带回家。

这可能是本书在未来很长一段时间内的最低价格,希望能让每一位真正热爱 Go 语言的朋友,都能无压力地拥有它。

扫描下方二维码或点击这里, 即享五折优惠,即刻开启你的Go语言高效学习之旅!

请注意,此五折优惠二维码仅在新书首发冲量期间有效,机会难得,不要错过!

为了更好地服务本书读者,我也为本书创建了专属的 GitHub 仓库,用于持续发布勘误信息和提供完整的配套示例代码。追求高质量,是我们共同的目标。

  • 勘误与代码支持:https://github.com/bigwhite/goprimer

期待在书的扉页里,与你相遇。


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

Go语言的“灵魂拷问”:接口只关乎行为,还是也应拥抱数据?

本文永久链接 – https://tonybai.com/2025/08/27/go-interface-embrace-data

大家好,我是Tony Bai。

在 Go 语言的世界里,接口(interface)一直被视为其设计哲学的基石之一——它只关心一个类型能做什么(行为),而不关心它是什么(结构)。这种基于方法集的鸭子类型,赋予了 Go 独一无二的灵活性和解耦能力。然而,随着 Go 1.18 泛型的到来,一个深刻的问题被摆上了台面:当我们需要编写对数据的结构而非行为具有通用性的代码时,现有的约束机制是否足够?

GitHub 上的 Issue #51259“proposal: spec: support for struct members in interface/constraint syntax”,正是这场“灵魂拷问”的中心。它提出的一个看似简单的想法——让接口能够描述结构体字段——却引发了一场关于 Go 语言核心哲学的深度辩论:我们是应该坚守“行为至上”的纯粹性,还是应该拥抱一个更务实的、能感知数据结构的泛型系统?

在这篇文章中,我就和大家一起来看看Go社区和Go团队关注这个提案的讨论过程,以及基于当前现状的临时决议。

问题的根源:当泛型遇到结构

想象一下这个常见的场景:你需要编写一个通用的函数,来处理一组具有共同字段的结构体,比如各种类型的 Kubernetes 资源,它们都内嵌了 metav1.ObjectMeta 和 metav1.TypeMeta。或者,在图形学应用中,你需要处理多种都包含 X、Y 字段的 Point 结构。

在 Go 1.18 之后,我们很自然地会想到使用类型联合(union)来约束泛型函数:

type Point2D struct { X, Y float64 }
type Point3D struct { X, Y, Z float64 }

// 期望的写法
func Distance[T Point2D | Point3D](p T) float64 {
   // 编译失败!
   // p.X undefined (type T has no field or method X)
   return math.Sqrt(p.X*p.X + p.Y*p.Y)
}

然而,编译器无情地拒绝了我们。原因在于,Go 的泛型约束规定,对类型参数的操作,必须是其类型集合中所有类型都明确支持的。对于一个类型联合,其“共同能力”仅限于所有成员都实现的方法集,而不包括共同的字段

为了绕过这个限制,目前唯一的办法是回归到 Go 的传统强项:行为接口。开发者被迫为每个结构体编写琐碎的 getter/setter 方法,仅仅是为了让它们满足同一个行为接口,从而能在泛型函数中使用,但这恰恰是“样板代码”的来源:

import "math"

// 原始结构体
type Point2D struct{ X, Y float64 }
type Point3D struct{ X, Y, Z float64 }

// 1. 定义一个行为接口来描述“获取坐标”的行为
type Point interface {
    X() float64
    Y() float64
}

// 2. 为每个结构体实现接口(这部分就是样板代码)
func (p Point2D) X() float64 { return p.X }
func (p Point2D) Y() float64 { return p.Y }

func (p Point3D) X() float64 { return p.X }
func (p Point3D) Y() float64 { return p.Y }

// 3. 现在,泛型函数可以基于行为接口工作了
func Distance[T Point](p T) float64 {
    // 通过方法调用,而非字段访问
    return math.Sqrt(p.X()*p.X() + p.Y()*p.Y())
}

上面的代码现在可以编译通过了,但代价是什么?我们被迫编写了四个极其琐碎的、仅仅是 return p.FieldName 的 getter 方法。这些方法没有增加任何新的业务逻辑,它们存在的唯一目的,就是为了满足类型系统的约束。如果还需要修改字段,我们还得再为每个结构体编写 SetX、SetY 等 setter 方法。

当需要约束的字段增多,或者涉及的结构体类型增加时,这种样板代码会呈爆炸式增长。这正是这场“灵魂拷问”的开端:为了形式上的“行为”,我们是否牺牲了实质上的简洁与直观?我们是否应该有一种更直接的方式,来表达对结构的约束?

提案的核心:让接口描述“数据契约”

为了摆脱这种繁琐的 “getter 样板代码” 困境,提案者提出了一个大胆而直观的想法:将对结构的要求,直接提升为接口的一部分,让接口能够描述一种“数据契约”。

// 提案中的核心语法
type TwoDimensional interface {
    X, Y int
}

// 泛型函数现在可以直接访问由约束保证存在的字段
func TwoDimensionOperation[T TwoDimensional](value T) int {
  return value.X * value.Y // 合法!
}

type Point2D struct{ X, Y int }
type Point3D struct{ X, Y, Z int }

var p2 Point2D
var p3 Point3D
TwoDimensionOperation(p2) // 编译通过
TwoDimensionOperation(p3) // 编译通过

这个提议的精妙之处在于,它并没有发明一个全新的概念,而是将我们之前被迫用 行为 (getter 方法) 模拟的 结构 约束,变成了一种一等公民。它精准地回答了一个问题:如果我们只是想要访问一个字段,为什么必须强制类型去实现一个方法呢?为什么不能直接在约束中声明我们对“数据契约”的要求?

一位参与讨论的 Gopher 对此给出了一个绝佳的类比,清晰地阐述了这种思想上的转变:

“In the same way that type XGetter interface { GetX() int } represents the set of types that implement the method GetX() int, Xer would be the set of types that have a member X.”
(就像 XGetter 接口代表了所有实现了 GetX() int 方法的类型集合一样,Xer 接口将代表所有拥有字段 X 的类型集合。)

这种转变不仅是语法的简化,更是思维模式的飞跃。它允许我们从“要求一个 GetX() 的行为”,转变为更直接的“要求一个 X 字段的存在”。这不仅解决了样板代码的问题,还带来了潜在的性能优势:编译器可以直接生成字段访问指令,而无需像方法调用那样进行动态派发(dynamic dispatch)。

激烈的辩论:行为 vs. 结构

这个提案立即引发了社区的深度讨论,核心的争议点在于它是否动摇了 Go 接口的哲学根基。

反对的声音:“接口应该只关乎行为”

一些Go社区成员的观点认为,这是对 Go 接口核心理念的背离:

“It seems to shift the emphasis of interfaces from behavior to data… a mechanism for focusing on what a type can do, rather that what a type is composed of.”
(这似乎将接口的重点从行为转移到了数据……接口是一个专注于类型能做什么,而非由什么组成的机制。)

这种观点认为,字段是数据(data)结构(structure),而方法是行为(behavior)。一旦接口开始描述数据,Go 就可能失去其设计上的纯粹性,向更复杂的、基于结构继承的语言靠拢。

支持的声音:“字段也是一种操作” & “泛型改变了游戏规则”

另一方则认为,这种“行为 vs. 结构”的二元对立在泛型时代已经过时。Go 核心团队的 ianlancetaylor 提供了一个全新的视角:

“If you view field access as an operation on a type, in the same sense that + is an operation on a type, then it does make sense.”
(如果你将字段访问视为一种类型上的操作,就像 + 是一种操作一样,那么这就说得通了。)

泛型约束 interface{ int | float64 } 允许在函数内使用 + 操作符,正是因为它约束了类型集内的所有类型都支持 + 这个“行为”。同理,interface{ X int } 也可以被理解为约束了所有类型都支持 .X 这个“操作”。

此外,支持者认为,Go 1.18 引入的类型联合本身,就已经让接口开始描述“是什么”(具体的类型集合),而不仅仅是“能做什么”了。因此,允许接口描述结构,只是这一演进方向上合乎逻辑的下一步。

深层挑战:可写性、嵌入与接口值

除了哲学辩论,讨论还深入到了一些棘手的技术细节:

  • 字段的可写性(Addressability): 如果一个泛型函数可以修改字段 (point.X = 1.0),当传入一个非指针的结构体值时,修改应该只发生在函数内部的副本上。但如果传入的是一个接口值,其底层动态值的可写性如何保证?这引出了关于“可写字段”约束的复杂讨论,例如用 *Y int 语法来表示可写字段。

  • 嵌入字段(Embedded Fields): 如何在接口中表达一个类型必须“嵌入”另一个类型,而不仅仅是拥有其所有字段?这涉及到类型布局和方法提升等更深层次的语义,目前尚无完美的解决方案。

  • 接口值化: ianlancetaylor 明确指出,任何被接受的约束提案,都应该有潜力在未来演进为可被实例化的普通接口类型。一个只能作为约束存在的“半成品”接口,会给语言增加不必要的复杂性。

结论:一个被搁置但远未结束的探索

最终,由于其巨大的复杂性和对语言核心概念的深远影响,Go 团队决定将此提案搁置(On Hold),以便在社区对 Go 1.18 泛型有了更充分的实践和理解后再做定夺。

然而,这场辩论的价值远超提案本身。它强迫我们重新思考 Go 语言的核心概念在泛型时代下的新内涵。它揭示了在 Kubernetes API 操作、数据库 ORM、图形学库等真实世界场景中,对“结构化泛型”的迫切需求。

虽然我们短期内不会看到 interface{ X int } 这样的语法,但这场讨论已经播下了种子。它可能会在未来以某种形式回归,或许是更完善的接口语法。Issue #51259 的开放状态,本身就代表着一种承诺:关于 Go 语言灵魂的探索,远未结束。


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

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

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

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

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


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats