PodChaos 失效主因是 label 不匹配和 podPhase 未设为 Running；NetworkChaos 对复用连接无效，需调低丢包率并验证新建连接；错误注入须保留错误链与结构化日志；StressChaos 需搭配 MemoryChaos 并关注 Go 运行时指标。
PodChaos 不生效？先查真实 label 和 podPhase
Chaos Mesh 的 PodChaos 类型失效，90% 是因为没真正匹配到目标 Pod。Kubernetes 中的 label 并不总是和 Deployment YAML 里写的一致——比如 pod-template-hash、app.kubernetes.io/version 这类字段在滚动更新后会变，硬写进 chaos 配置就容易失效。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
kubectl get pod -n <ns> --show-labels查 Pod 当前真实 label，别信配置文件里的静态值 - 优先选稳定 label，如
app: user-service，避开易变字段 - 在
PodChaosspec 里显式加上podPhase: Running，避免 chaos 被调度到容器启动中（Pending或ContainerCreating）状态的 Pod 上 - 查 controller 日志：
kubectl logs -n chaos-testing deploy/chaos-controller-manager | grep -i "podchaos"，看是否有no matching pods报错
NetworkChaos 丢包/延迟没反应？检查流量路径和客户端行为
NetworkChaos 依赖 eBPF 或 tc 在 Pod 的 eth0 接口注入异常，但它对 Go runtime 的 DNS 缓存、连接池复用、http.Transport 的 idle 复用逻辑完全无感——也就是说，它只影响“新建连接”或“未复用的请求”，而 Go 默认复用连接，可能根本走不到被干扰的路径。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认目标 Pod 是
hostNetwork: false（默认就是），否则tc规则不会生效 - 丢包率别一上来就设
loss: "50%"；Go 的 HTTP client 默认超时短，context deadline exceeded会比丢包更早触发；建议从loss: "5%"起步 - 若服务间走 gRPC，必须配
grpc.WithBlock()+ 显式超时，否则 NetworkChaos 延迟叠加后，gRPC 直接快速失败，看不出渐进式降级 - 验证是否生效：进 Pod 执行
curl -v --connect-timeout 2 http://other-svc，别只看业务日志或重试计数
代码层注入错误？别 return errors.New，要保留错误链和结构化日志
在 handler 或 service 层硬塞 http.Error 或 panic，会让混沌实验失去可观测性，也破坏原有错误处理链路。真正的可控注入，必须能被断言、能被追踪、不能被 recover 吞掉。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 注入点放在业务函数内（如
service.GetUser(ctx, id)），而非http.ServeHTTP入口 - 统一用
fmt.Errorf("timeout on %s: %w", endpoint, err)，保留错误链，支持errors.Is()断言 - 用结构化日志标记混沌行为：
zap.Bool("chaos_injected", true)，不要靠 message 里写"(CHAOS)"字符串匹配 - 避免在
defer func() { recover() }()里吞掉注入错误——混沌必须暴露，否则等于没做
StressChaos 压 CPU 没卡住？Go 的 GPM 调度模型会绕过压力
StressChaos 启动的是独立 stress-ng 进程，它只抢系统 CPU 时间片，并不直接阻塞 Go runtime 的调度器。即使 CPU 使用率 100%，只要还有空闲 P（processor），goroutine 仍可能被调度执行——所以你感觉“程序没卡”，其实是 Go 的并发模型在起作用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别只压 CPU，搭配
MemoryChaos一起用——内存紧张时 GC 延迟、OOM kill 更容易暴露调度瓶颈和 channel 阻塞问题 -
StressChaos的workers数建议设为 Pod CPUrequests的 1.5 倍，比如requests: 2就设workers: 3；设太高会被 kubelet kill，太低压不出效果 - 观察指标重点不是 CPU%，而是 Go runtime 指标：
go_goroutines、go_gc_duration_seconds、http_client_request_duration_seconds是否出现毛刺或长尾
