不能靠GlobalFilter做百万级并发动态黑名单校验，应将其作为入口守门人，将匹配下沉至Caffeine+LongAdder+预编译正则的内存查表方案，并通过Nacos/Redis监听实现秒级热更新。
不能靠 GlobalFilter 做百万级并发的动态黑名单校验——它天生不适合做高吞吐、低延迟、强一致性的实时权限拦截。真正可行的方案是：用 GlobalFilter 做“入口守门人”，把黑名单匹配下沉到无锁、常数时间、支持热更新的数据结构中，比如 Caffeine + LongAdder 统计 + 正则预编译缓存，再配合 Nacos/Redis 的变更通知机制。
为什么直接在 GlobalFilter 里写正则匹配会崩
若依默认的 BlackListUrlFilter 把每个 blacklistUrl 字符串转成 Pattern.compile(url.replace("**", "(.*?)"))，这在 QPS 过万时就会暴露问题：
- 每次请求都调用
Pattern.compile()是严重浪费——正则编译开销大，且未复用； - 黑名单列表若达上千条，逐条
pattern.matcher(path).matches()是 O(n) 时间复杂度，CPU 必打满； - 配置变更需重启或手动刷新 Bean，无法支撑秒级生效的运营封禁需求；
-
GlobalFilter是响应式链中一环，阻塞式 IO（如查 Redis）会拖垮整个 WebFlux 线程池。
必须把黑名单匹配从“运行时计算”变成“内存查表”
核心思路：把黑白名单规则提前编译、分层索引、只保留最简匹配逻辑。例如：
- 将
/user/**拆为前缀树节点/user/，命中后才进正则分支； - 把
/order/\d{8}-\w{6}编译为Pattern实例并缓存在ConcurrentMap<String, Pattern>中，key 是原始字符串（避免重复编译）； - 用
Caffeine.newBuilder().maximumSize(1000).expireAfterWrite(10, TimeUnit.MINUTES)缓存匹配结果，对高频路径（如/health）实现微秒级响应； - 禁止在
filter方法内做任何redisTemplate.opsForSet().isMember()调用——改用启动时全量加载 + 监听 Nacos 配置变更事件异步刷新内存副本。
GlobalFilter 中真正该写的只有三行关键逻辑
一个生产可用的 BlacklistGlobalFilter 主体应极简，所有重活交给预热好的组件：
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
String path = exchange.getRequest().getURI().getPath();
if (blacklistMatcher.match(path)) { // ← 这个 match() 必须是无锁、O(1) 或 O(log n)
return ServletUtils.webFluxResponseWriter(exchange.getResponse(), "Forbidden");
}
return chain.filter(exchange);
}
-
blacklistMatcher是你自己实现的匹配器，内部封装了前缀 Trie + 正则 LRU 缓存 + 白名单快速放行逻辑； - 不要在
match()里做日志打印、指标埋点、HTTP 调用——这些全部抽到PostFilter或独立的Mono.defer()异步段； - 如果黑名单含 IP 维度（如
192.168.1.100/24），必须用IPSubnetFilter类库预构建SubnetUtils实例，而非每次 new； - 务必设置
Ordered.HIGHEST_PRECEDENCE + 100，确保它在 JWT 校验之前执行——否则非法路径可能绕过黑名单直抵鉴权环节。
最容易被忽略的一点：百万级场景下，GlobalFilter 本身不是瓶颈，Pattern 对象泄漏和 ConcurrentHashMap resize 才是雪崩起点。上线前必须用 JFR 录制 GC 和锁竞争，确认匹配器不产生新对象、不触发扩容、不持有外部引用。
