Goroutine、Channel、Context 与并发

goroutine 很轻量，但仍占用内存、调度和外部资源。并发设计首先回答谁启动、谁停止、谁等待、谁关闭 channel，以及错误如何取消其他工作。若这些答案不清楚，增加 channel 只会把阻塞藏得更深。

一、学习目标

建立 goroutine 生命周期和所有权
正确选择 channel、mutex 与原子操作
实现有界 worker 并传播首个错误
使用 context 取消整条调用链
通过 race detector 和泄漏测试验证并发

二、所有权与 happens-before

启动 goroutine 的函数应知道它何时结束，或把等待句柄明确交给调用方。go f() 后立即返回且没有停止方式，是最常见的泄漏入口。

Channel 发送/接收、关闭、mutex 解锁/加锁等同步操作建立内存可见性关系。不要用 time.Sleep 猜测另一个 goroutine 已完成。共享计数使用锁或 atomic，复杂状态通常由一个 goroutine独占并通过消息交互更清楚。

三、Channel 关闭规则

通常由发送方关闭 channel，因为它知道不会再有值：

jobs := make(chan Task)
go func() {
    defer close(jobs)
    for _, task := range tasks {
        jobs <- task
    }
}()

接收方不要关闭仍可能被其他发送者使用的 channel。关闭不是广播任意错误的机制；接收方可通过第二返回值判断流结束。nil channel 可用于 select 中动态禁用分支，但未经说明的 nil 往往导致永久阻塞。

四、有限并发

同步任务使用固定 worker 数或信号量限制并发，不能为未知数量的输入无界启动 goroutine。一个简单 worker 池需要：

输入 channel 的唯一关闭者。
WaitGroup 等待所有 worker。
受控错误通道或共享首错。
context 取消剩余工作。
输出消费者不会提前退出导致发送者阻塞。

并发数应来自配置并有合理上限。更多 worker 可能触发远端限流、耗尽文件描述符或增加锁竞争。

五、Context 传播

context.Context 作为首个参数跨越请求边界传递，不存入结构体作为可变全局：

func (s *Service) Sync(ctx context.Context, tasks []Task) error

每个可能阻塞的 select 都应包含 ctx.Done()，HTTP 请求使用 NewRequestWithContext。取消只是一条信号，函数仍要退出循环、关闭自己拥有的资源并返回 context.Cause 或包装错误。

值只用于请求范围元数据，不用于可选参数或业务配置。

六、竞态、死锁与泄漏

运行：

go test -race ./...

Race detector 只发现实际执行路径上的数据竞态，不证明不存在。死锁可能表现为所有 goroutine 阻塞；测试应设置 deadline 并在失败时采集 goroutine 栈。

泄漏测试可反复调用并取消操作，等待所有显式 WaitGroup 完成。不要只比较 runtime.NumGoroutine 的瞬时数字，因为测试框架和运行时也会创建 goroutine；更可靠的是让组件暴露停止/等待契约。

七、从知识点到工程契约

本篇的示例最终要进入可维护的 Go 包，而不是停留在 main 中的一次性片段。先把目标写成调用者可以观察的契约：输入是否允许零值或 nil，返回值是否是快照，错误能否通过 errors.Is/As 分类，函数是否启动 goroutine、取得资源或修改共享状态。然后再选择结构体、接口、函数值或泛型；抽象形式必须服务于契约，而不是反过来决定需求。

可以用以下顺序把知识点落到工程代码：

在独立小函数中写出最小成功路径，并让 go test 能直接调用。
加入一个与“无界为每个输入启动 goroutine”相关的失败样例，确认失败可观察且不会留下半完成状态。
把文件、网络、时间、环境或并发等外部因素改成显式依赖，测试使用临时目录、固定时钟或本地服务。
运行 gofmt、vet 和相关测试；涉及共享状态时追加 -race，涉及解析器时追加有上限的 fuzz。
最后再评估 API 是否需要导出。只在同一模块内部使用的能力保留在 internal，避免过早形成公共兼容负担。

