面向对象架构中，如何通过拦截器（Interceptor）设计来优化对象行为？

本文共计874个文字，预计阅读时间需要4分钟。

截取器在面向对象架构中，并非是给方法加钩子，而是让对象自身具备可插拔的行为扩展能力。其核心不在于代理或反射，而在于利用组合、递归和接口契约，将横向逻辑自然地编织进对象的生存周期中。

拦截器本质是对象行为的“嵌套封装”

一个 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 记录耗时，不需要拆成两个独立阶段