很多人第一次被问到「说一下什么是分布式系统」时，脑子里蹦出来的是一堆名词：集群、微服务、CAP、一致性哈希、Raft。名词都听过，但要连着讲三分钟，讲成一个有逻辑的答案，就卡住了。这门课就是冲着这个卡点来的——它不铺开讲整套分布式理论，而是围绕一道高频面试题，把 Golang 视角下该说清楚的东西说清楚。

先看清自己的缺口在哪

分布式这个概念，难的地方不在于定义，而在于它是一堆问题的集合。你把十个人叫来问「什么是分布式」，可能得到十种回答：有人从部署形态讲，有人从一致性问题讲，有人从服务拆分讲。面试官想听的其实是你能不能把这些线索收拢成一条主线。

常见的缺口大致有三类。一是只会背定义，讲不出「为什么要分布式」，说不出单机到底撞到了哪堵墙。二是知道 CAP、Base 这些词，但被追问「你项目里怎么取舍的」就答不上来。三是完全不提 Golang——而这门课偏偏是 Golang 方向的，goroutine 调度、channel 通信、net/rpc 这些语言层面的东西，恰恰是把分布式概念落到实处的抓手。

如果你属于上面任意一种，这门课值得花时间。如果你已经能自己画出分布式系统的分层图，并且讲得清每层在解决什么问题，那这五课时的密度对你来说可能偏低。

这门课怎么讲「分布式」

它走的是问题驱动的路子：从面试官那句「说一下什么是分布式系统」出发，往回倒推需要准备哪些内容。所以你会看到概念不是孤立摆出来的，而是挂在一个个会被追问的点上——单体到分布式的演进动因、节点之间如何通信与协调、数据一致性和可用性之间怎么权衡、故障为什么是常态而不是意外。

Golang 在这里不是装饰。讲通信会落到具体的并发模型上，讲服务协作会牵扯到 RPC 层面的实现思路。对 Golang 学习者来说，这比纯理论讲述更容易记住，因为你能把抽象概念对应到写过的代码结构上。

看完应该能回答的问题

用两三分钟讲清「什么是分布式系统」，并且让面试官愿意继续追问，而不是听完就换话题。
单体应用在什么条件下必须走向分布式，这个转折点的判断依据是什么。
CAP 在实际系统里不是三选二这么简单，具体到某个业务场景，你的取舍理由是什么。
Golang 的并发原语在分布式场景里解决了哪一类问题，又留下了哪一类问题没解决。
被问到「你做过分布式吗」时，怎么把手上的项目讲出分布式味道，而不是硬编。

配套练习建议

五课时的内容偏紧凑，光看容易产生「我都懂了」的错觉。建议每看完一节做一件事：合上材料，用手机录音把这一节的核心问题讲一遍，控制在两分钟内。回放的时候你会发现，卡壳的地方就是没真懂的地方。

另外，找一个自己写过的 Golang 项目，试着回答「如果它的用户量涨十倍，哪里会先撑不住」。不需要真的去改造，能把瓶颈点和可能的分布式解法讲出来，这门课的目的就达到了。面试里的分布式问题，考的从来不是你会不会背，而是你能不能把概念和具体系统连起来。