前端不参与网关Token校验；网关需统一校验HTTP请求（通过Order=-100的GlobalFilter）和WebSocket请求（通过order=-2的局部过滤器），并透传用户上下文至下游服务。
前端本身不参与网关的 Token 校验逻辑。所谓“前端网关集中过滤器”“通道多态”并不是真实存在的技术概念——Spring Cloud Gateway 是服务端组件，运行在 Java 后端（如 Netty 线程上），前端（浏览器或 App）无法也不应“利用通道多态”去驱动或控制网关过滤器的执行方式。
真正需要做的，是在网关层设计一个统一、高效、可复用的校验机制，让所有进来的请求（HTTP 和 WebSocket）都能被一次性、可靠地完成 Token 验证。以下是关键落地要点：
网关统一校验所有 HTTP 请求的 Token
- 所有普通 HTTP 请求（含高并发请求）天然经过网关的 GlobalFilter 链，无需前端配合
- 自定义
TokenCheckFilter实现GlobalFilter和Ordered接口 -
getOrder()返回较小值（如-100），确保它在路由转发前最早执行 - 白名单路径（如
/login-service/doLogin）直接放行，避免登录接口被拦截 - 从
Authorization: Bearer xxx头中提取 token，用 Redis 做非阻塞校验（redisTemplate.hasKey(realToken)） - 校验失败时写入
401响应并调用response.setComplete()终止链路
WebSocket 请求必须单独处理，不能依赖 GlobalFilter
- WebSocket 握手请求（
ws://或wss://）会被WebsocketRoutingFilter（order = -1）直接接管，跳过所有 GlobalFilter - 必须定义一个继承
AbstractGatewayFilterFactory的局部过滤器（如AuthWebSocketFilter） - 在路由配置中显式绑定该过滤器，并设
order = -2，确保它在WebsocketRoutingFilter之前执行 - 推荐前端通过 query 参数传 token（如
ws://gateway/ws?token=xxx），因 Header 在握手阶段可能不可靠 - 校验失败立即设置
response.setStatusCode(401)并返回Mono.empty()，阻止连接升级
校验通过后务必透传用户上下文给下游服务
- 单纯校验只是第一步，下游微服务需要知道“谁在访问”
- 解析 JWT payload 获取
userId、roles等信息（如AppJwtUtil.getClaimsBody(token)） - 构造新请求头：
ServerHttpRequest mutatedRequest = request.mutate() .header("X-User-Id", userId) .header("X-User-Roles", roles) .build(); - 调用
exchange.mutate().request(mutatedRequest).build()继续过滤器链
不复杂但容易忽略：校验不是终点，透传上下文才是微服务间可信通信的基础。
