Go错误测试核心是主动触发错误路径并验证返回、包装及清理逻辑；需用mock控制错误时机，显式断言错误类型与内容，覆盖传播链路，并检查副作用是否正确执行。
在 Go 中测试错误处理流程，核心是主动触发错误路径，验证函数是否按预期返回错误、是否正确包装错误、是否执行了必要的清理逻辑。关键不在于“覆盖所有错误”，而在于“控制错误发生时机”并“断言错误行为的合理性”。
用自定义依赖模拟错误场景
多数错误来自外部依赖（如数据库、HTTP 客户端、文件系统）。测试时应替换为可控的 mock 或 fake 实现，使其在特定调用中返回预设错误。
- 对 io.Reader / io.Writer 接口，可用
bytes.NewReader(nil)或nil值触发读写错误 - 对 http.Client，可设置自定义
http.RoundTripper，在匹配 URL 时返回&url.Error{Err: errors.New("timeout")} - 对数据库操作，用
sqlmock库让某次QueryRow()返回sql.ErrNoRows或自定义错误
显式断言错误类型与内容
不要只检查 err != nil，要验证错误是否符合预期：是特定错误变量、是否包含关键信息、是否被正确包装（如用 fmt.Errorf("xxx: %w", err)）。
- 用
errors.Is(err, fs.ErrNotExist)判断是否为某个哨兵错误 - 用
errors.As(err, &target)提取底层错误类型（如*os.PathError） - 用
strings.Contains(err.Error(), "timeout")辅助验证错误消息（仅当消息属公共契约时）
覆盖常见错误传播链路
真实项目中错误常跨多层传递。测试需覆盖：底层出错 → 中间层包装 → 上层判断并响应 的完整路径。
立即学习“go语言免费学习笔记（深入）”；
- 写一个测试，让最底层函数返回
io.EOF，验证上层是否返回fmt.Errorf("read config: %w", err) - 再写一个测试，断言最终错误经
errors.Is(..., io.EOF)仍能回溯到原始错误 - 避免在中间层用
err.Error()拼接新错误——这会切断错误链
验证错误发生时的副作用是否正确
错误处理不只是返回 error，还常伴随资源释放、状态重置、日志记录等副作用。这些必须被测到。
- 若函数打开文件后出错，应确保
defer f.Close()或显式Close()被调用（可用计数器或 interface mock 验证 Close 是否执行） - 若函数修改了结构体字段，错误路径下应确认字段未被意外更新（例如未设置默认值、未进入非错误分支逻辑）
- 用
testify/assert.Called(t, mockLog.Printf)或类似方式检查错误日志是否输出
基本上就这些。不复杂但容易忽略的是：错误测试不是“为了测而测”，而是确保程序在坏情况下的行为可预测、可维护、可调试。
