结论：靠接口+一堆if-else切策略不是策略模式，而是条件判断搬运工；真正策略模式要求契约窄（仅输入→输出）、上下文不参与选择、di容器统一管理注册与生命周期。
直接说结论：靠接口+一堆 if-else 切策略，不是策略模式，是给策略模式贴了个标签的条件判断搬运工。真正起效的关键，是让策略契约窄到只管“输入→输出”，上下文不参与选择逻辑，DI 容器管注册和生命周期——否则你只是把 if 从 Controller 搬进了 Context。
IStrategy 接口别写成空壳或万能泛型
常见错误是定义一个空接口 IStrategy，或者搞出 IProcessor<tin tout toptions tcontext></tin> 这种泛型套娃。结果新加一个策略时，要么要改接口（违反开闭原则），要么得传 object 或强转（运行时报错）。
- 按真实输入输出边界定义，比如
IChargeProcessor<chargerequest chargeresult></chargerequest>，而不是笼统的IPaymentStrategy - 方法签名必须明确同步/异步：用
Task<chargeresult></chargeresult>就别混用ChargeResult；统一返回Result<t></t>类型，别有的抛异常、有的返回bool+out string - 禁止在接口里暴露配置字段（如
ConnectionString）、框架对象（如HttpContext、IServiceProvider）——这些该通过构造函数注入
Context 类不能偷偷做策略路由
很多人写 OrderProcessor 时，在 Execute() 里根据 order.PaymentMethod 去 switch 或查字典选策略，这等于把策略选择逻辑又塞回了上下文，跟写 if-else 没本质区别。
-
Context构造函数只接收IStrategy，不接收string name、Type、IConfiguration节点 - 禁用
new SqlPaymentStrategy()这类硬编码实例化——它绕过 DI，导致生命周期失控（比如 Scoped 策略被当 Singleton 用） - 需要运行时切换？提供
SetStrategy(IStrategy s)方法，由上层（比如 API Controller）决定传哪个，而不是让 Context 自己查
.NET 6+ 注册策略别手写 Dictionary
手动维护字典看似可控，但一接入多租户、插件热加载或 Scoped 服务依赖，立刻崩：Key 写错没提示、重复注册、作用域错乱、服务根本没注册。
- 注册用
AddScoped<istrategy emailnotificationstrategy>()</istrategy>，配合元数据标记（如[StrategyName("email")]），比字符串 Key 更安全 - 解析时别用
GetService<istrategy>()</istrategy>，要用GetServices<istrategy>()</istrategy>拿全部，再按需筛选（比如用FirstOrDefault(s => s.Name == "alipay")） - 如果策略内部要访问 Scoped 服务（如
IDbContextFactory<appdbcontext></appdbcontext>），调用方必须自己创建IServiceScope，别在策略里new ServiceScope()，否则报InvalidOperationException: No service for type 'X' has been registered
DI 报错 No service for type 'X' 怎么快速定位
这个错误不是策略类写错了，而是 DI 链断在某一层：要么策略本身漏注册，要么它构造函数里某个参数（比如 IOptions<paymentconfig></paymentconfig>）没显式调用 AddOptions<paymentconfig>()</paymentconfig>，或者生命周期冲突（Transient 策略注入了 Singleton 服务，而该 Singleton 又依赖 Scoped 服务）。
- 从报错策略类开始，逐个检查构造函数参数，确认每个类型都在
Program.cs显式注册过 - 特别注意
IOptions<t></t>、IConfiguration、IHttpClientFactory这些“看着像自带”的服务——它们全都要手动注册 - 加一行
var all = provider.GetServices<istrategy>().ToList();</istrategy>打印已注册策略列表，一眼看出缺哪个实现类
策略最难的从来不是写几个类，而是划清边界：哪些该进策略、哪些该由上下文传入、哪些该交给装饰器或中间件兜底。一旦把日志、重试、缓存塞进策略实现里，你就已经走偏了。
