多态性是框架实现可扩展、低耦合的核心机制，通过统一接口+多种实现支撑插件体系，如spring的beanpostprocessor、mybatis的executor、netty的channelhandler；抽象类预留钩子，运行时动态选择策略，避免if-else类型判断。
多态性在框架源码中不是“用出来”的炫技功能，而是支撑整个架构可扩展、可替换、低耦合的底层设计惯用手法。它让框架不绑定具体实现，把行为决策权交给使用者或运行时环境。
统一接口 + 多种实现，是框架插件体系的基础
主流框架（如 Spring、MyBatis、Netty）大量使用接口定义能力契约，再由不同模块提供实现：
- Spring 的 BeanPostProcessor 接口：允许用户插入自定义逻辑，在 Bean 初始化前后执行。框架只调用接口方法，不管你是做 AOP 增强、属性校验，还是日志埋点——只要实现它，就会被自动发现并调用。
- MyBatis 的 Executor 接口：定义了查询、更新等核心执行行为。SimpleExecutor、ReuseExecutor、BatchExecutor 都是它的子类，框架根据配置（如是否开启批处理）动态选择具体实现，上层代码完全无感。
- Netty 的 ChannelHandler：每个处理器都实现相同接口（如
channelRead()），但可以分别是解码器、业务逻辑、异常处理——管道中串联多个 handler，靠的就是多态调用。
抽象类预留钩子，子类决定关键行为
比接口更进一步，框架常提供抽象模板类，把流程骨架写死，把变化点声明为 abstract 或 protected 方法：
- Spring 的 AbstractApplicationContext 定义了 refresh() 流程（加载配置、注册 BeanFactoryPostProcessor、实例化单例……），但具体怎么解析 XML/注解/JavaConfig，交由 ClassPathXmlApplicationContext、AnnotationConfigApplicationContext 等子类实现。
- MyBatis 的 BaseExecutor 封装了缓存、事务、一级缓存等共性逻辑，而真正执行 SQL 的
doQuery()方法留空，由 SimpleExecutor 或 CachingExecutor 各自实现。
运行时动态选择实现，支撑条件化行为
框架不会在启动时硬编码某一种策略，而是根据环境、配置或对象类型，在运行时决定调用哪个子类的方法：
- Spring MVC 的 HandlerAdapter：一个请求进来，DispatcherServlet 不知道该用 @Controller 还是 @RestController，它遍历所有 HandlerAdapter 实现（RequestMappingHandlerAdapter、HttpRequestHandlerAdapter 等），调用
supports()判断是否适配当前 handler，再调用handle()执行——这就是典型的“父类引用 + 运行时判定 + 子类差异化响应”。 - Logback 的 Appender：日志输出到控制台、文件、远程服务？框架只持有
Appender<iloggingevent></iloggingevent>引用，实际运行时根据 logback.xml 配置加载对应子类（ConsoleAppender、FileAppender、SocketAppender），调用同一doAppend()方法，行为却完全不同。
避免 instanceof 和 if-else，用多态替代类型判断
高质量框架源码里极少出现大段 if (obj instanceof X) { ... } else if (obj instanceof Y) { ... }。取而代之的是：
- 把类型判断逻辑下沉到各子类内部，比如
canHandle(Message msg)方法； - 用工厂或策略注册表（如 Map
）配合多态调用，而不是硬编码分支； - 依赖 Spring 的 @Conditional、@Profile 等机制，在容器层面完成实现类的按需注入，而非运行时 if 判定。
本质上，框架开发者把“变”和“不变”清晰分离：流程是不变的，策略是可变的；接口是稳定的，实现是可插拔的。多态性正是实现这种分离最自然、最轻量、最符合 OOP 直觉的技术载体。
