拦截器本质是对象行为的嵌套封装，通过组合+递归+接口契约将横切逻辑自然织入生命周期：当前拦截器前置→下一层（拦截器或target）→当前后置，严格逆序执行，支持终止、跳过与异常补偿。
拦截器在面向对象架构中，不是给方法“加钩子”，而是让对象自身具备可插拔的行为扩展能力。它的核心不在于代理或反射，而在于用组合+递归+接口契约，把横切逻辑自然地编织进对象生命周期里。
拦截器本质是对象行为的“嵌套封装”
一个 Target 对象不直接被调用，而是被包装进 TargetInvocation 实例中。这个包装体持有一个 Interceptor 列表和一个 Target 引用。当执行时，它不是顺序遍历列表，而是递归调用：当前拦截器的前置逻辑 → 下一层（下一个拦截器或 target）→ 当前拦截器的后置逻辑。这种结构天然支持嵌套、可撤销、可跳过——比如某个拦截器 preHandle 返回 false，就直接终止递归，不再往下传。
- 每个 Interceptor 实现统一接口（如 before/after），但内部可自由访问上下文、调用 service、修改参数或响应
- TargetInvocation 不依赖 Spring 或 Servlet 容器，纯 Java 对象，可单元测试、可复用到 CLI 或消息处理等非 Web 场景
- 新增拦截逻辑只需实现接口 + 插入链中，无需修改原有 Target 类，符合开闭原则
与 AOP 和动态代理的关键区别
Spring AOP 基于代理，是在运行时生成新类；而 OOP 拦截器是编译期确定的组合关系。前者强依赖反射和类加载机制，后者只依赖接口和引用传递。这意味着：
- 没有代理类生成开销，启动快、内存占用低
- 调试时堆栈清晰：能看到每一层 InterceptorImpl → TargetInvocation → Target 的完整调用路径
- 不绑定框架：同一套 Interceptor 可用于 Spring MVC、Vert.x、甚至自研 RPC 调用链
如何组织拦截逻辑才真正“面向对象”
避免把拦截器写成一堆静态工具方法的集合。真正 OOP 的写法是：每个拦截器是一个有状态、可配置、可复用的对象。
- 用构造函数或 Builder 注入依赖（如 Logger、UserService），而不是靠 @Autowired 或静态单例
- 将判断逻辑封装为策略，例如 AuthInterceptor 内部持有 AuthStrategy 接口，不同环境切换 JwtStrategy / SessionStrategy
- 利用 ThreadLocal 或上下文对象（如 InvocationContext）传递数据，而非在 request/response 中塞临时属性
递归调用不是炫技，而是为了行为对称性
preHandle 和 afterCompletion 必须成对出现，且执行顺序严格逆序。递归天然保证这一点：进入时层层 before，退出时层层 after，像括号匹配一样可靠。
- 若用循环实现，需额外维护栈或索引，容易遗漏后置逻辑或顺序错乱
- 异常传播也更自然：某层抛出异常，上层可在 after 中捕获并做补偿（如回滚事务、释放锁）
- 支持“环绕式”语义，比如 PerformanceInterceptor 记录耗时，不需要拆成两个独立阶段
