Collectors.partitioningBy本质是快速分类而非拦截，通过轻量Predicate将支付请求分为高风险/正常两组；需确保谓词无IO、纯内存计算，并配合业务逻辑阻断。
用 Collectors.partitioningBy 做实时反洗钱拦截，本质不是靠它“拦截”，而是快速分类识别风险请求，再配合业务逻辑做阻断。它本身不执行拦截动作，但能高效把支付请求按风险规则切分成“高风险/正常”两组，为后续决策提供结构化输入。
明确分区依据：定义可量化、低延迟的风险判断逻辑
分区谓词（Predicate）必须轻量、无副作用、不依赖外部IO。例如：
- 单笔金额 ≥ 5万元 → 高风险
- 同一用户10分钟内发起≥5笔支付 → 高风险（需结合本地缓存或Redis计数）
- 收款方为高风险名单中的IBAN或商户ID → 高风险（名单建议预加载到内存Set）
⚠️ 注意：避免在 predicate 中调用数据库或HTTP接口，否则会拖慢整个流处理链路，违背“实时”前提。
结合Stream流水线，在请求聚合阶段完成初筛
假设你已将一批待处理的支付请求封装为 List，可这样组织处理流：
Map<boolean list>> partitioned = requests.stream()
.filter(req -> req.getStatus() == PENDING) // 先剔除已处理项
.collect(Collectors.partitioningBy(req -> {
// 风险判定逻辑（纯内存计算）
boolean isHighRisk = req.getAmount().compareTo(BigDecimal.valueOf(50000)) >= 0
|| riskCounter.isFrequentPayer(req.getUserId(), Duration.ofMinutes(10), 5)
|| highRiskMerchants.contains(req.getPayeeId());
return isHighRisk;
}));
</boolean>
结果 partitioned.get(true) 即高风险请求列表，可立即触发人工审核、二次验证或直接拒绝；partitioned.get(false) 进入下游快速通道。
与风控引擎联动，避免重复计算
partitioningBy 适合做第一层粗筛。真实场景中建议：
- 把简单规则（金额、频次、黑名单）放在这里，毫秒级响应
- 复杂模型（如图神经网络识别团伙交易）交由异步风控服务处理，只传ID或特征摘要
- 对
true分区的请求，打上riskLevel: HIGH标签并写入审计日志，便于溯源
注意线程安全与状态一致性
若使用共享的 ConcurrentMap 或本地计数器（如 AtomicLong），需确保：
- 计数器 key 精确到用户+时间窗口（如
"user_123_20240520_14"） - 定时清理过期窗口（可用 ScheduledExecutorService 或 Caffeine 的 expireAfterWrite）
- 避免在 parallelStream 中修改共享状态 —— partitioningBy 本身线程安全，但谓词内部状态不安全
不复杂但容易忽略。
