C产品如何满足特定用户需求？

本文共计1004个文字，预计阅读时间需要5分钟。

直接说结论：

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<string, IStrategy>

手动维护字典看似可控，但一接入多租户、插件热加载或 Scoped 服务依赖，立刻崩：Key 写错没提示、重复注册、作用域错乱、服务根本没注册。

• 注册用 AddScoped<istrategy emailnotificationstrategy>()</istrategy>，配合元数据标记（如 [StrategyName("email")]），比字符串 Key 更安全
• 解析时别用 GetService<istrategy>()</istrategy>，要用 GetServices<istrategy>()</istrategy> 拿全部，再按需筛选（比如用 FirstOrDefault(s => s.Name == "alipay")）
• 如果策略内部要访问 Scoped 服务（如 IDbContextFactory<AppDbContext>），调用方必须自己创建 IServiceScope，别在策略里 new ServiceScope()，否则报 InvalidOperationException: No service for type 'X' has been registered

DI 报错 No service for type 'X' 怎么快速定位

这个错误不是策略类写错了，而是 DI 链断在某一层：要么策略本身漏注册，要么它构造函数里某个参数（比如 IOptions<PaymentConfig>）没显式调用 AddOptions<PaymentConfig>()，或者生命周期冲突（Transient 策略注入了 Singleton 服务，而该 Singleton 又依赖 Scoped 服务）。

• 从报错策略类开始，逐个检查构造函数参数，确认每个类型都在 Program.cs 显式注册过
• 特别注意 IOptions<T>、IConfiguration、IHttpClientFactory 这些“看着像自带”的服务——它们全都要手动注册
• 加一行 var all = provider.GetServices<istrategy>().ToList();</istrategy> 打印已注册策略列表，一眼看出缺哪个实现类

策略最难的从来不是写几个类，而是划清边界：哪些该进策略、哪些该由上下文传入、哪些该交给装饰器或中间件兜底。一旦把日志、重试、缓存塞进策略实现里，你就已经走偏了。