2. 核心概念：鉴权与授权、拦截器与过滤器
在构建后端部署的鉴权拦截体系时，有两个基础概念对必须彻底厘清：鉴权（Authentication）与授权（Authorization）的职责边界，以及拦截器（Interceptor）与过滤器（Filter）在请求处理链中的定位差异。混淆这两对概念是移植适配过程中最常见的架构失误来源。
2.1 鉴权（Authentication）与授权（Authorization）
鉴权解决“你是谁”的问题，授权解决“你能做什么”的问题。两者在请求处理流程中严格按先后顺序执行：先鉴权，后授权。任何跳过鉴权直接进入授权的设计都会产生严重安全漏洞。
| 维度 | 鉴权（Authentication） | 授权（Authorization） |
|---|---|---|
| 核心问题 | 你是谁？ | 你能做什么？ |
| 验证对象 | 身份凭证（Token、Session、证书） | 权限策略（角色、资源、操作） |
| 典型机制 | JWT 验证、OAuth2 登录、Basic Auth | RBAC、ABAC、ACL |
| 失败结果 | 401 Unauthorized | 403 Forbidden |
| 执行顺序 | 第一道关卡 | 第二道关卡 |
| 状态依赖 | 通常无状态（Token 自包含） | 依赖用户上下文（角色/权限集） |
常见误区：很多团队在 API 网关层只做了鉴权，却误以为完成了授权。例如验证了 JWT 签名有效（鉴权通过），但未检查该用户是否具有“删除订单”的权限（授权缺失），导致越权操作。移植适配时，必须明确每一层拦截点负责的是鉴权还是授权。
2.2 拦截器（Interceptor）与过滤器（Filter）
在 Java Web 生态（尤其是 Spring 体系）中，Filter 和 Interceptor 是两种不同粒度的请求拦截机制。移植适配时，选择错误的拦截层会导致鉴权逻辑重复执行、上下文丢失或无法拦截特定资源。
| 对比维度 | 过滤器（Filter） | 拦截器（Interceptor） |
|---|---|---|
| 所属规范 | Servlet 规范（javax.servlet / jakarta.servlet） | Spring MVC 框架（HandlerInterceptor） |
| 拦截范围 | 所有 Web 请求（包括静态资源、Servlet、JSP） | 仅拦截 Spring MVC 的 Handler 执行前后 |
| 执行时机 | 进入 Servlet 容器后、进入 DispatcherServlet 之前 | DispatcherServlet 分发后、Handler 执行前/后 |
| 上下文访问 | 只能访问 ServletRequest / ServletResponse | 可访问 HandlerMethod、ModelAndView、Bean 容器 |
| 依赖注入 | 需通过 init-param 或 Spring 委托配置 | 天然支持 Spring 依赖注入 |
| 典型用途 | 字符编码、跨域（CORS）、请求日志、XSS 过滤 | 鉴权校验、权限检查、性能监控、请求参数预处理 |
| 配置方式 | web.xml 或 FilterRegistrationBean | WebMvcConfigurer.addInterceptors() |
移植适配关键判断：如果你需要拦截的请求可能包含静态资源（如 /assets/*、/health 端点），或者需要在进入 Spring 容器之前就完成鉴权，请使用 Filter。如果你需要获取当前请求对应的 Controller 方法信息、或者需要利用 Spring 的依赖注入来获取 UserService 等 Bean，请使用 Interceptor。在云原生网关（如 Spring Cloud Gateway）中，Filter 的概念被重新定义为 GatewayFilter，与 Servlet Filter 不同，移植时需注意区分。
2.3 移植适配中的选择策略
在将鉴权拦截逻辑从单体应用移植到微服务或云原生架构时，需要根据目标框架重新选择拦截层。以下是一份快速决策清单：
- 目标为 Spring Boot 单体或 BFF 层：优先使用 Interceptor 实现鉴权与授权，便于获取 Handler 上下文和依赖注入。
- 目标为 Spring Cloud Gateway / Zuul：使用 GatewayFilter（对应 Filter 概念），在路由转发前完成 Token 校验。
- 目标为 Istio / Envoy 服务网格：使用 Envoy External Authorization Filter，将鉴权逻辑下沉到 Sidecar 层，业务服务无需再写拦截代码。
- 目标为 Serverless（AWS Lambda / Knative）：使用 Lambda Authorizer 或 自定义请求拦截器，注意冷启动对鉴权延迟的影响。
- 需要拦截静态资源或非 Spring 端点：必须使用 Filter，因为 Interceptor 无法覆盖这些路径。
实践建议：在移植适配过程中，建议将鉴权逻辑封装为独立的 AuthProvider 接口，Filter 和 Interceptor 都依赖该接口，而不是直接内嵌鉴权代码。这样当底层鉴权方式从 JWT 切换为 OAuth2 或 Session 时，只需修改 AuthProvider 实现，无需改动拦截层代码。