Go混沌工程需精准可控：PodChaos须校验label匹配与Pod状态，NetworkChaos需确认网络模式及低丢包率起步，代码层注入应保留错误链并结构化日志，Istio故障依赖sidecar与域名精确匹配。
Go 本身不提供“故障注入”原语，所有注入行为都得靠外部工具或代码层主动干预；直接在业务逻辑里写 time.Sleep 或 return errors.New("chaos") 看似简单，但脱离可观测性、不可控、难复现——这不是混沌工程，是随机崩坏。
PodChaos 不生效？先确认 labelSelector 是否真能匹配到 Pod
Chaos Mesh 的 PodChaos 类型失效，90% 情况不是 YAML 写错，而是目标 Pod 根本没被选中。
- 用
kubectl get pod -n <ns> --show-labels查真实 label，别信 Deployment 里写的静态值 - 优先用稳定 label，比如
app: user-service，避开pod-template-hash或version这类滚动更新时会变的字段 - 加
podPhase: Running字段，避免 chaos 在容器启动中就被调度，实际未注入 - 查 Chaos Mesh controller 日志：
kubectl logs -n chaos-testing deploy/chaos-controller-manager | grep -i "podchaos"，看有没有no matching pods
NetworkChaos 丢包/延迟没反映到 Go HTTP 请求上？检查流量路径是否被绕过
NetworkChaos 依赖 eBPF 或 tc 在 Pod 的 eth0 接口注入异常，但它对 Go runtime 的 DNS 解析、连接池复用、甚至 http.Transport 的 idle 复用逻辑完全无感。
- 确保目标 Pod 是
hostNetwork: false（默认就是），否则网络规则不生效 - 丢包率别一上来就设 50%，
context deadline exceeded可能比预期丢包更早触发；建议从loss: "5%"起步 - 若服务间走 gRPC，记得配
grpc.WithBlock()和显式超时，否则 NetworkChaos 延迟一叠加，gRPC 直接快速失败，看不出渐进式降级 - 验证是否生效：进 Pod 执行
curl -v --connect-timeout 2 http://other-svc，别只看业务日志或重试计数
想在 Go 代码里可控注入错误？别 panic，要可传播、可标记、可断言
在 handler 或 service 层硬塞 http.Error 或 panic，会让实验失去可观测性，也干扰原有错误处理链路。
立即学习“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() }()里吞掉注入错误——混沌必须暴露，否则等于没做
Istio VirtualService 故障规则没反应？重点查 sidecar 和匹配条件
Istio 的故障注入完全发生在 Envoy 侧，Go 应用进程对此一无所知。它只收到一个慢响应或 503，不会感知“自己被注入了延迟”。
- 确认 Pod 已注入 sidecar：
kubectl get pod -l app=your-go-app输出应有 2 个容器（app + istio-proxy） -
VirtualService.host必须严格匹配服务全限定域名，如user-service.default.svc.cluster.local，不能写localhost或短名 - 规则只对匹配的 route 生效：若你配置了
http:但请求实际走 mTLS 或 HTTPS，规则会被跳过 - 查 Envoy 访问日志：
kubectl logs -l app=your-go-app -c istio-proxy | grep "503\|delayed"，看upstream_service_time和response_code字段
真正难的从来不是“怎么让服务出错”，而是“怎么让错误发生得精准、可观测、可回滚”。比如 StressChaos 压 CPU 后 Go 程序没卡住——那得搭配 MemoryChaos 一起用，因为 GC 触发时机和内存压力才是 Go 真正的脆弱点。
