predicate用于动态筛选可参与满减的商品子集，需先按作用域（如门店、品类）分组，再逐层构造精准谓词判断资格，而非直接剔除商品；其本质是声明“准入资格”，后续再汇总计算是否达标。
用 Predicate 剔除不满足满减门槛的商品，关键不是“删商品”，而是**按规则动态筛选可参与优惠的子集**——尤其在多层购物车（比如：主订单 → 多个子订单/门店/配送单元）中，需先明确满减作用域（全场？某门店？某品类？），再逐层构造精准谓词。
明确满减的作用层级和条件
满减通常不全局生效。例如：
- “满 300 减 30”仅适用于 A 门店下的商品
- “指定品类满 200 减 20”，且该品类只包含 SKU 开头为
BOOK-的商品 - 跨店合并结算时，满减按“每店独立计算”，不能混加
→ 必须先将购物车按作用域分组（如按 storeId 或 categoryTag），再对每组单独应用 Predicate 判断是否达标，而非对整个扁平商品列表一刀切过滤。
用 Predicate 表达“可参与满减”的资格逻辑
不要写 “剔除不满足的商品”，而应定义 “哪些商品有资格进入满减计算池”。例如：
// 示例：A 门店满 300 减 30，仅限自营商品且未下架
Predicate<cartitem> isEligibleForStoreA = item ->
"A".equals(item.getStoreId()) &&
"SELF".equals(item.getSupplyType()) &&
!item.isDeleted() &&
item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())).compareTo(BigDecimal.valueOf(300)) >= 0;
</cartitem>
⚠️ 注意：这里 item.getPrice().multiply(...).compareTo(300) >= 0 是常见误区——满减门槛是**整组商品合计金额**，不是单个商品。真正该用 Predicate 做的是：筛选出本组内所有可能参与计算的商品（即：满足基础资格），后续再对这组做 sum 汇总判断是否达标。
分层过滤 + 条件聚合，避免误剔
典型多层结构：一个结算单（Checkout）含多个 ShopCart（每店一个），每个 ShopCart 含多个 CartItem。正确流程是：
- 对每个
ShopCart，先用 Predicate 筛出“本店合格商品子集”（如上例） - 对该子集求和：
eligibleItems.stream().mapToDouble(i -> i.getAmount()).sum() - 若和 ≥ 门槛，则保留全部 eligibleItems 参与优惠；否则，该 ShopCart 不触发满减 → 所有商品都“不享受”，但**仍保留在购物车中用于支付（只是不减）**
→ Predicate 在这里只做“准入资格初筛”，不是“最终剔除指令”。结算结果页仍显示全部商品，仅优惠栏注明“未达门槛，不减免”。
警惕 BigDecimal 和 null 安全陷阱
购物车金额常用 BigDecimal，Predicate 中必须显式处理 null 和精度：
Predicate<cartitem> nonNullPrice = item -> item.getPrice() != null;
Predicate<cartitem> validAmount = item ->
item.getPrice() != null &&
item.getQuantity() > 0 &&
item.getPrice().compareTo(BigDecimal.ZERO) > 0;
// 组合使用（推荐用 and() 链式调用）
Predicate<cartitem> safeEligible = nonNullPrice.and(validAmount).and(...);
</cartitem></cartitem></cartitem>
Java 8+ 中，Predicate.and()/or()/negate() 支持函数式组合，比手写 && 更易读、可复用、便于单元测试。
本质上，Predicate 是声明“什么能进池子”，不是执行“删什么”。多层结算中，先分域、再筛资格、后算总额、最后决定是否启用优惠——把剔除动作留给业务逻辑层，Predicate 只负责干净、可测、可组合的资格断言。
