分布式系统测试应优先 mock 客户端而非启动全量服务，需覆盖超时、重试等边界；HTTP 用 httptest.Server，gRPC 需实现 Invoke 和 NewStream；并发测试须用 WaitGroup + chan/回调 + time.After 兜底。
用 testify/mock 模拟远程服务依赖
分布式系统测试最常卡在「调用链太深，真实服务不可控」。与其启动全套微服务，不如把 http.Client、grpc.ClientConn 或消息队列客户端替换成 mock 实例。
关键不是“能不能 mock”，而是 mock 是否覆盖了超时、重试、连接断开等边界行为：
- 用
testify/mock时，必须显式定义Call.Return()和Call.Times()，否则默认返回零值，容易掩盖空指针 panic - HTTP mock 推荐用
net/http/httptest.Server而非纯 mock，它能真实触发http.Transport的超时逻辑 - gRPC mock 需要实现
Invoke和NewStream两个方法，漏掉NewStream会导致流式接口测试始终失败
用 sync.WaitGroup + time.After 控制并发测试生命周期
测试并发组件（如事件分发器、状态同步器）时，直接用 time.Sleep 等结果是脆弱的——环境负载稍高就 flaky；但不等又可能漏掉异步写入。
正确做法是让被测代码主动通知测试完成：
立即学习“go语言免费学习笔记（深入）”；
- 在被测函数中传入
chan struct{}或回调函数，在关键路径末尾 close 或调用它 - 测试主 goroutine 用
sync.WaitGroup管理子 goroutine 数量，避免提前退出 - 必须加
time.After做兜底超时，否则死锁时go test会无限挂起 - 示例：
done := make(chan error, 1) go func() { done <- service.DoWork() }() select { case err := <-done: assert.NoError(t, err) case <-time.After(2 * time.Second): t.Fatal("test timed out") }
用 goroutines + runtime.Gosched() 触发竞态条件
单元测试里复现 data race 很难，因为调度顺序不可控。想验证锁或原子操作是否真起作用，得主动“搅局”。
不要依赖 -race 被动发现，而要在测试中构造确定性竞争：
- 启动多个 goroutine 并发读写同一变量，中间插入
runtime.Gosched()增加调度点 - 用
atomic.LoadUint64/atomic.StoreUint64替代普通读写，观察值是否符合预期序列 - 注意：不能在测试中用
sync.RWMutex包裹整个临界区来“修复”问题——那只是掩盖了设计缺陷 - 如果业务逻辑本身依赖严格顺序（比如状态机跃迁），应改用
select+chan显式建模，而非靠锁抢执行权
用 etcd 本地集群做一致性协议集成测试
测试 Raft、Paxos 或自研共识模块时，单节点 etcd 进程无法暴露网络分区、leader 切换等真实问题。
必须跑最小三节点集群，且控制其网络行为：
- 用
docker-compose启三个etcd容器，通过network_mode: "bridge"隔离网络 - 用
iptables在容器内丢包模拟分区：iptables -A OUTPUT -d 172.18.0.3 -j DROP - 测试脚本里轮询
/v2/stats/self和/v2/stats/leader接口，确认节点是否感知到状态变化 - 注意：etcd v3.5+ 默认启用
strict-reconfig-check，测试期间需关掉，否则强制要求 quorum 才允许配置变更
分布式系统测试真正的难点不在工具链，而在如何让“不确定性”变得可预测——超时设多少、mock 返回什么错误、网络断几秒，这些参数背后都是对生产环境故障模式的理解。漏掉一个典型故障场景，测试就只是绿条而已。
