企业官网建设流程全解析

先说结论：这个问题十有八九不是 Spring AI Alibaba 或者 Spring Security 本身“坏了”，而是两者在请求生命周期里对“上下文”和“响应流”的假设不一样。一个只顾着把令牌校验塞进 FilterChain，一个只顾着把对话内容以 SSE 流式吐给前端，两边各干各的，拼在一起就撞车了。

我自己接这种项目时，第一反应从来不是去搜“兼容性补丁”，而是先理清一条请求从进来、过认证、进 Controller、异步流式返回，这一路上 SecurityContext 和响应流分别经历了什么。只要把这两个东西的走向搞明白了，解决办法基本就是“给它们各修一条道”的事。

这篇文章会把完整的排查思路、方案设计和可运行的代码骨架都写出来。适合正在用 Spring AI Alibaba（尤其是通义千问这类流式对话场景）同时又接入了 Spring Security 的团队参考，也适合那些刚把两个 starter 放进 pom.xml、一启动就发现 AI 接口全部异常的朋友。

1. 问题定位：两种框架在认证链路上的“碰撞点”

1.1 冲突现象与复现路径

先说现象。我遇到的最典型场景是这样的：项目里用了spring-ai-alibaba-starter，Controller 里返回Flux<String>或者SseEmitter，前端用 fetch 或者 EventSource 接收打字机效果。Spring Security 这边是标准 JWT 无状态方案：自定义 OncePerRequestFilter 解析 token，SecurityContextHolder里放认证对象，SecurityFilterChain里配置路径权限。

然后问题集中在两个阶段出现。

