Collectors.partitioningBy仅支持二元分组，适用于高/低风险切分；多级分类需结合谓词与groupingBy等协同实现，且须预聚合指标、外置规则、保障并发安全。
用 Collectors.partitioningBy 对海量交易变量做实时风险等级分类，本质不是“二分”，而是借其布尔分组能力，快速切出高/低风险两个桶；真正支撑多级（如高/中/低）或动态阈值的，需配合自定义谓词与外部策略协同，而非仅靠 partitioningBy 本身。
明确 partitioningBy 的定位：只支持二元逻辑切分
它返回 Map<boolean list>></boolean>，天然只能分两组。想实现“高风险/中风险/低风险”三级，不能直接嵌套或堆叠 partitioningBy——那样会导致代码臃肿、逻辑耦合、难以维护。正确做法是：
- 用一个清晰的谓词（Predicate）定义“是否属于高风险”，例如：
tx -> tx.getAmount() > 1_000_000 || tx.getVelocity() > 50 - 调用
partitioningBy(predicate)得到{true=[高风险交易], false=[其余交易]} - 再对
false分支的子集做二次分类（比如用 groupingBy + 自定义 RiskLevel 枚举），避免强行塞进 partitioningBy
应对海量数据：别在流里做重计算，提前物化关键指标
实时场景下，每笔交易的 getAmount()、getVelocity() 等字段若需实时聚合（如“过去5分钟该用户交易次数”），绝不能在 partitioningBy 的谓词中现场查库或调远程接口——这会成为性能瓶颈。应：
- 在交易进入处理流水线前，由 Flink / Kafka Streams 或 Redis Sorted Set 预聚合好衍生指标，写入轻量上下文对象（如
EnrichedTransaction） - 谓词只读内存字段：
tx.getPrecomputedRiskScore() >= 80，确保判断在微秒级完成 - 必要时用
partitioningBy+ConcurrentHashMap缓存近期用户风险快照，避免重复评估
与业务策略解耦：把风险规则外置为可热更新的 Predicate
硬编码谓词会让风控策略变更必须发版。更合理的方式是：
- 定义接口
RiskPredicate extends Predicate<transaction></transaction> - 实现类从配置中心（如 Apollo、Nacos）加载规则表达式，用 Aviator 或 Spring Expression 解析成运行时谓词
- 将该谓词实例传入
Collectors.partitioningBy(predicate)，做到不重启更新阈值和组合条件 - 示例配置：
amount > 500000 && (channel == 'third_party' || ipCountry == 'high_fraud_region')
注意并发安全与下游消费模式
partitioningBy 默认使用 HashMap，在并行流（parallelStream()）中可能引发竞争。实际生产建议：
- 显式指定并发收集器：
Collectors.partitioningBy(predicate, Collectors.toConcurrentMap(...))（需 JDK 12+） - 或更稳妥：先用
parallelStream().map(...).collect(Collectors.toList())汇总原始数据，再单线程 partitioningBy —— 对于毫秒级延迟可接受的风控场景，反而更可控 - 分组后不要直接在 Map 上做耗时操作（如写 DB），应转成
Stream.of(map.values())异步分发至不同处理管道
