specification接口必须是泛型的，因为需复用在不同实体上，ispecification的t决定作用域；非泛型会导致ef core无法推导表达式树类型而抛异常，且丧失命名即契约、可测试、可组合等核心价值。
Specification接口定义为什么必须是泛型的
因为规约要复用在不同实体上，ISpecification<t></t> 的泛型参数 T 决定了它能作用于哪个领域模型。如果写成非泛型（比如 ISpecification），你就没法在 Where(spec.ToExpression()) 里推导出表达式树的类型，EF Core 会报 InvalidOperationException: The LINQ expression could not be translated。
典型错误写法：
public interface ISpecification { Expression<func bool>> ToExpression(); }</func>
正确做法是强制泛型约束，并提供默认实现基类：
-
T必须是 class，避免值类型误用 - 加
where T : class约束，否则 EF Core 构建查询时可能抛NotSupportedException - 推荐继承
Specification<t></t>基类，统一处理And/Or组合逻辑，避免手写表达式拼接出错
And/Or组合时Expression如何安全合并
直接用 Expression.AndAlso 或 Expression.OrElse 会出问题：两个表达式参数名不一致（比如一个叫 x，另一个叫 y），EF Core 解析时报 ArgumentException: Parameter 'x' not found in expression。
必须统一参数名并重写表达式树：
- 用
ExpressionParameterReplacer类（自定义）把右侧表达式的参数替换成左侧的参数 - 不要手动 new ParameterExpression，而是复用左侧表达式的
Parameters[0] - EF Core 6+ 支持
ExpressionVisitor自动优化，但组合前仍需确保参数引用一致，否则spec1.And(spec2).ToExpression()生成的 SQL 可能漏条件
示例片段：
public static Expression<func bool>> AndAlso<t>(this Expression<func bool>> left, Expression<func bool>> right) { ... }</func></func></t></func>
Specification与EF Core查询配合时的性能陷阱
规约模式容易让人忽略「延迟执行」和「客户端求值」风险。一旦 ToExpression() 返回的表达式含无法翻译的操作（如 string.Contains 在非 SQL Server 的数据库），EF Core 会静默降级为客户端过滤，数据量大时直接 OOM。
关键检查点：
- 用
AsNoTracking()配合规约，避免无谓的变更跟踪开销 - 在开发环境开启
options.LogTo(Console.WriteLine)，确认生成的 SQL 是否含WHERE条件，而不是全表拉到内存再.Where() - 避免在规约中调用实例方法（如
user.IsActive()），EF Core 不认识，必走客户端求值 - 日期比较慎用
DateTime.Now—— 它会被当常量展开，但若规约被缓存复用，时间就“冻住”了；改用DateTime.UtcNow并确保表达式树里是DateTimeOffset.Now这类可翻译形式
为什么不能直接用LINQ方法链替代Specification
不是不能，而是维护成本陡增。当同一个查询条件出现在 OrderService、ReportService、AdminApi 三个地方，且每个都带不同组合（比如「未取消 + 创建时间 > 7天」、「未取消 + 有支付记录」），硬写 .Where(x => x.Status != Cancelled && x.CreatedAt > cutoff) 会导致三处重复、两处漏改、一处写错。
Specification 的实际价值在「命名即契约」：
-
ActiveOrderSpecification比x.Status == OrderStatus.Active更易懂、可测试、可复用 - 组合时语义清晰：
new ActiveOrderSpecification().And(new PaidOrderSpecification())直观反映业务意图 - 单元测试可针对单个规约验证，不用每次都构造完整 DbContext
但注意：别为了模式而模式。简单查询（如 ById）直接用 FindAsync(id)，比套一层 ByIdSpecification 更直接、更少抽象泄漏。
