Spring源码中的设计模式解析与应用

> ### 摘要 > 本文深入剖析Spring框架核心源码，从`BeanFactory`、`ApplicationContext`到`AOP代理机制`，系统揭示工厂模式、代理模式、模板方法模式、观察者模式等十余种设计模式在真实代码中的落地实现。通过逐行解读关键类（如`AbstractApplicationContext`、`ProxyFactoryBean`）的设计逻辑，文章阐明Spring如何以松耦合、可扩展的方式支撑企业级应用开发，助力开发者从“使用者”进阶为“理解者”与“定制者”。 > ### 关键词 > Spring源码,设计模式,框架设计,代码解析,实战应用 ## 一、Spring框架概述 ### 1.1 Spring框架概览及其设计理念 Spring并非凭空而生的工具集，而是一场关于“控制权让渡”的温柔革命。它从诞生之初便拒绝将开发者囚禁于繁复的XML配置与僵硬的接口契约之中，转而以轻量、非侵入、面向接口的方式，悄然重构人与代码之间的信任关系。其核心设计理念——松耦合、可测试、可扩展——不是印在文档首页的口号，而是深嵌于每一行源码呼吸节奏里的基因密码。当`BeanFactory`以极简接口收束对象生命周期管理，当`ApplicationContext`如一位沉静的 orchestrator（编排者）统合资源、事件与AOP能力，Spring真正践行的，是一种克制的哲学：不替代开发者思考，只为其搭建可延展的思维脚手架。这种设计，既源于对Java企业开发痛点的深切体察，也映照出框架作者对软件演进本质的敬畏——好的框架，从不喧宾夺主，而是在无声处，让逻辑自然生长。 ### 1.2 Spring核心模块与设计模式的关系 Spring的模块结构，恰似一座精密咬合的齿轮组，而设计模式正是那些隐于齿隙、传递力量却不露形迹的力学逻辑。`BeanFactory`模块是工厂模式最本真的回响——它不生产具体类型，却为所有类型提供统一的创建契约；`AOP代理机制`则让代理模式跃然纸上，`ProxyFactoryBean`不是简单封装JDK动态代理或CGLIB，而是以策略选择+适配封装，将横切逻辑织入业务脉络而不惊扰其肌理；`AbstractApplicationContext`中反复出现的`refresh()`模板方法，则如一道清晰的程序刻度线，将环境准备、Bean加载、事件发布等关键步骤固化为骨架，把可变部分留给子类自由落笔。十余种设计模式并非堆砌罗列，而是在`core`、`beans`、`context`、`aop`四大支柱模块中彼此呼应、层层嵌套，构成一张既严谨又富弹性的架构之网。 ### 1.3 为什么要研究Spring源码中的设计模式 因为真正的理解，始于看见“缝合处”。当开发者仅停留于`@Autowired`与`@Transactional`的魔法表层，便如同隔着毛玻璃阅读一首诗——能感知韵律，却难触内核。唯有潜入`BeanFactory`的`getBean()`调用链，目睹`AbstractBeanFactory`如何委托`FactoryBeanRegistrySupport`处理工厂Bean，才能体会“工厂的工厂”这一嵌套设计背后的解耦深意；唯有细读`ProxyFactoryBean`中`getObject()`与`getProxy()`的职责分治，才懂得代理模式如何在运行时悄然编织织物，而非编译期强行缝合。研究Spring源码中的设计模式，不是为膜拜权威，而是为了在真实、复杂、经受过千万次生产考验的代码里，辨认出那些被反复验证过的思维结晶——它让“知道怎么用”升维为“明白为什么这样用”，最终将框架从黑箱，还原为可触摸、可推演、可重写的思维模型。 ### 1.4 设计模式在Spring中的实际应用价值 设计模式在Spring中绝非教科书式的静态标本，而是持续搏动的工程血脉。工厂模式支撑起Bean的按需创建与依赖解耦，使微服务粒度拆分成为可能；代理模式赋予AOP以无侵入织入能力，让日志、监控、事务等横切关注点真正实现“一次编写、处处生效”；观察者模式驱动`ApplicationEventPublisher`与`ApplicationListener`的松散协作，让模块间通信摆脱硬编码依赖，为事件驱动架构铺平道路。这些模式共同构筑的，是一种可生长的系统韧性——当业务需求突变，开发者无需推翻重来，只需遵循既定模式扩展`BeanPostProcessor`、实现新`Advisor`、注册自定义`EventListener`。这便是Spring留给实践者的最珍贵遗产：它不承诺万能解法，却慷慨交付一套已被千锤百炼的“元语言”，让每一次代码书写，都成为对优雅架构的一次自觉靠近。 ## 二、Spring中的创建型与结构型设计模式 ### 2.1 单例模式在Bean容器中的实现 在Spring的`BeanFactory`世界里，单例并非一种执念，而是一种克制的承诺——“同一个ID，同一份存在”。当`DefaultListableBeanFactory`加载配置、解析`<bean scope="singleton">`或`@Scope("singleton")`时，它并未急于实例化，而是悄然将Bean定义（`BeanDefinition`）注册进缓存池；待首次调用`getBean()`，才触发`createBean()`流程，并立即将生成的实例以`beanName`为键、对象引用为值，存入`singletonObjects`这个线程安全的`ConcurrentHashMap`。此后每一次获取，都如轻叩同一扇门——门后始终是那个已被初始化、已执行`postProcessAfterInitialization`、已注入所有依赖的完整生命体。这种“懒加载+强缓存”的双阶设计，既规避了启动时无谓的资源消耗，又确保了全局状态的一致性与可预测性。它不声张，却让数据库连接池、配置管理器、全局事件总线等关键组件，在千万并发中依然步调如一——单例在此，不是对内存的吝啬，而是对系统确定性的温柔守护。 ### 2.2 工厂模式在Bean创建中的应用 工厂模式在Spring中从不以单一面孔示人，而是一组环环相扣的“创造之链”：`BeanFactory`是契约的起点，定义`getBean()`这一普适接口；`AbstractBeanFactory`承上启下，封装模板逻辑与缓存策略；真正挥动造物之手的，是`AbstractAutowireCapableBeanFactory`——它调度`InstantiationStrategy`选择反射或CGLIB实例化，委托`BeanPostProcessor`介入生命周期，再交由`ObjectFactory`完成延迟初始化。尤为精妙的是`FactoryBean`接口：它自身是Bean，却生产另一类Bean；`ProxyFactoryBean`便是典型——它不返回自己，而返回一个动态织入了切面逻辑的代理对象。这种“工厂的工厂”结构，使Spring得以在不修改客户端代码的前提下，无缝切换JDK代理与CGLIB代理，甚至集成第三方对象工厂。工厂在此，早已超越“创建对象”的原始语义，升华为一种可插拔、可组合、可编程的构造哲学。 ### 2.3 模板方法模式在JdbcTemplate中的体现 `JdbcTemplate`是模板方法模式最沉静而有力的践行者。其抽象基类`JdbcAccessor`仅声明数据源与异常转换器，真正的骨架藏于`execute()`系列方法之中：`execute(ConnectionCallback)`先获取连接、开启事务上下文、捕获SQL异常并转为`DataAccessException`，再调用用户传入的回调；`query()`与`update()`则在此骨架上进一步固化SQL执行、结果集映射、参数绑定等步骤，仅将“如何处理结果”“如何设置参数”留白为`RowMapper`与`PreparedStatementSetter`。开发者无需直面`Connection.close()`的琐碎，不必在每处DAO中重复`try-catch`，只需专注业务逻辑本身——那被抽离出去的二十行样板代码，正是模板方法以沉默交付的尊严。它不禁止你重写，却以清晰的钩子（`doInConnection`、`extractData`）邀请你落笔于该落笔之处，让数据访问从此有了呼吸的节奏与统一的语法。 ### 2.4 策略模式在事务管理中的使用 Spring的事务管理，是一场精密的策略协奏。`PlatformTransactionManager`是策略的统御接口，而`DataSourceTransactionManager`、`JtaTransactionManager`、`HibernateTransactionManager`则是其具体化身——它们各自封装了不同环境下的事务开启、提交、回滚逻辑，却共享同一套编程模型：`TransactionDefinition`描述隔离级别与传播行为，`TransactionStatus`承载运行时上下文，`TransactionTemplate`则以模板方式屏蔽底层差异。更深层的策略嵌套存在于`TransactionAttributeSource`体系中：`AnnotationTransactionAttributeSource`从`@Transactional`解析元数据，`NameMatchTransactionAttributeSource`按方法名匹配规则，二者皆实现同一接口，可自由切换。当开发者在`@EnableTransactionManagement`中指定`mode = AdviceMode.ASPECTJ`，框架便悄然将策略从Spring AOP切换至AspectJ织入——策略在此，不是冷冰冰的if-else分支，而是可装配、可替换、可测试的工程契约，让事务这头庞然巨兽，在不同技术栈间从容转身。 ## 三、Spring中的行为型设计模式 ### 3.1 观察者模式在事件机制中的应用 Spring的事件机制，是一场静默而盛大的对话——发布者不执念于谁在听，监听者不焦虑于何时被唤，它们之间只隔着一个轻盈的`ApplicationEventMulticaster`。当`AbstractApplicationContext`调用`publishEvent()`，它并不遍历所有Bean去比对类型，而是将事件托付给多播器；后者再依据`ApplicationListener`的泛型参数（如`ContextRefreshedEvent`）完成精准投递。这种“解耦的默契”，正是观察者模式最动人的实践：`ApplicationEventPublisher`是抽象的被观察者，定义`publishEvent()`这一契约；`SimpleApplicationEventMulticaster`是具体的实现，持有一个线程安全的监听器集合，并支持同步/异步分发、失败回调等可扩展行为；而每一个实现了`ApplicationListener<E extends ApplicationEvent>`的类，都是自愿注册的观察者——它们无需知晓事件从何而来，亦不必关心其他监听者是否存在，只需在`onApplicationEvent()`中安放自己的响应逻辑。更值得凝视的是，Spring甚至为监听器提供了`SmartApplicationListener`接口，通过`supportsEventType()`与`supportsSourceType()`两个钩子，让观察行为具备运行时判断力——这已不止于经典模式的复刻，而是将观察者升华为一种有意识、可裁决、能自省的协作主体。事件在此，不是消息的单向倾泻，而是一张由信任与契约织就的响应之网。 ### 3.2 代理模式在AOP中的实现 代理模式在Spring AOP中，从不以锋利的刀刃示人，而如一层温润的釉彩，覆于业务逻辑之上却不改其本色。`ProxyFactoryBean`是这层釉彩的匠人：它本身是一个Spring Bean，却拒绝成为最终的服务提供者；它的`getObject()`方法不返回自身，而是调用`getProxy()`，悄然启动代理生成流程——若目标类实现接口，则委托`JdkDynamicAopProxy`，借`InvocationHandler`在方法调用时织入增强逻辑；若无接口，则交由`CglibAopProxy`，通过字节码重写生成子类，在方法入口处插入拦截器链。尤为精微的是，`AdvisedSupport`作为代理的元数据中枢，统一管理`Advisor`列表、目标对象、代理接口等要素，使JDK与CGLIB两种底层技术得以被同一套高层语义所驾驭。代理在此，早已超越“控制访问”的原始意图，演化为一种运行时的逻辑编织术：它不修改源码，不侵入业务，却能让事务、日志、权限等横切关注点如呼吸般自然附着于每一次方法调用。那看似透明的代理对象，实则是Spring以设计模式写就的一封情书——致所有不愿被框架绑架，却渴望被优雅支撑的开发者。 ### 3.3 适配器模式在Spring整合其他框架中的作用 适配器模式是Spring拥抱世界的谦逊语法。当它面对Log4j、SLF4J、Commons Logging等彼此割裂的日志生态，`commons-logging`模块并未强推新标准，而是以`LogAdapter`体系为桥梁：`Jdk14LoggerAdapter`将`java.util.logging.Logger`封装为统一`Log`接口，`Log4jLoggerAdapter`则将`org.apache.log4j.Logger`映射过去，所有适配器皆继承自`AbstractLoggingSystem`，共享`getLog()`与`isDebugEnabled()`等标准化行为。同样，在MVC层，`HandlerAdapter`让`@Controller`、`HttpRequestHandler`、`Servlet`三类迥异的处理器得以共存于同一`DispatcherServlet`调度流水线中——`RequestMappingHandlerAdapter`解析注解控制器，`HttpRequestHandlerAdapter`转译函数式请求处理器，`SimpleServletHandlerAdapter`则兜底传统Servlet。这些适配器从不试图改造原系统，只是轻轻一握，便将异构接口纳入Spring的运行时契约。适配器在此，不是妥协的产物，而是一种清醒的工程自觉：真正的开放，不在于消灭差异，而在于为差异预留尊严的接口；不在于统一语言，而在于建造一座座可拆卸、可替换、可验证的翻译亭。 ### 3.4 装饰器模式在Spring增强功能中的体现 装饰器模式在Spring中，是一场不动声色的层层加冕。`BeanPostProcessor`接口本身即是最朴素的装饰契约——它不改变Bean的创建逻辑，却在`postProcessBeforeInitialization()`与`postProcessAfterInitialization()`两个关键节点，为任意Bean动态附加行为。`AutowiredAnnotationBeanPostProcessor`为其注入依赖，`CommonAnnotationBeanPostProcessor`为其激活`@Resource`与`@PostConstruct`，`InitDestroyAnnotationBeanPostProcessor`则为其绑定生命周期回调——它们并非独立存在，而是被`AbstractBeanFactory`按序注入`beanPostProcessors`列表，在每个Bean初始化前后依次“披上”一层新职责。更富深意的是`AbstractAutowireCapableBeanFactory`对`InstantiationStrategy`的封装：`CglibSubclassingInstantiationStrategy`与`SimpleInstantiationStrategy`皆实现同一接口，前者在实例化后额外织入`@Transactional`代理能力，后者则专注基础反射创建——它们可自由组合、叠加使用，如同为同一个Bean对象逐层裹上不同功能的“外衣”。装饰器在此，拒绝一劳永逸的终极形态，它信奉渐进式增强：每一次装饰都不覆盖前序逻辑，只在其上叠加语义；每一次增强都保持接口一致，让调用者始终面对同一张面孔。这恰是Spring最温柔的承诺：你交付一个朴素的类，我许你千种可能。 ## 四、Spring设计模式在实际项目中的应用 ### 4.1 Spring Boot中的自动配置与设计模式 自动配置，是Spring Boot写给开发者的一封情书——它不喧哗，却字字落在心上；它不替代思考，却悄然卸下千行样板的重担。这份温柔背后，并非魔法，而是一场精密的设计模式协奏：`@EnableAutoConfiguration`是策略模式的无声宣言，它依据类路径下的jar包（如`spring-boot-starter-web`）、已存在的Bean、以及`@Conditional`系列注解所构成的运行时上下文，动态决策“该加载哪些配置”；`AutoConfigurationImportSelector`则如一位严谨的策展人，从`META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports`中读取候选配置类列表，再经`getAutoConfigurationEntry()`层层过滤，最终只留下真正适配当前环境的那一组——这正是策略+模板方法的双重落地：骨架由`SpringFactoriesLoader`固化，变化点则交由各`Condition`实现自由裁决。而`xxxAutoConfiguration`类本身，又是工厂模式与装饰器模式的共生体：它们不直接创建核心组件，而是通过`@Bean`方法声明可被容器管理的实例工厂；同时，又以`BeanPostProcessor`或`ApplicationContextInitializer`为钩子，在不侵入原有逻辑的前提下，为`WebMvcConfigurer`、`DataSource`等基础设施叠加定制行为。自动配置之所以“自动”，从来不是因为省略了设计，而是因为把最繁复的设计，藏进了最克制的接口与最诚实的条件判断里。 ### 4.2 Spring Cloud中的设计模式应用 在分布式系统的混沌边界上，Spring Cloud以设计模式为经纬，织就一张既坚韧又柔韧的协作之网。服务发现中的`DiscoveryClient`是典型的抽象工厂：它不绑定Eureka、Consul或Nacos的具体实现，却统一提供`getInstances()`与`getServices()`契约，让上层路由、负载均衡、熔断逻辑得以在抽象层面演进；`LoadBalancerClient`则进一步将策略模式推向纵深——`RibbonLoadBalancerClient`与`BlockingLoadBalancerClient`作为可插拔策略，分别适配同步与响应式调用模型，而`ServiceInstanceListSupplier`更以观察者姿态监听服务实例变更，使负载均衡器能在毫秒级完成拓扑刷新。熔断机制中，`CircuitBreaker`接口是策略的中枢，`Resilience4JCircuitBreakerFactory`与`SentinelCircuitBreakerFactory`各自封装不同熔断算法，却共享同一套降级、异常分类与状态跃迁语义；而`@CircuitBreaker`注解本身，则是代理模式的轻盈化身——它不修改目标方法字节码，仅在调用链路中动态织入熔断逻辑，让故障隔离如呼吸般自然。这些模式从不孤立存在，而是在`spring-cloud-commons`的抽象基座上彼此咬合：一个服务调用请求流经注册中心（工厂）、选型策略（策略）、熔断保护（代理）、降级兜底（模板方法），最终抵达远端——这不是技术的堆砌，而是一次次对“如何优雅地失败”“如何谦逊地协作”的深沉回应。 ### 4.3 Spring框架设计模式在微服务架构中的实践 当单体应用裂变为数十个微服务，Spring的设计模式便从“支撑工具”升华为“协作宪法”。工厂模式在此演化为跨服务的契约生成引擎：`OpenFeign`的`FeignClientFactoryBean`并非简单创建HTTP客户端，而是依据`@FeignClient`元数据，动态组装编码器、解码器、重试策略与拦截器——它不生产具体服务，却为所有远程调用提供一致的创建语义；代理模式则成为服务边界的温柔守门人：`@FeignClient`生成的代理对象，将`user-service/findById`这样的业务语义，无声翻译为HTTP请求，再将响应反序列化为领域对象，全程屏蔽网络细节，使开发者仍能以本地方法思维编写分布式逻辑。观察者模式支撑起事件驱动的松耦合治理：`spring-cloud-stream`以`BindingService`为多播中枢，将`Source`发布的消息投递给多个`Sink`绑定，而`@StreamListener`或函数式`Consumer`只是自愿注册的监听者，彼此间无依赖、无感知、无阻塞；模板方法则沉淀为通用治理能力——`AbstractCommand`在`Hystrix`时代定义命令执行骨架，`Resilience4J`中`CircuitBreaker.decorateSupplier()`亦延续此脉络，将熔断、限流、重试等横切逻辑固化为可复用的执行模板。这些模式共同构筑的，是一种“分布式确定性”：无论服务如何拆分、部署如何漂移、语言如何异构，只要遵循Spring的模式契约，系统便始终保有可预测、可调试、可演进的秩序感。 ### 4.4 实际项目中Spring设计模式的最佳实践 真正的最佳实践，从不诞生于文档的完美推演，而淬炼于上线前夜的告警、灰度时的抖动、重构中的犹豫。在真实项目里，工厂模式的最佳落点，是将第三方SDK（如微信支付`WXPayService`、阿里云OSS `OSSClient`）封装为`@Primary`的`FactoryBean`，使其生命周期由Spring统管，避免静态单例导致的内存泄漏与测试污染；代理模式的清醒使用，在于严格区分“业务代理”与“基础设施代理”——`@Transactional`与`@Cacheable`应仅作用于明确的Service方法，绝不穿透至Repository或DTO层，以防事务边界模糊与缓存雪崩；观察者模式的生命力，在于拒绝“上帝监听器”：每个`ApplicationListener`必须专注单一事件类型，且通过`SmartApplicationListener`的`supportsEventType()`主动声明能力边界，避免事件风暴引发的隐式耦合；而模板方法的尊严，则在于克制——自定义`JdbcOperations`扩展时，宁可多写两行`try-catch`，也不重写`execute()`主干，只为守住那条“变与不变”的清晰刻度线。这些实践没有银弹，却有一致的灵魂：尊重模式本意，不为炫技而嵌套，不因便利而越界，不以牺牲可读性换取灵活性。因为Spring教会我们的终极一课是——设计模式不是代码的装饰，而是开发者与系统之间，那份沉默却郑重的约定。 ## 五、Spring设计模式的高级应用与优化 ### 5.1 提升代码可读性与可维护性的设计模式技巧 设计模式不是写给机器看的语法糖，而是写给人——尤其是写给三个月后的自己、写给刚加入项目的同事、写给深夜排查线上问题的那位陌生开发者——的一封清晰信笺。在Spring源码中，可读性从来不是附赠品，而是被精心设计的主干：`AbstractApplicationContext.refresh()`以二十行注释分明的模板步骤，将原本混沌的启动流程切分为`prepareRefresh()`、`obtainFreshBeanFactory()`、`registerBeanPostProcessors()`等语义自明的方法名，每一处钩子都像路标，指向“此处可扩展”，而非“此处请猜”。`JdbcTemplate`将`execute()`与`query()`分离，不是为了多写一个类，而是让DAO层的每一行调用都在说同一句话：“我在执行SQL”或“我在映射结果”——没有歧义，不藏逻辑，不绕弯路。更动人的是`SmartApplicationListener`中那两个布尔方法：`supportsEventType()`与`supportsSourceType()`，它们不返回对象，不抛异常，只用最朴素的`true/false`回答“我是否关心这件事”，让事件监听的意图如晨光般透明。当工厂模式以`FactoryBean`接口呈现，当代理模式借`ProxyFactoryBean`之名落笔，Spring早已把“命名即契约”刻进基因——因为真正可维护的代码，从不需要注释来解释“它是什么”，而只需让人一眼读懂“它为何存在”。 ### 5.2 提高系统性能与扩展性的设计模式应用 性能不是靠压测调优出来的，而是被设计进去的呼吸节奏；扩展性亦非上线后补上的补丁，而是源码里预留的接口缝隙。Spring将性能与扩展性悄然缝入模式肌理：单例模式的`singletonObjects`缓存采用`ConcurrentHashMap`，不是为炫技线程安全，而是让每一次`getBean()`都避开重复初始化的沉重代价，在高并发场景下稳如磐石；代理模式中`AdvisedSupport`对`Advisor`列表的统一管理，使事务、日志、权限等增强逻辑得以按需组合、延迟加载、按优先级排序——既避免无谓织入，又保障关键切面必先执行。模板方法模式在`JdbcTemplate`中的运用，更是性能与扩展的双重诗学：它把连接获取、异常转换、资源释放这些昂贵操作固化为骨架，却将`RowMapper`与`PreparedStatementSetter`开放为轻量回调——开发者注入的只是函数式逻辑，零对象创建开销，毫秒级响应可期。而`BeanPostProcessor`的装饰器链，则让扩展如搭积木般自然：新增一个`MetricsBeanPostProcessor`统计初始化耗时，无需修改任何已有类，只需注册为Bean，便自动融入容器生命周期——这并非松散耦合的空谈，而是Spring以设计模式写就的、可测量、可观察、可渐进演化的性能契约。 ### 5.3 降低系统复杂度的设计模式选择 复杂度从不来自功能本身，而源于职责的纠缠、边界的模糊与变化的不可控。Spring的选择始终清醒：用最少的模式，解最重的耦。观察者模式在事件机制中拒绝“推送即执行”的粗暴逻辑，转而由`SimpleApplicationEventMulticaster`承担分发中枢职责，让发布者与监听者之间仅存一个泛型接口的薄薄契约——没有回调地狱，没有循环依赖预警，只有`publishEvent()`与`onApplicationEvent()`之间静默的信任。适配器模式则以谦卑姿态消解整合之痛：`LogAdapter`体系不争论Log4j与SLF4J孰优孰劣，只专注构建一层薄薄的翻译层；`HandlerAdapter`不强制所有控制器继承同一基类，却让`@Controller`、`HttpRequestHandler`、`Servlet`三类迥异实现共舞于`DispatcherServlet`的同一调度节拍。这种“不消灭差异，只管理差异”的智慧，正是降低复杂度的最高形式。当策略模式将`PlatformTransactionManager`抽象为接口，让`DataSourceTransactionManager`与`JtaTransactionManager`各自安住于自己的技术土壤，系统便不再因事务引擎切换而全局震荡——复杂度被锁进策略实现内部，暴露给开发者的，永远是一致的`@Transactional`语义。Spring教给我们的，从来不是如何驾驭复杂，而是如何优雅地绕过它。 ### 5.4 常见设计模式误用及其解决方案 误用设计模式，比不用更危险——它披着“架构正确”的外衣，却悄悄埋下可读性崩塌、调试路径断裂、变更成本飙升的伏笔。Spring源码本身，就是一面照见误用的明镜：有人将`FactoryBean`滥用为“万能对象生成器”，在`getObject()`中混杂数据库查询、远程调用与状态校验，彻底违背其“专注对象创建”的本意；这恰是Spring在`ProxyFactoryBean`中严守职责边界的反例——它只负责生成代理，绝不介入目标对象的业务逻辑。又有人将代理模式泛化至Repository层，为每个DAO方法添加`@Transactional`，导致事务边界失控、一级缓存失效、N+1查询雪崩；而Spring的实践恰恰相反：`@Transactional`明确限定于Service层，因其承载的是“业务原子性”，而非“数据操作原子性”。再如模板方法模式，若在自定义`JdbcOperations`子类中重写`execute()`主干，便等于亲手拆毁Spring精心铺设的异常转换与资源回收骨架——真正的扩展，应落在`ConnectionCallback`或`ResultSetExtractor`这些被明确留白的钩子里。解决方案不在别处：回归Spring源码的原始设计意图——工厂模式只管“造”，代理模式只管“织”，模板方法只管“定骨架”，观察者只管“发与听”。当每一个模式都回到它诞生时的那个具体问题，误用便自然退场，留下的，是清澈如初的代码纪律。 ## 六、总结 本文从源码层面系统剖析了Spring框架中工厂模式、代理模式、模板方法模式、观察者模式等十余种设计模式的真实落地路径，揭示其如何在`BeanFactory`、`ApplicationContext`、`AOP代理机制`等核心组件中协同演进。通过逐行解读`AbstractApplicationContext`、`ProxyFactoryBean`等关键类的设计逻辑，文章阐明Spring以松耦合、可扩展为内核的架构哲学，并强调：设计模式在Spring中绝非静态教条，而是持续搏动的工程血脉——它支撑Bean按需创建、实现AOP无侵入织入、驱动事件松耦合通信、赋能事务可插拔管理。研究这些模式，本质是穿透魔法表层，将框架从黑箱还原为可触摸、可推演、可重写的思维模型，助力开发者从“使用者”成长为“理解者”与“定制者”。