《Go 语言编程实战》目录

《Go 语言编程实战》目录

这一页是全书的总入口。它不只列出章节标题，还给出三条可以照着走的阅读路径，以及每一节的定位说明。如果你不确定从哪开始，先读下面的「读者画像与前置知识」，再对照「学习路径」选一条；如果你已经有明确目标，可以直接跳到「分部分章节」按编号定位。

全书结构是：目录 1 篇 + 正文 18 章 54 节，共 55 篇。正文按工程关注点分为五个部分，每一部分解决一类问题，并围绕一个贯穿全卷的服务 TaskHub 逐步长大。

这本书解决什么问题

卷一《Go 语言编程入门》的终点是「能独立交付一个服务」。这本书的起点，正好是那个终点之后的第一步。

一个能跑的服务和一个能长期维护的服务之间，隔着很多东西：模块怎么拆、依赖怎么管、配置和密钥怎么分层、多租户的数据怎么隔离、缓存和数据库怎么保持一致、消息丢了怎么办、线上出问题怎么定位、怎么发布怎么回滚。这些东西没有一样是语言特性，但每一样都能让一个团队的项目从「demo 很好」变成「运维很痛」。

本书的目标，就是把这中间的一段补齐。它假定你已经会写 Go，不再解释语法，而是回答「在生产环境里，这件事的正确做法是什么、为什么」。

如何使用本目录

这一页有三种用法，取决于你此刻的状态：

如果你刚拿到这本书，按顺序读「这本书解决什么问题」「读者画像与前置知识」「学习路径」三节，用五分钟决定自己的入口章节。不要跳过这一步——卷二的信息密度高于卷一，选错入口会读得很吃力。

如果你已经读到一半，想查某一节在哪，直接看「分部分章节」里对应部分的表格。每一行都有一句话说明，可以帮你确认是不是你要找的那一节。

如果你把这本书当手册用，主要会用到「常见问题速查」与每一节末尾的小结。工程问题往往是「知道去哪一节找」比「记住答案」更重要。

读者画像与前置知识

不同类型的读者，起点和建议路径差别很大。可以先在下面找到最接近自己的那一类。

已经读完卷一，或已有等价基础：这是本书的目标读者。你需要已经会用 net/http 写接口、用 database/sql 连数据库、用 context 做取消、用 log/slog 打日志、用 go test 写表驱动测试。如果不具备这些，建议先回卷一补上——本书不再重复。

有其他后端语言经验（Java/C#/Python/Node.js）：你的工程经验大多可以直接迁移，但有几处 Go 特有的地方需要留意。第一，Go 没有框架，中间件、依赖注入、路由都要自己组织（第 1、4、15 章）。第二，Go 的错误是返回值，工程上的错误分类与包装策略要重新设计（贯穿全卷）。第三，Go 的并发模型让「一个请求开一堆 goroutine」变得廉价，也因此让泄漏变得常见（第 9 章）。第 6、7、9 章对你信息密度最高。

在团队里负责 Go 项目但缺少体系：你可能已经踩过很多坑，知道「要加超时」「要用连接池」，但说不清参数该取多少、边界在哪。本书的价值在于把散落的经验整理成可决策的表格——第 6 章的超时预算、第 7 章的一致性策略、第 12 章的调优方法，都会给出「什么情况下选什么」的判据。

做基础设施或平台工程：第 14–16 章的容器化、Kubernetes、发布与运维，以及第 10 章的可观测性，可以直接跳读。但请先读第 1 章与第 3 章——模块边界和配置分层是后面所有章节的地基。

学习路径

下表给出三条典型路径。三条路径不互斥，可以先速成再补齐。

两条补充建议：无论选哪条路径，都请完整读第 1 章和第 3 章，把模块边界与配置分层定下来——这两件事改起来成本最高，一开始做对能省掉后面大量返工。如果时间允许，第 9 章的并发工程与第 11 章的测试策略值得反复读，它们决定了你的服务在压力下和在上线后是否可靠。

一份可执行的九周计划

上面三条路径偏原则。如果你希望有一份可以直接照着打勾的安排，下面这份九周计划可以作为起点（按每天投入一小时估算），它对应的是「完整通读」路径。

这份计划的关键不在于准时，而在于每周都有产出。工程能力的增长来自「把东西真的接起来跑通」，而不是读完章节。如果某一周的任务没有完成，宁可延长这一周，也不要为了赶进度跳过动手环节。

