chaos mesh 注入网络延迟无效，首要检查 crd 版本兼容性与 pod label 是否精确匹配（含大小写、连字符），其次确认 go 客户端是否因自定义 transport 掩盖延迟表现。
用 chaos-mesh 注入网络延迟，但 Pod 没反应？检查 CRD 和 label 匹配
Chaos Mesh 是目前 Go 服务最常用的 Chaos Engineering 工具，但它不靠代码侵入，而是靠 Kubernetes CRD + label 选择器生效。常见现象是：YAML 提交成功、chaosctl 显示运行中，但目标 Go 服务完全没延迟——大概率是 label 不匹配或 CRD 版本错。
- 确保目标 Pod 的 label（比如
app=api-server）和NetworkChaos.spec.selector.labelSelectors完全一致，大小写、连字符都不能差 - Go 应用若用
net/http默认客户端，延迟对 outbound 请求有效；但若用了http.Transport自定义超时或连接池，可能掩盖故障表现 -
chaos-meshv2.6+ 要求集群启用admissionregistration.k8s.io/v1，旧版 K8s 需降级到 v2.5 或手动 patch webhook - 延迟注入实际发生在 iptables 层，所以
curl -v看到的time_namelookup不变，但time_connect和time_total会明显拉长
在 Go 单元测试里模拟依赖故障，别用 time.Sleep 打乱并发逻辑
本地验证容错逻辑时，直接在 test 中 sleep 等待 chaos 触发，会导致测试不可靠、难并行。Go 原生支持更可控的方式。
- 用
context.WithTimeout包裹调用，让下游超时由 context 控制，而不是靠外部延迟注入 - 对 HTTP 客户端，替换
http.DefaultClient为自定义&http.Client{Transport: &roundTripMock{}}，在RoundTrip方法里返回net.ErrClosed或伪造 503 - 数据库层推荐用
sqlmock，调mock.ExpectQuery().WillReturnError(sql.ErrNoRows)比等真实 DB 故障快且稳定 - 避免在 test 文件里 import
github.com/chaos-mesh/chaos-mesh/pkg/clients—— 这是控制器代码，test 里用它等于把集成测试当单元测试跑
go test -race 发现 data race，但线上没报？Chaos 可能放大竞态窗口
Race detector 在常规负载下不一定触发问题，而 Chaos Engineering（比如 CPU 打满、GC 频繁触发）会让原本隐藏的竞态浮出水面。这不是误报，是时机问题。
-
go run -race main.go启动服务后，用stress-ng --cpu 4 --timeout 30s模拟高负载，再发请求，比单纯压测更容易复现 data race - Go 的
sync.Map不是万能的：如果先Load再Store（非原子操作），race detector 仍会报警；应改用LoadOrStore或加sync.RWMutex - 日志打点若用
log.Printf+ 全局变量拼接字符串，高并发下易因字符串逃逸引发竞争——换成log.WithValues("req_id", id).Info("handled")（如使用go-logr）更安全
用 goleak 检测 goroutine 泄漏，但 chaos 后 false positive 多？看是否 cleanup 遗漏
Chaos 测试中 goroutine 泄漏常被误判，本质是测试未等异步资源释放完就结束。goleak 报告里出现 http.(*persistConn).readLoop 或 net/http.serverHandler.ServeHTTP 并不总代表泄漏。
立即学习“go语言免费学习笔记（深入）”；
- 测试末尾加
time.Sleep(100 * time.Millisecond)不解决问题，要用goleak.IgnoreTopFunction("net/http.(*persistConn).readLoop")忽略已知良性 goroutine - Go HTTP server 若没显式调
srv.Shutdown(ctx)就直接srv.Close()，底层连接 goroutine 会卡住；chaos 场景下更易堆积 - 第三方库（如
redis-go、pgx）的连接池默认 keep-alive，测试中应调pool.Close()或设MaxIdleTime = 1s加速回收
真正难搞的是那些没暴露 shutdown 接口的库，或者依赖信号量等待外部事件的 goroutine——它们不会自己退出，得靠测试主动通知或设超时 cancel。
