Litmus 不是 Go 内置测试工具，而是 Kubernetes 原生混沌工程平台，依赖 CRD 驱动集群侧故障注入；Go 服务需暴露探针、健康端点和可观测性信号才可被有效混沌验证。
为什么 Litmus 不是 Go 项目的“内置测试工具”
Litmus 本质是一套 Kubernetes 原生的混沌工程平台，不是 Go 语言的测试库。你没法在 go test 里直接 import litmuschaos 包跑混沌；它运行在集群侧，靠 CRD（如 ChaosEngine、ChaosExperiment）驱动 Pod 注入故障。Go 代码只负责被测服务本身——比如你的微服务用 net/http 暴露健康端点，Litmus 才会通过探针判断它是否“挂了”。
常见错误现象：
- 试图在 Go 单元测试中调用 litmusctl 启动 chaos 实验，结果报 connection refused（本地没连上 K8s API Server）
- 把 Litmus 的 YAML 清单当成 Go 配置项硬编码进 config.go，导致环境切换失败
怎么让 Go 服务真正“可混沌”
关键不在 Go 怎么写 Litmus，而在 Go 服务是否暴露了 Litmus 能观察和干扰的接口与行为。Litmus 默认依赖三类信号：
- 就绪/存活探针：确保
livenessProbe和readinessProbe使用真实的业务逻辑（比如检查 DB 连接），而非固定返回 200 - 健康检查端点：暴露
/healthz或类似路径，返回结构化 JSON（含依赖状态），Litmus 的http_probe才能解析 - 可观测性埋点：在关键路径（如订单创建、缓存更新）打日志或上报指标，否则混沌发生后你只能看到 “Pod 重启了”，但不知道是 DB 断连还是 Redis 超时
示例：一个脆弱的健康检查写法：func healthz(w http.ResponseWriter, r *http.Request) { w.WriteHeader(200) }
正确做法应检查下游依赖并返回带字段的 JSON：{"status":"ok","db":"connected","cache":"timeout"}
Go 项目集成 Litmus 的最小可行路径
不碰 Go 代码本身，只改部署层和观测层。这是最稳定、最容易落地的方式：
- 用 Helm 或 Kustomize 将 Litmus 控制平面（
litmuschaos/litmuschart）部署到目标集群，确认ChaosOperatorPod Running - 为你的 Go 服务编写
ChaosEngineYAML，指定appLabel必须和 Deployment 的 label 完全一致（比如app: order-service） - 选一个预置实验，比如
pod-delete，注意设置spec.components.env.PODS_AFFECTED_PERC控制影响范围，避免全量删崩 - 用
litmusctl或 kubectl 直接 apply，然后 watchChaosResult状态：成功不等于“没出问题”，而是“实验按预期执行完毕”
性能影响：Litmus 的 chaos-exporter 会持续拉取指标，若集群 Prometheus 负载高，建议关闭 monitoring 模块，改用日志 + 自定义探针
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
容易被忽略的 Go 侧兼容性细节
混沌不是压测，它放大的是设计盲区。Go 服务里几个看似无关的细节，常让 Litmus 实验“看似成功、实则失效”：
- HTTP 客户端未设超时：
http.DefaultClient默认无超时，网络分区时 goroutine 泄漏，Litmus 的pod-network-loss实验后服务卡死但不崩溃，健康检查仍返回 200 - DB 连接池配置过小：
SetMaxOpenConns(5)，而 Litmus 并发启 10 个pod-delete，新 Pod 启动时抢不到连接，整个服务雪崩——但这不是 Litmus 的错，是 Go 服务没做连接池弹性适配 - 日志输出非 JSON 格式：Litmus 的
log_exporter无法解析fmt.Printf("error: %v", err)，导致故障链路无法自动关联
真正的难点从来不在怎么跑通 Litmus，而在于你的 Go 服务有没有把“失败”当成一等公民来建模——超时、重试、熔断、降级，这些不是混沌教给你的，是你得先写好，混沌才测得出来
