Collectors.partitioningBy 用于内存中轻量级黑名单预筛，通过分组快速分离拦截与放行请求；需配合显式拦截动作（如抛异常、记日志），不替代网关或风控系统。
用
实现支付请求的实时
黑名单
拦截，本质不是靠它“拦截”，而是借助其分组能力快速分离出需拦截的请求——它适合在内存中做轻量、低延迟的预筛，不能替代网关或风控系统的持久化拦截逻辑。
明确适用场景：内存级实时预判
该方法适用于以下情况：
黑名单数据已加载到 JVM 内存（如通过定时同步 Redis 或数据库）
单次请求携带多个支付变量（如一批订单号、卡号、设备 ID），需批量判断是否命中黑名单
要求毫秒级响应，不希望每次请求都查一次远程存储
黑名单规模适中（几万以内），避免
查找退化
核心写法：用 partitioningBy 分离“放行”与“拦截”子集
假设你收到一批支付请求参数
，每个含字段
，而黑名单是
：
注意：
返回的是
，
对应匹配谓词的元素，即“需拦截”的请求。
增强实用性：支持多维变量 + 懒加载 + 线程安全
真实支付请求常含多个可黑名单字段（如
、
、
），建议封装判断逻辑：
关键细节：
黑名单集合推荐用
或
，避免并发修改异常
若黑名单更新频繁，可用
或双缓冲机制（如读取时用旧副本，后台异步刷新新副本）
不建议在流中调用远程接口（如查 Redis），会阻塞并失去并行优势
和真正拦截动作的衔接
分组只是第一步。后续需：
对
列表统一记录审计日志（含时间、请求ID、命中字段）
抛出特定异常（如
）或返回标准错误码（如
）
对
列表继续走下游流程（风控规则、渠道路由等）
可选：将拦截结果异步上报至监控系统，用于动态调整黑名单策略
不复杂但容易忽略：partitioningBy 本身不带副作用，拦截动作必须显式编码实现，它只负责“分得清”。
Collectors.partitioningByHashSet::containsListcardNoSet blackCardNos Map> partitioned = requests.stream()
.collect(Collectors.partitioningBy(req -> blackCardNos.contains(req.getCardNo())));
List blocked = partitioned.get(true); // 命中黑名单
List allowed = partitioned.get(false); // 放行
partitioningByMap> trueuserIdipdeviceIdSet blackUsers = ...;
Set blackIps = ...;
Set blackDevices = ...;
Predicate isBlocked = req ->
blackUsers.contains(req.getUserId()) ||
blackIps.contains(req.getIp()) ||
blackDevices.contains(req.getDeviceId());
Map> result = requests.stream()
.collect(Collectors.partitioningBy(isBlocked));
ConcurrentHashMap.newKeySet()Collections.unmodifiableSet(...)CopyOnWriteArraySetblockedBlacklistRejectedException403 PAYMENT_BLOCKEDallowed