场景

理解 Spring 只停留在注解用法，遇到扩展点时容易写出侵入式代码。把容器实现还原为设计模式，可以更准确地找到可替换位置。

原理

BeanFactory 体现工厂与注册表，单例作用域由容器维护实例，AOP 使用代理，JdbcTemplate 固定资源管理骨架，事件机制使用观察者，HandlerAdapter 把不同控制器适配到统一调度流程，装饰器则逐层增强能力。

设计步骤

阅读源码时先找稳定接口与变化实现；再追踪对象由谁创建、调用由谁转发、回调何时触发；用最小示例替换一个策略或适配器；最后验证生命周期、线程安全和异常传播，而不是背诵类名。

权衡

模式让框架开放扩展而不修改核心，但多层代理、模板回调和事件监听会增加调试距离。同步事件简单可控，却耦合响应时间；异步事件解耦更强，却必须处理顺序、丢失与重试。

实践建议

业务代码借鉴模式时保持克制：工厂集中创建，模板固定真正稳定的流程，事件表达已经发生的事实。不要复制 Spring 的通用复杂度。调试代理问题可先查看运行时类型和代理链；扩展框架优先使用公开 SPI，避免依赖内部类。

落地检查

上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在预发布环境模拟依赖不可用、进程重启和配置回滚，验证降级路径不会放大故障。上线时采用小流量观察，提前定义停止条件与负责人。稳定后复盘真实数据，删除没有收益的复杂度，并把新发现的约束补进测试、监控和设计记录，使方案能够随业务持续演进，而不是停留在一次性评审结论。