Go中主动触发熔断或超时需在关键路径注入故障：HTTP通过context.WithTimeout动态设超时并替换request context，gRPC客户端拦截器检查metadata后直接返回伪造错误；pprof仅采集数据不消耗CPU，真实CPU飙升需受控忙循环goroutine。
怎么用 Go 代码主动触发服务熔断或超时？
微服务故障注入不是靠随机 kill 进程，而是要在关键路径上可控地插入延迟、错误或资源耗尽。Go 的 net/http 和 context 是最直接的切入点——比如在 HTTP handler 中根据请求头或查询参数动态决定是否注入故障。
常见做法是封装一个带开关的中间件：
func FaultInjectMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if r.URL.Query().Get("inject") == "timeout" {
ctx, cancel := context.WithTimeout(r.Context(), 50*time.Millisecond)
defer cancel()
r = r.WithContext(ctx)
}
if r.URL.Query().Get("inject") == "error" {
http.Error(w, "simulated error", http.StatusInternalServerError)
return
}
next.ServeHTTP(w, r)
})
}这样调用 /api/users?inject=timeout 就能复现下游响应慢的场景；?inject=error 则模拟依赖服务返回 5xx。注意：超时必须作用于 r.Context()，否则 handler 内部的 http.Client 调用不会感知。
如何让 gRPC 客户端返回伪造的失败状态？
gRPC 的故障注入难点在于拦截器（interceptor）不能直接修改返回的 status.Status，但可以在 unary client interceptor 中提前返回错误，跳过真实调用。
立即学习“go语言免费学习笔记（深入）”；
- 使用
grpc.WithUnaryInterceptor注册拦截器，检查ctx.Value或 metadata 是否含故障标记 - 若命中，则直接返回
status.Error(codes.Unavailable, "injected failure")，不执行invoker - 避免在拦截器里 sleep——这会阻塞整个连接池，应改用
time.AfterFunc或异步 goroutine 模拟延迟
示例中常误写成 time.Sleep(2 * time.Second) 后再调用 invoker，结果导致所有并发请求排队等待，和真实故障表现不符。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
为什么用 pprof + SIGUSR1 模拟 CPU 飙升效果不好？
runtime/pprof.StartCPUProfile 只采集采样数据，不实际消耗 CPU；而 kill -USR1 触发的是 profile dump，不是资源扰动。真正模拟高负载，得用忙循环或密集计算。
安全的做法是启动一个受控 goroutine：
func StartCPUSpike(duration time.Duration) {
done := make(chan struct{})
go func() {
defer close(done)
start := time.Now()
for time.Since(start) < duration {
// 空转但不阻塞调度器：用浮点运算+内存访问
var x float64
for i := 0; i < 10000; i++ {
x += math.Sqrt(float64(i))
}
runtime.Gosched() // 让出时间片，避免饿死其他 goroutine
}
}()
// 调用方需保存 done channel，超时后 close 它来终止
}重点：必须调用 runtime.Gosched()，否则单核机器上可能卡死整个服务；别用 for {} 死循环——它会让 Go 调度器无法切换协程。
注入网络分区时，iptables 规则为什么对 localhost 失效？
本地开发环境用 iptables -A OUTPUT -d 127.0.0.1 -j DROP 常无效，因为 Go 的 net/http 默认走 loopback 接口，而 iptables 的 OUTPUT 链不处理回环流量（除非启用 rp_filter 或改用 INPUT 链）。
更可靠的方式是：
- 改用
tc（traffic control）在 lo 接口上做丢包：tc qdisc add dev lo root netem loss 100% - 或让服务监听非
127.0.0.1地址（如192.168.1.100），再对这个 IP 设 iptables 规则 - Docker 环境下优先用
docker network disconnect断开容器间连通性，比宿主机 iptables 更贴近生产网络拓扑
真实故障往往不是“完全不通”，而是间歇性丢包或高延迟——所以别只测 100% 丢包，用 netem delay 200ms 50ms 模拟弱网更有效。
