simmy 是为 polly 提供混沌注入能力的扩展库，必须基于 polly 策略链工作，不替代重试或熔断策略，仅支持 .net standard 2.0+，最新版为 4.0.0。
Simmy 是什么，和 Polly 什么关系
Simmy 是一个为 Polly 提供混沌注入能力的扩展库，不是独立的熔断/重试框架。它必须基于已有的 Polly 策略链工作，通过装饰器（PolicyWrap）在请求执行前、后或异常时插入随机故障（如强制失败、延迟、返回伪造响应）。没有 Polly 就无法使用 Simmy。
- Simmy 不替代
RetryPolicy或CircuitBreakerPolicy，而是让它们“在混沌中被测试” - 它只支持 .NET Standard 2.0+，不兼容 .NET Framework 4.6.1 以下版本
- 当前最新稳定版是
Simmy 4.0.0（对应Polly v7.2.3+），用旧版 Polly（v6.x）会报MethodNotFoundException
如何用 Simmy 添加随机失败策略
最常用的是 InjectFailureAsync，它能在任意策略执行前按概率触发异常，模拟下游服务宕机：
var chaosPolicy = MonkeyPolicy.InjectFailureAsync(
exceptionToThrow: new HttpRequestException("Simmy says: service is down"),
injectionRate: 0.1 // 10% 概率触发
);
<p>var resilientPolicy = Policy.WrapAsync(
chaosPolicy,
Policy.Handle<HttpRequestException>()
.WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromMilliseconds(100))
);</p>-
injectionRate是浮点数，范围 0–1；设为 0 相当于禁用混沌，设为 1 则每次必炸 - 异常类型必须和外层
Handle<t>()</t>匹配，否则不会进入重试逻辑 - 注意：此策略仅影响被包装的委托调用，不改变原始 HTTP 客户端行为
如何控制混沌开关和运行时调整
Simmy 的所有策略都支持 enabled 开关和 enabledAsync 异步开关，便于在生产环境灰度开启：
var chaosPolicy = MonkeyPolicy.InjectFailureAsync(
exceptionToThrow: new TimeoutException(),
injectionRate: 0.05,
enabled: () => Environment.IsDevelopment() // 仅开发环境启用
);
- 开关函数在每次策略执行时调用，可读取配置中心（如 Consul、AppSettings）动态变更
- 若用
enabledAsync，需确保返回ValueTask<bool></bool>，避免阻塞线程 - 不要直接在构造时硬编码
true/false，否则上线后无法关闭
常见踩坑：为什么混沌没生效
-
PolicyWrap 顺序写反：把混沌策略放在最外层（如 Policy.Wrap(chaos, retry)）才有效；若写成 Policy.Wrap(retry, chaos)，混沌只在重试结束后触发，失去测试意义
- 忘记 await：Simmy 所有策略都是
Async 后缀，调用时漏掉 await 会导致策略不执行，且无编译错误
- 混沌策略未参与执行：只定义了
chaosPolicy，但调用时仍用原始 httpClient.SendAsync()，没走 resilientPolicy.ExecuteAsync()
- 使用了同步方法（如
Execute）包装异步策略：会抛 NotSupportedException，必须匹配 ExecuteAsync / ExecuteAndCaptureAsync
PolicyWrap 顺序写反：把混沌策略放在最外层（如 Policy.Wrap(chaos, retry)）才有效；若写成 Policy.Wrap(retry, chaos)，混沌只在重试结束后触发，失去测试意义 Async 后缀，调用时漏掉 await 会导致策略不执行，且无编译错误 chaosPolicy，但调用时仍用原始 httpClient.SendAsync()，没走 resilientPolicy.ExecuteAsync() Execute）包装异步策略：会抛 NotSupportedException，必须匹配 ExecuteAsync / ExecuteAndCaptureAsync
Simmy 的核心价值不在“加功能”，而在“可控地破坏”——真正难的是设计有意义的混沌场景，比如只对特定路由注入延迟、对 5xx 响应跳过重试、或在数据库主从切换窗口期禁用缓存策略。这些都需要结合业务链路深度定制，而不是套个 InjectFailureAsync 就算完成。
