90%场景该用fmt.errorf，因其支持%w链式包装、保留错误上下文和堆栈，便于errors.is/as断言及可观测性；errors.new仅适用于无参数、不需包装的哑错误。
Go 错误注入该用 errors.New 还是 fmt.Errorf
直接说结论：90% 场景下该用 fmt.Errorf，尤其涉及上下文传递或链式错误时。errors.New 只适合无参数、无堆栈、不打算被进一步包装的哑错误。
常见错误现象是：注入后日志里只看到 "failed to connect"，但完全不知道发生在哪次重试、哪个服务实例、带什么请求 ID——这会让故障定位变成盲猜。
-
fmt.Errorf("timeout on %s: %w", endpoint, err)能保留原始错误链，配合errors.Is/errors.As做精准断言 - 如果注入点在中间件或拦截器里，务必用
%w而非%s，否则errors.Unwrap会断掉 -
errors.New创建的错误无法被errors.Is正确匹配（除非你拿指针比对），在断言失败路径时容易漏判
在 HTTP handler 里安全注入错误而不崩掉整个服务
别在 http.HandlerFunc 里直接 panic 或返回裸 http.Error——这会让混沌实验失控，把压测流量全打成 500，还掩盖了真实超时/重试行为。
正确做法是让错误“流下去”，交给已有错误处理链路消化。比如你用的是 chi 或自定义中间件，就该复用它的错误传播机制。
立即学习“go语言免费学习笔记（深入）”；
- 注入点放在业务逻辑层（如
service.GetUser()），而不是http.ServeHTTP入口；handler 层只负责转译错误为 HTTP 状态码 - 避免在 defer 里 recover 后吞掉错误——混沌实验要可观测，吞掉等于白注入
- 如果必须在 handler 注入，用
return显式退出，并确保上层中间件能捕获到这个 error 值（不是 panic）
go.uber.org/zap 日志里怎么标记这是注入的错误
不加标记的日志和真实故障日志混在一起，后期查 SLO 影响、做 MTTR 分析时根本分不清哪些是演练、哪些是事故。
最轻量但有效的方式：统一加一个结构化字段，比如 chaos_injected: true，且必须在错误创建时就带上，不能等 log 语句里再补。
- 封装一个注入专用错误构造函数：
ChaosErrorf(msg string, args ...interface{}) error，内部用fmt.Errorf并附带chaos=true上下文 - 在 zap 的
error字段外，额外写zap.Bool("chaos_injected", true)，不要依赖 message 里写 “(CHAOS)” 这种字符串匹配 - 注意：如果用了
zap.Error(err)，而 err 是你自己包装的，确保它实现了MarshalLogObject接口，否则 chaos 标记不会出现在结构体里
并发场景下错误注入的竞态风险
在 goroutine 里随机注入错误，很容易撞上 context.WithTimeout 或 sync.Once 这类本身就有状态的组件，导致注入失效或 panic。
典型表现是：本地跑 10 次都成功注入，压测时却几乎不触发——大概率是竞态掩盖了错误抛出时机。
- 避免在
select+case 之后再注入错误，此时 context 已 cancel，再 return error 会被上层忽略 - 如果注入点在 shared struct 方法里（比如
db.Client.Query()），确认该方法不是被多个 goroutine 共享同一实例且未加锁 - 测试时用
go run -race跑一遍注入逻辑，重点看错误对象是否被跨 goroutine 读写（比如反复赋值给同一个err变量）
