Golang模拟IO故障：错误注入压力测试方法

本文深入探讨了在 Go 语言中进行轻量、精准、可控的 IO 故障注入压力测试的四大核心实践：通过直接让 Read/Write 返回标准错误（如 io.ErrUnexpectedEOF、os.PathError）模拟磁盘读写失败；利用自定义 net.Listener 主动拒绝或秒断连接以复现网络抖动；规避不稳定的权限文件系统操作，转而用真实 syscall.Errno 类型错误触发权限校验逻辑；以及结合 context.WithTimeout 与手动 cancel，在 mock IO 方法中显式响应取消信号来真实模拟超时场景——所有方法均不依赖外部工具、不 mock 底层系统调用，兼顾测试准确性、性能与可维护性，直击线上高频故障痛点。

用 io.ErrUnexpectedEOF 或自定义错误触发读写失败

Go 标准库里没有“开箱即用”的 IO 故障注入机制，但你可以直接让 Read 或 Write 方法返回任意错误——这才是最轻量、最可控的方式。别绕路去 mock 文件系统或劫持 syscall，那会引入不可控的兼容性问题和性能干扰。

常见错误现象：测试代码跑通了，但线上一压就 panic，因为没覆盖 io.EOF、io.ErrUnexpectedEOF、net.ErrClosed 这类典型中断场景。

• 在测试中构造一个包装 io.Reader 的结构体，Read 方法按概率/计数返回 io.ErrUnexpectedEOF，而不是真实读到末尾
• 对 io.Writer 同理，可在第 N 次 Write 时返回 io.ErrShortWrite 或自定义错误（如 errors.New("disk full")）
• 避免用 fmt.Errorf("mock error")——它和标准库错误类型不一致，某些逻辑（比如 errors.Is(err, io.ErrUnexpectedEOF)）会失效
• 如果被测代码用了 io.Copy，记得它内部会忽略 io.EOF，但不会忽略 io.ErrUnexpectedEOF，这点很关键

用 net.Listener 拦截连接并主动关闭模拟网络抖动

HTTP 或 RPC 压测时，光搞磁盘 IO 不够，连接建立失败、半途断连才是高频故障。直接操作 net.Listener 是最贴近真实的切入点，不用改业务代码，也不依赖外部工具。

使用场景：验证客户端重试逻辑、连接池是否泄漏、超时是否生效。

• 实现 net.Listener 接口，Accept 方法随机 return (nil, errors.New("connection refused")) 或先 accept 再立刻 conn.Close()
• 把你的 HTTP server 启动在该 listener 上：http.Serve(mockListener, handler)，这样所有进来的连接都经过你控制
• 注意：不要在 Accept 中 sleep 或阻塞太久，否则压测工具（如 wrk）会卡住；错误应立即返回
• Go 1.18+ 的 net/http/httptest 不支持这种底层拦截，别试图用 httptest.NewUnstartedServer 替代

避免用 os.MkdirAll + os.Chmod 模拟权限错误

有人会想：我把目录 chmod 000，再让程序去写，不就触发 permission denied 了吗？这在单测里看似可行，但压力测试下极不稳定——并发写入时权限检查时机不可控，还可能污染测试环境，CI 机器上更可能因沙箱限制失败。

性能影响：每次 os.Chmod 都是系统调用，压测中频繁切换权限会拖慢整个测试节奏，且无法精确控制在哪次 write 出错。

• 直接让 mock os.File 的 Write 方法返回 &os.PathError{Op: "write", Path: "/fake", Err: syscall.EACCES}
• 确保 Err 字段是真实的 syscall.Errno 类型，否则像 os.IsPermission(err) 这类判断会返回 false
• 别用 os.OpenFile 打开真实路径再干预——文件句柄、缓存、defer 关闭都会干扰结果

用 context.WithTimeout 配合手动 cancel 模拟 IO 超时

很多服务的“IO 故障”本质是响应太慢，而非直接报错。Go 里最自然的表达就是 context 超时，但要注意：仅靠设置 context.WithTimeout 不够，你还得在 IO 操作中主动检查 ctx.Done() 并退出。

容易踩的坑：HTTP client 设置了 timeout，但 handler 里用了 time.Sleep 模拟耗时，没监听 context，导致超时不生效。

• 在 mock Read 方法里加 select { case ，并在某次调用时故意 delay 超过 deadline
• 如果被测代码封装了 io.ReadFull 或 json.Decoder.Decode，它们默认不接受 context，必须用带 context 的替代方案（如 http.NewRequestWithContext 构造请求）
• 不要在 goroutine 里启动 IO 然后等它自己结束——你要能精准控制“哪一次 read 被 cancel”，否则故障不可复现

真正难的是让错误出现在预期位置：比如第 3 次 Read 返回 EOF，第 7 次 Write 触发 timeout，第 2 个 accept 被拒绝。这些细节一旦写死在测试逻辑里，就很容易被并发打乱顺序，所以建议用原子计数器 + 条件判断，而不是全局状态。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang模拟IO故障：错误注入压力测试方法》文章吧，也可关注golang学习网公众号了解相关技术文章。