每周结束时，可以用三个问题自查：这一周引入的东西，我能在监控里看到它的行为吗？如果它挂了，我知道怎么发现、怎么回滚吗？如果现在合上书，我能向同事讲清楚这一周最核心的那个取舍吗？三个问题里只要有一个答不上来，就值得回头补一补再往下走。

如果你的时间只有一半，可以把第 13 章与第 17 章压缩——对象存储与合规审计更接近「按需查阅」的内容，等到项目里真的用上再回来补即可。

三条路径之外的三条提醒

无论选哪条路径，有三条提醒能显著影响你的阅读体验：

不要只读不跑。 本书的示例涉及数据库、Redis、容器等真实依赖，正文里给出的输出都是本机实跑的结果。请务必自己把依赖起起来——只看代码不跑，你收获的会是「我好像懂了」的错觉。

不要跳过第 1 章的模块划分。 后面每一章都假定你已经有了清晰的模块边界。地基不稳，后面每一步都会变得别扭。

不要为了「更工程」而过度设计。 本书会介绍很多模式，但没有一个是必须用的。第 18 章会专门讲怎么在复盘时砍掉不必要的复杂度。

五个部分之间的依赖关系

五个部分不是平行关系，而是层层依赖的。下面这张表说明每一部分依赖什么、又被谁依赖，方便你判断能否跳过某一部分：

一个实用的判断原则是：第一部分（工程基座）与第四部分（可观测与质量）是绕不过去的，前者决定代码怎么组织，后者决定出问题时你能不能看见。如果你的方向是后端业务开发，第二部分（API 与安全）与第三部分（性能与可靠性）优先级最高；如果你主要做平台与基础设施，第五部分的第 14–16 章更急，第 13 章可以往后放。

与既有 Go 专题的分工

本站的 Go 专题已经积累了 300 多篇文章，覆盖了 Go 的各个单点主题：内存模型、GMP 调度、sync 原语的取舍、性能剖析、常用库选型等等。它们质量不低，但有一个共同的特点：每一篇都假设你已经会 Go，然后带你在某个单点上钻深。

这本书与它们的分工，靠的是系统语境。卷二的每一节都以 TaskHub 这个多租户协作平台的具体模块为主线：你不会看到「Redis 有哪几种数据结构」这种脱离上下文的罗列，而会看到「任务列表的缓存该用什么结构、为什么、失效策略怎么定」。也就是说，本书负责把工程能力按顺序接起来，专题负责就一个问题钻到底，两者是互补关系。

需要特别说明的是与卷三、卷四的边界：本书第 9 章只写到「会用 errgroup 做结构化并发、会用 goleak 抓泄漏」为止；runtime/metrics 的底层语义、GC 调优的参数推导、编译器与运行时的实现细节一律不写，留给高级卷与原理卷。第 12 章的性能工程同样只到「用数据定位瓶颈」为止，不深入运行时内部。

版本与示例约定

为了让全书保持一致的预期，这里先交代版本与示例的约定，后面每一节都默认你已经知道这些口径：

• 本书主线是 Go 1.27，对照线是 Go 1.26。书中代码在本机 go1.27.0 工具链上实测，官方同期最新稳定版是 go1.27.2；同一条版本线内的补丁差异不影响本书结论。
• 多版本共存用 GOTOOLCHAIN。本机默认工具链较旧，但可以通过 GOTOOLCHAIN=go1.27.0 go version 切换到指定工具链。
• 与卷一不同，卷二大量使用第三方库。golang.org/x/sync、go-redis/v9、pgx/v5、testify、goleak、OTel、Testcontainers 等都会出现。引入的每一个库，正文都会说明「为什么不用标准库」。
• 拉依赖走 GOPROXY=https://goproxy.cn,direct。本机 proxy.golang.org 不可达，这一点在 2.2 升级、replace 与私有模块 里会展开。
• 代码块都标语言：go 表示 Go 代码，bash 表示命令行，text 表示真实输出或报错原文，yaml / json / sql / dockerfile 分别对应配置与脚本。
• 输出与代码分离：Go 代码块之后，紧跟着的 text 代码块是这段代码在本机跑出的真实输出，不是示意。
• 没跑过的会明说。本书涉及 Kubernetes、CI/CD、云服务等本机无法完整复现的环境，凡未实测的片段都会在正文里明确标注并说明原因。读者宁愿看到诚实的边界，也不要看到编造的输出。

分部分章节

下面按五个部分列出全部 18 章 54 节，每一行给出编号、标题与一句话说明。