审查代码时至少回答四个问题：谁拥有数据，谁允许修改，失败由谁处理，工作由谁停止。Go 的垃圾回收只解决不可达内存回收，不会替你关闭文件、取消请求、等待 goroutine 或恢复被覆盖的数据。只要其中一个问题没有答案，就先缩小函数或包的边界。

本篇最重要的能力是“建立 goroutine 生命周期和所有权”。不要用注释替代可执行约束：能由类型表达的就交给类型，能由构造或验证表达的就返回错误，能由测试观察的就保存回归用例。示例扩展到 StudyTasks 时，还要保持领域包不导入命令行、文件和 HTTP 细节。

八、验证策略与复盘

验证分为静态、动态和故障三层。静态层检查格式、模块图和分析器；动态层用正常输入证明结果；故障层主动制造取消、权限、损坏数据、超时或竞态。一次测试通过只能说明执行过的路径符合断言，不能证明所有输入都安全，因此需要让每条关键契约至少对应一个成功用例和一个反例。

建议保存下面的复盘记录：

项目	需要记录的证据
版本	`go version`、模块与 toolchain 指令
输入	最小正常值、零值、边界值和非法值
状态	调用前后数据、资源和 goroutine 的所有者
输出	返回值、错误链、stdout/stderr 与日志字段
失败	第一个失败点、清理动作和可恢复状态
工具	实际运行的 test、race、vet、benchmark 或 build 命令

完成验证后，用另一份干净临时目录重跑，不读取开发机的用户配置、缓存数据或真实网络。若测试只能按特定顺序成功，就说明状态隔离仍不完整。若为了让测试通过必须长时间 sleep，应改用 channel、WaitGroup、context 或可注入时钟表达确定的同步条件。

本篇可以用以下目标做验收：正确选择 channel、mutex 与原子操作；实现有界 worker 并传播首个错误；使用 context 取消整条调用链。把它们逐项转成命令输出或断言，而不是写成“人工看起来正确”。当实现与预期不符时，先保存最小失败样例，再调整设计。

发布前再做一次反向审查：从调用方而不是实现内部出发，写出一个完全不知道具体类型和文件布局的使用示例；从故障点出发，假设进程在每个 I/O 之后被取消；从升级出发，假设下一版改变字段或默认值。若调用方必须知道未公开细节、故障会留下无法判断的状态，或升级只能覆盖旧数据，契约就还不完整。把这三个场景加入测试或文档，比继续增加抽象更有价值。

最后检查示例能否被复制到一份最小程序独立运行，所有导入、错误处理和清理是否完整。教学代码可以省略与主题无关的界面，却不能省略会改变正确性的 context、Close、边界检查或同步。对为了篇幅省略的部分要明确标注，不能让读者把伪代码误当成生产承诺。

九、StudyTasks 实践

为 sync 实现最多 4 个 worker 的并发上传。第一个不可恢复错误取消其余任务，函数等待所有 worker 退出后返回。用本地慢服务验证并发上限、取消延迟、无阻塞发送，并在 race detector 下重复运行。

完成本节后，不要只保存代码或 SQL。请同时保存执行命令、关键输出和失败案例；学习笔记真正有价值的部分，是能够说明输入、状态变化、输出以及失败后的恢复方式。

十、常见错误

无界为每个输入启动 goroutine
由接收方关闭仍有发送者的 channel
用 sleep 等待并发操作完成
创建 context 后不传播到最底层 I/O
函数返回时留下无法停止或等待的后台 goroutine

十一、练习与自测

实现带并发上限和首错取消的 Map，并验证输出顺序契约。
制造一个因消费者提前返回导致的发送阻塞，再修复。
比较 mutex 保护 map 与单 goroutine 所有权两种设计。
让测试超时时打印 goroutine 栈，定位一次故意死锁。

自测时应在干净的临时目录或临时数据库中重新执行，而不是依赖上一节遗留的状态。如果结果与预期不同，先记录实际输出，再缩小问题范围。

十二、官方资料

版本行为与二手文章不一致时，以本系列固定版本的官方文档、命令输出和可重复测试结果为准。

上一篇：HTTP、JSON 与 API 客户端下一篇：测试、调试与代码质量