第一个阶段是“接口直接 401”。几乎所有 AI 对话接口都在/api/ai/**下面，SecurityConfig 里虽然写了.requestMatchers("/api/ai/**").authenticated()，但测试时发现请求进去了，响应却变成了 401，而且这个 401 还不是过滤器返回的，是响应已经往回写了一半才冒出来的。前端拿到的是一段残缺的 SSE 数据，解析必然失败。

第二个阶段是“登录成功但拿不到用户信息”。业务代码里明明在 Service 层调用了SecurityContextHolder.getContext().getAuthentication()，在普通接口里一切正常，一放到流式对话接口里就变成 null，或者拿到的是另一个线程的上下文，造成用户身份错乱。这个更隐蔽，通常线上偶现，压测的时候尤其明显。

我当时复现路径非常简单：写一个最小工程，pom 里加上spring-boot-starter-security和spring-ai-alibaba-starter，配置一个@GetMapping(produces = "text/event-stream")的接口，方法里直接chatClient.stream(prompt)，然后浏览器访问。十次里有七八次是 SSE 还没开始推，认证链就先动手了。

1.2 冲突的根源：FilterChain、异步线程与响应流

要理解冲突，得先把 Spring Security 的请求生命周期吃透。Spring Security 通过 FilterChainProxy 管理一条过滤器链，请求进入后被一系列 Filter 处理，比如SecurityContextHolderFilter（或老的SecurityContextPersistenceFilter）、CsrfFilter、UsernamePasswordAuthenticationFilter、ExceptionTranslationFilter等。每个 Filter 做的事情本质上围绕一个东西：SecurityContext。

问题在于 SecurityContext 默认是和当前线程绑定的。SecurityContextHolder默认使用ThreadLocal策略，子线程默认不会继承父线程的上下文。而 Spring AI Alibaba 的流式对话接口，底层是 WebFlux 的Flux或者异步任务执行器，响应返回往往是异步的，甚至可能跨线程调度。一旦认证信息在子线程里找不到了，就等于用户身份丢了。

更麻烦的是响应流。SSE 的本质是“HTTP 响应不关闭，数据分块持续推送”。但 Spring Security 的某些过滤器（比如HeaderWriterFilter、CsrfFilter、甚至自定义的响应包装器）可能在整个请求处理完之前对 response 做包装或者缓冲。如果某个过滤器在异步请求返回后的回调阶段再次介入，就可能把已经承诺给前端的text/event-stream响应破坏掉。最典型的表现就是：Flux 的数据确实产生了，但响应头已经被改写了，或者数据被缓冲到内存里，前端收不到“逐字”效果，等连接关闭才一次性拿到内容。

我在一篇官方 issue 里看到过类似的描述——异步分发时，Spring Security 的 filterChain 会在ASYNCdispatch 类型下再次执行。如果你的 SecurityConfig 没有显式处理shouldNotFilter或者对 async dispatch 做特殊处理，某些 filter 可能会二次介入，造成上下文重置或响应头冲突。这个就是很多诡异 401 的根本来源。

还有个隐蔽点：spring-ai-alibaba的客户端在启动时会注册一些 Actuator 端点或者内部健康检查路径，如果这些路径被 SecurityConfig 误伤，可能导致应用启动时构建模型对象失败，间接造成运行时异常。别笑，我至少见过两个团队把/actuator/**忘了放行，结果 AI 客户端初始化异常，报的却是认证错误。

1.3 快速诊断：五分钟确认冲突类型

遇到问题先别急着改代码，我建议按下面这个顺序做快速诊断。

第一步，看请求日志。在 SecurityConfig 里临时开启 debug 日志，观察 filter chain 的执行顺序，确认请求是否被多次分发、是否有 filter 在 async dispatch 阶段二次执行。重点看日志里有没有Securing POST /api/ai/chat/stream这种行，以及它出现了几次。

第二步，在 Controller 方法入口临时打印SecurityContextHolder.getContext()和当前线程名。再在Flux的doOnNext里也打印一次线程名和上下文。对比两次输出的线程 ID 和认证对象是否一致。如果线程变了、上下文空了，就是线程传递问题。

第三步，用 curl 直接测原始 SSE 行为，绕开前端：

curl -N -H "Authorization: Bearer <token>" http://localhost:8080/api/ai/chat/stream?prompt=你好

如果 curl 能看到流式输出但前端不行，那问题出在前端 EventSource 无法自定义 Header 上；如果 curl 直接 401 或响应卡死，那是后端 filter 链的问题。

这三步做完，基本能把问题归类成三种：认证上下文丢失、过滤器二次介入、SSE 响应被缓冲/改写。下面的方案就是分别针对这三种情况的。

2. 核心方案设计：认证前移，流式旁路

2.1 设计思路：不要和高层框架对抗

我处理这类冲突的原则很简单：不要试图让 Spring Security 去“理解”SSE 流式输出，而是把认证尽量前移，让 AI 对话接口在自己的隔离跑道里运行。

具体来说，一个请求进入系统后，认证动作应该尽量发生在早期，在进入业务方法前就完成。认证结果以某种稳定的方式传导，而不要依赖“当前线程里恰好有 SecurityContext”这种脆弱假设。对于流式接口来说，更合理的做法是：在 Controller 入口拿到认证信息，构造一个包含用户信息的对象，显式传给流式处理链路。

这样做的好处有三个：第一，认证逻辑可以复用；第二，流式处理代码不依赖 ThreadLocal，天然可测试；第三，避免了异步线程切换导致的上下文丢失问题——因为我们根本不传 SecurityContext，我们传业务需要的用户 ID 或用户对象。

网上很多文章推荐“用TaskDecorator包装线程池，把 SecurityContext 传到子线程”，这个方案确实能解决一部分问题，但它有一个隐患：你把整个 SecurityContext（包括权限、角色、令牌）都带进了异步链路。如果异步链路里还有嵌套的并行任务，或者有第三方回调，SecurityContext 的范围就不可控了。我个人的偏好是：Controller 层把Authentication转换成轻量的用户信息对象（比如ChatUser），然后作为参数传下去。只在极少数必须依赖SecurityContextHolder的第三方库内部逻辑中，才考虑线程装饰器方案。

2.2 令牌解析与上下文传递的关键设计

先说令牌解析。如果你用的是 JWT，那么认证过滤器的核心工作就是三件事：从请求头或参数里取 token、验证签名和有效期、把解析结果塞进 SecurityContext。

这里有一个容易被忽略的坑：流式接口的text/event-stream请求，前端 EventSource 是没法自定义 Header 的。所以前端如果用原生的EventSource，token 就只能放在 query string 里，比如?token=xxx。这会导致两个问题：token 出现在访问日志里、token 可能被浏览器或者代理缓存。所以我通常建议前端改用 fetch + ReadableStream 来接收 SSE，这样可以把 token 正常放在 Authorization 头里。如果项目里已经有现成的 SSE 前端库，也优先选支持自定义 Header 的。

过滤器解析 token 后，注意SecurityContextHolder的策略选择。默认的MODE_THREADLOCAL在异步场景下不够用，但我也不是特别推荐直接改成MODE_INHERITABLETHREADLOCAL，因为 Spring 官方明确说明继承 ThreadLocal 在某些线程池复用场景下会导致上下文污染。更推荐的做法是：在使用@Async或自定义线程池的地方，配置一个TaskDecorator，把当前线程的 SecurityContext 拷贝给执行线程，任务结束后再清理。

@Bean("aiTaskExecutor") public Executor aiTaskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(4); executor.setMaxPoolSize(8); executor.setQueueCapacity(100); executor.setThreadNamePrefix("ai-chat-"); executor.setTaskDecorator(new SecurityContextTaskDecorator()); executor.initialize(); return executor; }

SecurityContextTaskDecorator的实现其实很简单：

public class SecurityContextTaskDecorator implements TaskDecorator { @Override public Runnable decorate(Runnable runnable) { SecurityContext context = SecurityContextHolder.getContext(); return () -> { try { SecurityContextHolder.setContext(context); runnable.run(); } finally { SecurityContextHolder.clearContext(); } }; } }

这里有一个容易被忽略的细节：clearContext()不能省。如果线程池里的线程被复用，上一个任务的上下文会残留在线程里，下一个任务如果恰好没设置新的上下文，就会拿到一个过期的认证信息，这在多租户或者用户切换的场景下就是严重事故。我见过一次线上 bug，用户 A 的对话里出现了用户 B 的上下文，就是因为装饰器只设置了上下文、没有清理。

2.3 路由拆分：给 AI 接口单独的认证入口

很多团队习惯把所有接口放在一个大 SecurityConfig 里管理，AI 对话接口也混在里面。一旦随着版块增加，配置越来越乱。我建议在架构层面做一次“按模块切分安全链”：主安全链负责/api/**的常规接口，AI 模块单独定义一条安全链，挂在/ai/**或者/api/ai/**上。

这么做的好处非常明显：AI 接口的异常处理、超时配置、放行规则都可以独立维护，不会因为主安全链加了一个全局过滤器而让流式接口遭殃。Spring Security 允许在一个应用里配置多条SecurityFilterChain，优先级通过@Order控制。

@Configuration @EnableWebSecurity public class SecurityConfig { @Bean @Order(1) public SecurityFilterChain aiSecurityFilterChain(HttpSecurity http) throws Exception { http .securityMatcher("/api/ai/**") .csrf(csrf -> csrf.disable()) .sessionManagement(sm -> sm.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .authorizeHttpRequests(auth -> auth .requestMatchers("/api/ai/**").authenticated() ) .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); return http.build(); } @Bean @Order(2) public SecurityFilterChain mainSecurityFilterChain(HttpSecurity http) throws Exception { http .csrf(csrf -> csrf.disable()) .sessionManagement(sm -> sm.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .authorizeHttpRequests(auth -> auth .requestMatchers("/api/auth/login", "/actuator/health").permitAll() .anyRequest().authenticated() ) .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); return http.build(); } }

注意一点：两条链里的addFilterBefore必须各自添加，因为请求只会命中其中一条链。如果你只配在主链里加了 JWT 过滤器，AI 链里没加，那 AI 链里虽然有.authenticated()，但根本没有人给它设置认证对象，结果同样会 401。

3. 实操落地：Spring AI Alibaba 流式接口的无缝对接

3.1 自定义认证过滤器实现

我用的是最标准的 JWT 方案：登录时发 token，请求进来时由过滤器校验。这里贴一份可以直接改用的过滤器骨架。

@Component public class JwtAuthenticationFilter extends OncePerRequestFilter { private final JwtTokenParser tokenParser; public JwtAuthenticationFilter(JwtTokenParser tokenParser) { this.tokenParser = tokenParser; } @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String token = resolveToken(request); if (StringUtils.hasText(token) && SecurityContextHolder.getContext().getAuthentication() == null) { try { Authentication authentication = tokenParser.parse(token); if (authentication != null) { SecurityContext context = SecurityContextHolder.createEmptyContext(); context.setAuthentication(authentication); SecurityContextHolder.setContext(context); } } catch (Exception ex) { // 解析失败不在这里抛异常, 留给后面的认证入口处理, 避免流式响应被中途截断 SecurityContextHolder.clearContext(); } } chain.doFilter(request, response); } private String resolveToken(HttpServletRequest request) { String bearer = request.getHeader("Authorization"); if (StringUtils.hasText(bearer) && bearer.startsWith("Bearer ")) { return bearer.substring(7); } return request.getParameter("token"); } }

这里一个核心设计决策是：token 解析失败的异常不要在这个过滤器里直接写 401，而是继续往下走。为什么？因为如果是 SSE 请求，response 可能已经以text/event-stream开始了，这时候再去sendError(401)会造成响应头混乱、前端拿到残缺数据。更好的做法是：让请求进入 Controller，由流式接口统一以 SSE 事件格式返回错误。比如返回一个ServerSentEvent的 error 事件：

ServerSentEvent.builder("认证失败") .event("error") .build()

前端监听 error 事件就能统一处理，不会出现“连接莫名其妙断开”的情况。

3.2 流式接口中安全上下文的透传方案

现在进入核心：Spring AI Alibaba 的流式调用怎么拿到用户身份。

先说你最可能遇到的问题场景。Controller 方法长这样：

@GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux<ServerSentEvent<String>> stream(@RequestParam String prompt) { Authentication auth = SecurityContextHolder.getContext().getAuthentication(); String userId = auth.getName(); return chatClient.stream(prompt) .map(content -> ServerSentEvent.builder(content).build()); }

这种写法在阻塞接口里没任何问题，但在流式场景下，Flux是惰性的，订阅发生在 Spring 框架内部，而且很可能发生在另一个线程上。SecurityContextHolder.getContext()那行是在主线程执行的，结果确实拿到了 auth，但如果chatClient.stream()内部切换了线程，Flux链路上的map、doOnNext等操作符运行时，访问SecurityContextHolder就可能拿到空上下文。

解决方法有两个，我按推荐优先级说。

第一个方法是“捕获前置”：在主线程把认证信息捕获到一个局部变量，然后在流式链路的操作符里使用这个变量，不要再去SecurityContextHolder里取。这最干净，也最容易理解。

@GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux<ServerSentEvent<String>> stream(@RequestParam String prompt) { String userId = SecurityContextHolder.getContext().getAuthentication().getName(); String model = ...; // 可以按用户维度选模型 return chatClient.stream(prompt) .map(content -> ServerSentEvent.builder(content) .id(userId) .build()); }

第二个方法是“订阅前恢复上下文”：在Flux的doOnSubscribe里把 SecurityContext 设置到订阅线程。这个方案适合那些没法修改内部逻辑、必须依赖SecurityContextHolder的第三方组件。

@GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux<ServerSentEvent<String>> stream(@RequestParam String prompt) { SecurityContext context = SecurityContextHolder.getContext(); return chatClient.stream(prompt) .doOnSubscribe(s -> SecurityContextHolder.setContext(context)) .map(content -> ServerSentEvent.builder(content).build()) .doFinally(signal -> SecurityContextHolder.clearContext()); }

第二方案需要谨慎：doOnSubscribe里设置的上下文会在线程池线程里残留，如果这个线程之后被复用于其他请求，就出问题了。所以必须配合doFinally清理。这也再次说明，第一方案更可控。

3.3 SSE 流式响应的正确配置

SSE 有几个和认证、响应流相关的配置细节很容易踩坑。

一个是 HTTP 响应头的显式设置。Spring AI Alibaba 的chatClient.stream()返回的 Flux 在输出时，Spring 会把它包装成 SSE 响应，但如果你用SseEmitter而不是直接返回 Flux，需要对SseEmitter设置response.getOutputStream().setWriteListener或者setAsyncTimeout。我更推荐直接用Flux<ServerSentEvent<T>>的返回方式，让 Spring 去管理 SSE 封装，少很多手写样板。

另一个关键是禁用可能出问题的过滤器。在无状态 JWT 项目中，CsrfFilter通常是要禁用的，因为 SPA 不存在 CSRF 的风险，而开启 CSRF 后，POST 类接口没有 token 会被 403。流式对话接口如果用 POST 方式（prompt 较长时 GET 有 URL 长度限制），CSRF 必须关闭，否则前端请求直接失败。这一条看似简单，但很多人排查半天没发现是 CSRF 在拦。

第三个是关于超时的设置。SSE 长连接如果长时间没有数据，前端浏览器或者代理服务器会断开连接。Spring AI Alibaba 的流式输出一般是持续的文字片断，但如果用户问了一个需要思考很久的问题（比如查询数据库），中间可能有几秒空白，这时候需要在 SSE 里周期性地发送注释行，比如: keep-alive\n\n，保持连接活跃。Spring 的Flux.interval(Duration.ofSeconds(15)).map(i -> ServerSentEvent.builder().comment("keepalive").build())可以做到，也可以用一个mergeWith把心跳事件并进去。

4. 常见问题与排查实录

4.1 “流式输出被认证链截断”：过滤器二次介入之谜

这个问题我帮两个项目排查过，现象都是：本地接口测试时正常，部署到测试环境后，前端收到的 SSE 数据在推送一段时间后突然中断，而且中断时间不确定。

排查过程特别有意思。反复看日志后，发现一个规律：中断恰好发生在请求进入 ASYNC dispatch 的时候。具体来说，Spring MVC 在处理异步请求时，会发起第二次 dispatch，把请求再次交给 filter chain。这个时候，OncePerRequestFilter因为有alreadyFilteredAttribute的保护不会重复执行，但如果你在配置里用了自定义的Filter（不是继承 OncePerRequestFilter），或者用了某些原生的javax.servlet.Filter，它会在第二次 dispatch 时再次介入。如果这个过滤器对 response 做了getOutputStream()或者getWriter()的调用，就和 SSE 的流式推送冲突了。

解决办法也简单：自定义 Filter 时，一律继承OncePerRequestFilter，并且在shouldNotFilter里排除掉 async dispatch：

@Override protected boolean shouldNotFilter(HttpServletRequest request) { return request.isAsyncStarted() || request.getDispatcherType() == DispatcherType.ASYNC; }

这个坑的隐蔽性在于：它只在异步请求里出现，常规接口完全正常，很容易被误认为“Spring Security 配置问题”.

4.2 “异步线程中 SecurityContext 丢失”：线程池复用引起的幻觉

还有一次，问题出在@Async注解上。业务代码里有一个服务类，用@Async("aiTaskExecutor")在单独的线程池里调用 AI 流式对话，界面上的表现是时好时坏。好一会儿、坏一会儿，毫无规律。

后来查明白原因了：默认情况下，@Async调用时SecurityContextHolder的 ThreadLocal 不会传递到异步线程，所以异步线程里SecurityContextHolder.getContext().getAuthentication()返回 null。为什么“时好时坏”？因为某些请求恰好没有被 Spring 丢到新线程处理（比如线程池队列满了，走的是调用线程直接执行），所以偶尔正常。一旦频率上来，线程池活跃，所有异步调用里的上下文就全丢了。

修复方案有两种。第一种是在自定义线程池时配置上面说过的TaskDecorator；第二种是更简单粗暴——不要在线程内部依赖SecurityContextHolder，在进入异步方法之前就把认证信息取出来作为参数传进去。

@Async("aiTaskExecutor") public void processAsync(String userId, String prompt) { // 这里不再读取 SecurityContextHolder，直接使用 userId 参数 }

我个人长期用第二种，代码更直白，也更容易测试。

4.3 “响应流缓冲导致假死”：SSE 退化成一次性响应

最后还有一个特别迷惑人的问题：前端的表现是“打字机效果完全没了，等全部内容生成完才一次性显示”。乍一看像是 AI 接口不支持流式，实际是响应被缓冲了。

排查方法很直接：在浏览器 Network 面板里看响应是否被 “暂缓”（Pending）很长时间，最后一次性返回。如果是，那就说明中间某个环节开了缓冲。最常见的缓冲点有：Nginx 的proxy_buffering默认开启，会对 SSE 响应做缓冲；或者 Spring Security 的SecurityContextHolderFilter无关，但某些 Response 包装器（比如ContentCachingResponseWrapper）会把整个响应缓存下来。

解决方法：

• Nginx 层：proxy_buffering off;或者在 location 里设置add_header X-Accel-Buffering no;
• Spring 层：检查是否有全局的 ResponseBodyAdvice，是否对text/event-stream也做了包装；如果有，排除掉它

很多团队把这个问题归咎于“Spring AI Alibaba 不支持流式”，实际上就是代理层缓冲。我建议在排查顺序里把“代理缓冲”放在很靠前的位置，因为它连认证都无关，最容易被忽略。

5. 路径放行与性能平衡的进一步优化

5.1 从“全链路认证”到“只认证关键入口”

很多项目在整合 Spring Security 之后，陷入了一个误区：把所有接口都纳入认证，甚至把静态资源、健康检查、接口文档也拦住。这样表面上很安全，实际上增加了大量的过滤器计算开销，对流式接口尤其不友好。

我建议做一次“分层放行”的设计。对于/actuator/health、/v3/api-docs/**、/swagger-ui/**这类基础设施路径，直接放行；对于 AI 对话接口，保留认证，但把认证的重点放在“令牌是否有效、用户是否可用”上，而不是在授权层反复查数据库。权限往往在进入业务方法后用注解控制（比如@PreAuthorize），而不是在每个请求上全局拦截。

这样一方面减少了过滤器链的长度，另一方面也让流式接口的 TTFB（首字延迟）明显降低。我实测过一个接口，精简过滤器链后，SSE 首包时间从几百毫秒降到了几十毫秒——在打字机体验里，这个差距是肉眼可见的。

5.2 令牌过期与流式长连接的拉锯战

流式长连接和短期 token 天然有矛盾。JWT 的过期时间通常很短（15 分钟到 2 小时），但一个 SSE 流式对话可能持续几分钟甚至更久。如果系统在连接建立后不再检查 token，那 token 过期也影响不大；但如果业务里有个过滤器在每个数据块写入时都重新校验 token，那长连接就会突然中断。

我的建议是：连接建立时做一次严格认证；连接建立后的持续推送阶段，不再重复校验 token。这符合 HTTP 的长连接语义，也避免了不必要的 CPU 开销。如果确实担心用户被踢下线后连接还挂着，可以在底层维护“连接和用户 ID”的映射关系，在账号异常时主动关闭对应该用户的连接，而不是靠 token 校验来解决。

这里还涉及一个细节：如果前端需要自动刷新 token，千万别在 SSE 请求过程中刷新。因为 SSE 请求在建立后，header 不会更新。你刷新了 token，当前连接使用的还是旧 token。正确做法是让前端在建立连接前确保 token 还有足够长的有效期，或者后端在连接内周期性下发一个“token 即将过期”的信号，前端收到后主动断线重连，用新 token 建立新连接。

5.3 缓存和限流的兜底机制

AI 对话接口还有一个被忽视的性能点：认证信息的解析是很贵的。JWT 验签涉及 RSA/ECDSA 非对称解密，每个请求都验签，加上流量大，CPU 会吃不消。尤其流式接口本身还有 TTFB 要求，验签开销会直接影响体验。

可以引入一个轻量缓存，把“token 签名 → 用户ID/权限集合”的解析结果缓存一小段时间，甚至放在 Caffeine 里。注意这里不要缓存整个 token 字符串，只缓存解析后的认证结果，并且要设置合理的过期时间。比如签名算法是 RS256，验签结果可以缓存 60 秒左右，基本不影响安全，但能减少大量 CPU 开销。

限流也是必须的。流式对话接口很贵，一个用户一次提问可能消耗几十甚至上百令牌。如果被恶意刷，后端成本直接失控。限流可以在网关层做，也可以结合 Spring Security 的过滤器做，按用户维度限制 QPS。我建议至少做两层：网关层做 IP 维度限流；应用层做用户维度限流。流式接口的限流不要只统计请求次数，还要统计“请求持续时间”，因为一个长时间挂着的 SSE 连接占用的资源比十个普通请求还高。

最后再分享一个基于真实项目经验的判断标准：当你发现 Spring AI Alibaba 和 Spring Security 整合后出现诡异问题时，先怀疑“请求生命周期内的上下文丢失”，再怀疑“响应流被中间层缓冲”，然后怀疑“filter 在 async dispatch 阶段二次执行”，这三个方向都能排查到具体证据。不要一上来就搜“停止更新”、“兼容补丁”之类的问题——这个框架的版本迭代一直很快，API 在不同版本之间也有变动，建议直接锁定你项目里的具体版本号，以官方仓库当前分支的示例代码为准。锁定版本、读源码、做隔离验证，这三步比任何“灵丹妙药”都靠谱。