文章目录
- 1. 核心原因：Filter 的“套娃（洋葱圈）”执行模型
- 2. 为什么不能（也无法）在这里用 `afterCompletion`？
- 维度一：Filter 拿不到 `afterCompletion`
- 维度二：生命周期顺序的致命冲突
- 总结
这是一个非常棒且极其敏锐的问题！
你之所以会想到afterCompletion，说明你对 Spring 的拦截器（Interceptor）机制非常熟悉。在拦截器的生命周期里，afterCompletion确实是公认用来清理 ThreadLocal 的黄金位置（因为哪怕后续视图渲染报错，它也一定会执行）。
但是，你当前写的这段代码是一个过滤器（Filter），它和拦截器有着本质的外层与内层、核心控制权的区别。
在 Filter 的世界里，**没有afterCompletion这种现成的生命周期钩子，finally块就是它的afterCompletion**。
1. 核心原因：Filter 的“套娃（洋葱圈）”执行模型
Java Web 的 Filter 采用的是责任链模式。当代码执行到chain.doFilter(request, response)时，它并不是“把请求发出去了”，而是像套娃一样，把控制权交给了下一个 Filter，直到最后交给 Spring 容器（DispatcherServlet）、拦截器、以及你的 Controller。
你可以把chain.doFilter这一行代码，看作是一个包裹了整个后续请求处理流程的巨大方法。
try{// 1. 请求进来了：这里是 Controller 执行【之前】// 2. 核心大戏：执行链向下传递（经历其他 Filter -> 拦截器 -> Controller -> 返回响应）chain.doFilter(request,response);}finally{// 3. 请求要离开了：整个业务（包括 Controller、拦截器）全部执行【完毕后】，才会走到这里LoginUserContextHolder.remove();}由于finally的特性是无论前面发生任何事情（正常结束或抛出致命异常），都铁定会执行。所以，当整个 Tomcat/Jetty 线程处理完所有的业务准备“出网”时，它一定会经过这个 Filter 的finally块。在这里 remove，是最安全、最底层的兜底。
2. 为什么不能（也无法）在这里用afterCompletion？
维度一：Filter 拿不到afterCompletion
afterCompletion是 Spring MVC拦截器（HandlerInterceptor）的特有方法。而你现在继承的OncePerRequestFilter属于Servlet 规范的组件，它属于 Spring 容器的最外层。
在 Filter 内部，你根本无法优雅地去挂载或感知拦截器的afterCompletion回调。
维度二：生命周期顺序的致命冲突
如果我们在 Filter 里设置了 ThreadLocal，却妄想在拦截器的afterCompletion里去 remove，会引发严重的职责边界混乱：
- 正常情况：请求进入 Filter（设置 ThreadLocal）→ \rightarrow→进入拦截器→ \rightarrow→执行 Controller→ \rightarrow→触发拦截器
afterCompletion（清理 ThreadLocal）→ \rightarrow→回到 Filter 离开。看起来很完美。 - 崩溃情况（致命漏洞）：假设请求在进入拦截器之前，在前面的某一个其他 Filter 里面就报错了（或者 Spring 核心解析器直接抛出了 400/403 错误，请求根本没进入 Spring Interceptor 的大门）。
- 结果：拦截器根本没触发，它的
afterCompletion自然也永远不会执行！ - 后果：你的
LoginUserContextHolder留在该核心线程里无法被清理，该线程回到线程池，下一次带给其他用户，造成严重的内存泄露或用户数据串房（越权）。
总结
在 Filter 中，**利用try...finally包裹chain.doFilter**是一种极其经典、教科书级别的设计模式。
- 它利用了方法调用栈的天然回溯：进去的时候在
try之前设值，出来的（无论成功失败）时候在finally里面清空。 - 它的安全级别比拦截器的
afterCompletion更高，因为它是 Servlet 级别的最后一层防线，只要线程想离开这个 Filter 吐出响应，就必须留下它的 ThreadLocal。