表格里的编号规则是「章.节」，例如 7.2 表示第 7 章第 2 节。点击标题即可进入该节正文。每个部分开头都有一段导读，说明这一部分在工程链条中的位置；如果你只想知道某节讲什么，直接看表格第三列的说明即可。

需要提醒的是，正文的每一节都遵循「本节目标 → 正文小节 → 小结 → 衔接下一节 → 阅读导航」的五段式结构，所以即使你从中间某节切入，也能通过开头的目标说明快速建立上下文，不必担心前情缺失。

第一部分：工程基座（第 1–3 章）

这一部分解决「代码怎么组织、依赖怎么管、配置怎么分层」三个前置问题。它们看起来与业务无关，却决定了后面每一章的写法是否别扭。

节奏上，这一部分刻意放慢了。第 1 章讲模块边界，是全书最容易返工的地方；第 2 章讲版本治理与供应链安全，涉及 govulncheck 与 SBOM；第 3 章把配置与密钥分开处理，并引入热更新与启动期校验。

第二部分：API 与安全（第 4–6 章）

这一部分是全书的核心。它回答「一个多租户服务的对外契约怎么定、访问怎么控、数据怎么取」。三章之间是递进关系：先定接口长什么样，再定谁能访问，最后定数据怎么落地。

第三部分：性能与可靠性（第 7–9 章）

这一部分让服务在高并发和部分依赖故障时仍然可用：缓存挡住读压力，消息削掉写峰值，并发工程控制资源上限。它回答的是「流量涨上来、依赖挂掉时，服务还能不能撑住」。

第四部分：可观测与质量（第 10–12 章）

这一部分回答「服务上线之后，你怎么知道它好不好」。三章分别对应「看得见」（日志、指标、链路）、「测得准」（分层测试）、「调得动」（性能工程）。没有这一部分，前面所有的工程手段都缺少反馈回路。

第五部分：交付与运维（第 13–18 章）

最后一部分把服务交付出去并长期运维：对象存储、容器化、Kubernetes 部署、发布流程、安全加固，最后用一个综合章把全书串起来。它回答的是「代码写完之后，怎么保证它跑得稳、上得了线、出问题能回得来」。

常见问题速查

下面是读者最常问的几个「该读哪一节」的问题，直接给答案：

如果你遇到的问题不在表里，可以先用目录里的关键词搜索定位章节，再结合每节的「本节目标」判断是否命中。

读完本书之后

读完全书并不意味着结束。工程能力是一门需要在项目里持续打磨的手艺，真正让知识固化的，是你把它用在自己的系统上。给几条后续建议：

• 找一个真实系统做一遍复盘。对照 18.1 架构复盘与容量规划 的清单，把你自己项目的取舍重新过一遍，往往能发现几处「当初随手写的、现在没人敢改」的地方。
• 把可观测性补齐。很多团队的问题不是性能不够，而是看不见。第 10 章的三件事——日志带关联 ID、指标覆盖黄金信号、链路串起跨服务调用——投入产出比极高。
• 建立故障演练的习惯。18.2 故障演练 里介绍的做法可以定期做一次，把「假设它能扛住」变成「验证过它能扛住」。
• 保持对「过度设计」的警惕。本书介绍了很多模式，但没有一个是必须用的。能力越强，越容易写出没人敢动的抽象；可维护优先于巧妙，这条原则在任何规模的项目里都成立。

如果你还想在某个单点上深挖，本站的 Go 专题文章是很好的补充——例如调度与内存模型、并发原语的取舍、性能剖析等方向。它们与本书是互补关系：本书负责把工程能力接成体系，专题负责就一个问题钻到底。

小结

这一页的核心信息可以浓缩成三句话：

• 结构上，全书是「目录 1 篇 + 五部分 18 章 54 节」，共 55 篇，围绕 TaskHub 一个多租户协作平台逐章推进。
• 路径上，读完卷一者按顺序通读，急于上线者集中读 9 节速成清单，已上线者按「常见问题速查」查阅。
• 方法上，每一节都遵循「本节目标 → 正文 → 小结 → 衔接 → 阅读导航」的五段式，任何一节都可以独立阅读。

如果你已经选好了路径，可以直接从对应的章节开始。每一节的末尾都会指向下一节，跟着走不会迷路。

祝你读得顺利。

最后再重复一句：本页不需要从头读到尾。它的作用是「在你需要的时候，三秒钟内把你送到正确的那一节」。把这一页加进书签，比记住任何章节编号都有用。