控制流、函数与错误设计

Go 把错误作为普通返回值，使调用路径上的失败显式可见。好的 Go 函数不仅能返回正确结果，还要让调用者区分可恢复的业务情况、外部依赖失败和程序不变量破坏。控制流应围绕这些边界保持短而清楚。

一、学习目标

使用 if、switch、for 与 range 表达清晰分支
通过早返回降低嵌套
设计多返回值和命名返回值
使用 %w、errors.Is、errors.As 维护错误链
区分业务错误、基础设施错误与 panic

二、控制流与作用域

Go 只有 for 一种循环，但可表达计数、条件和无限循环。if 与 switch 可带初始化语句，把临时变量限制在分支作用域：

if task, ok := byID[id]; ok {
    return task, nil
}
return Task{}, ErrNotFound

优先处理失败并早返回，使主路径保持左对齐。switch 默认不贯穿分支，类型 switch 用于接口动态类型。不要把复杂业务规则压成布尔表达式；给条件命名通常比增加注释更清楚。

三、函数签名与返回值

多返回值适合同时返回结果与错误：

func ParseStatus(input string) (Status, error) {
    switch strings.ToLower(strings.TrimSpace(input)) {
    case "todo":
        return StatusTodo, nil
    case "done":
        return StatusDone, nil
    default:
        return 0, fmt.Errorf("parse status %q: %w", input, ErrInvalidStatus)
    }
}

命名返回值适合短小函数或 defer 需要观察结果的场景；长函数中过度使用会隐藏赋值来源。参数按值复制，是否传指针应由修改语义、复制成本和 nil 合法性决定，而不是机械地把所有结构体都改成指针。

四、错误链与稳定契约

哨兵错误可表达稳定的程序判断：

var ErrNotFound = errors.New("task not found")

return Task{}, fmt.Errorf("load task %s: %w", id, ErrNotFound)

调用方用 errors.Is(err, ErrNotFound)，不要比较错误文本。需要读取结构化字段时定义错误类型并使用 errors.As。包装文字应补充动作和对象，避免重复“failed to”噪声。

一旦调用方依赖某个错误可被 Is/As 识别，它就成为 API 契约。内部实现更换时要保持这条语义，或明确发布破坏性变更。

五、多个错误与清理失败

批量操作可能产生多个独立错误，errors.Join 可以保留每条错误链：

var errs []error
for _, task := range tasks {
    if err := validate(task); err != nil {
        errs = append(errs, fmt.Errorf("task %s: %w", task.ID, err))
    }
}
return errors.Join(errs...)

但聚合错误不适合需要原子性的写操作；如果一项失败就应整体回滚，就不要继续执行再汇总。关闭资源也可能失败，必须根据资源类型决定主操作错误和关闭错误如何组合，而不是无条件丢弃 Close。

六、panic 的边界

panic 表示程序无法在当前抽象层正常继续，常用于违反内部不变量或标准库无法恢复的初始化错误。用户输入、文件不存在、HTTP 超时都应返回错误。

recover 只能在同一 goroutine 的 defer 中捕获 panic。应用入口可以记录并转换退出码，服务器可以在请求边界隔离单个请求，但业务函数不应到处 recover 后假装成功。测试可以断言确实不应发生的 panic，同时优先修复根因。

七、从知识点到工程契约

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

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

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

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

本篇最重要的能力是“使用 if、switch、for 与 range 表达清晰分支”。不要用注释替代可执行约束：能由类型表达的就交给类型，能由构造或验证表达的就返回错误，能由测试观察的就保存回归用例。示例扩展到 StudyTasks 时，还要保持领域包不导入命令行、文件和 HTTP 细节。

八、验证策略与复盘

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

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

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

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

本篇可以用以下目标做验收：通过早返回降低嵌套；设计多返回值和命名返回值；使用 %w、errors.Is、errors.As 维护错误链。把它们逐项转成命令输出或断言，而不是写成“人工看起来正确”。当实现与预期不符时，先保存最小失败样例，再调整设计。

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

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

九、StudyTasks 实践

为 add、done、delete 定义错误契约：空标题、任务不存在、任务已完成分别怎样表达。让 CLI 通过 errors.Is 映射退出码和用户消息，同时保留一条包含动作上下文的诊断日志。

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

十、常见错误

比较错误字符串或依赖本地化文本做程序分支
包装错误时使用 %v，意外切断错误链
对用户输入使用 panic，或随处 recover 后忽略失败
长函数滥用命名返回值，难以看出结果何时改变
把可部分成功的批处理和必须原子的写入混为一谈

十一、练习与自测

定义带 TaskID 字段的 NotFoundError，并同时支持 errors.Is 和 errors.As。
为 ParseStatus 写表驱动测试，覆盖大小写、空白和非法输入。
组合主操作错误与 Close 错误，并说明调用方如何检查两者。
重构一个三层嵌套分支为早返回，比较可读性。

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

十二、官方资料

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

上一篇：数组、切片、映射与常用数据结构下一篇：包、模块、工作区与依赖