企业官网建设流程全解析

【Spring笔记】从三级缓存到Spring Boot 3，那些高频检索背后的真实问题

如果你和我一样，浏览器收藏夹里堆了几十个Spring相关的链接，从"三级缓存原理"到"Boot 2.3和2.6选哪个"，再到"Spring AI连百炼"——那这篇笔记写给你。

前段时间整理了一轮自己的Spring笔记，发现热搜词里大家反复搜的东西，其实集中指向几个真实诉求：底层原理看不透、版本选型拿不准、工程落地没头绪、新技术（AI、监控、微服务治理）不知道怎么接。这篇笔记把我的理解、踩过的坑、实际验证过的方法串起来，不求面面俱到，只求每个话题都能一句人话讲清本质，再给一套可复现的操作路径。适合正在学Spring、被循环依赖绕晕、准备跳槽刷面试题、或者刚接手一个Spring Boot项目需要梳理思路的开发者。

1. 三级缓存原理：为什么是三级，少一级会怎样

1.1 三级缓存分别存什么：先把名字对上号

Spring的三级缓存，说的是DefaultSingletonBeanRegistry（也就是AbstractBeanFactory的父级）里面三个Map：

• singletonObjects：一级缓存，存放创建完并且完成属性填充、初始化、代理增强的最终Bean。
• earlySingletonObjects：二级缓存，存放"提前暴露"的早期引用，这个对象还没走完完整生命周期，属性可能还没填完，代理可能还没生成。
• singletonFactories：三级缓存，存放的是ObjectFactory<?>，一个工厂对象，真正需要时才调用它去生成早期Bean。

这三个Map在源码里的定义分别是：

private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256); private final Map<String, Object> earlySingletonObjects = new ConcurrentHashMap<>(16); private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

我习惯把三级缓存看作一条流水线：singletonFactories排在最前，它负责"按需产出早期引用"；产出后放进earlySingletonObjects暂存；等到Bean创建完成，最终入驻singletonObjects。

1.2 为什么二级缓存不够，一定要三级

这是最常被面试官追问的点，也是很多人卡住的地方。先说结论：如果没有AOP代理，只有二级缓存也是够用的。但Spring里大量Bean会被@Transactional、@Async、AOP切面增强，一旦"循环依赖 + AOP"同时出现，二级缓存就出问题了。

用一个例子讲清楚。假设A类有个@Transactional方法，A依赖B，B又依赖A：

1. 创建A，发现需要B，开始创建B。
2. B创建时发现需要A，但A还没创建完。如果只有二级缓存，B拿到的会是A的原始实例。
3. 等A真正创建完毕，执行postProcessAfterInitialization时，Spring发现A需要做事务代理，于是把singletonObjects里的A替换成了代理对象。
4. 问题来了：B手里持有的还是原始A，它调用A的@Transactional方法时，事务增强完全不生效。

三级缓存解决这个问题的关键在于ObjectFactory——getEarlyBeanReference会在B需要A的那一刻，提前判断A是否需要代理，如果需要就直接生成AOP代理放进二级缓存。之后A走完初始化流程时，postProcessAfterInitialization检测到已经有了提前代理，直接复用同一代理，不再重复生成。

理解这个机制有两个关键：

• getEarlyBeanReference和postProcessAfterInitialization返回的代理必须是同一个，否则照样会出现"两个A"。
• 只有Bean还在创建中且被循环依赖引用了，才会走提前暴露的逻辑；没被引用的Bean不会提前暴露。

当年读源码读到这里，真正搞明白的那一刻，整个Spring的设计思路都顺了。推荐大家去读AbstractAutowireCapableBeanFactory里的doCreateBean方法，定位到addSingletonFactory那一行，把断点打在getEarlyBeanReference上，运行一个带循环依赖的项目观察调用链。

1.3 手写Spring时的实现顺序

"手写Spring"是近年面试培训班的高频词，但真正写过的人会懂：手写不是为了造一个能用的框架，而是为了把生命周期逼出来。

我建议按这个顺序写：

1. 第一步：BeanDefinition注册。先定义BeanDefinition（存类名、是否单例、属性值），用Map保存。
2. 第二步：反射创建实例。根据BeanDefinition用构造器newInstance，这一步可以先不管依赖注入。
3. 第三步：属性填充和依赖注入。遍历@Autowired字段，从容器里取依赖Bean，取不到就先创建被依赖的Bean——这一步会自然产生循环依赖需求。
4. 第四步：Bean后置处理器（BeanPostProcessor）。在实例化后、初始化前后各留一个扩展点，AOP代理在这里注入。
5. 第五步：加上三级缓存的提前暴露机制，循环依赖问题自然解决。

给自己定一个验收标准：能支持@Component扫描、@Autowired注入、@Transactional代理、循环依赖这几个特性，就算及格了。写的过程中你会真正理解：为什么Spring的Bean工厂有那么多层抽象，为什么getBean方法会递归调用，为什么后置处理器叫"后置"却干着前置的活。

1.4 面试里常见的那几个追问

围绕三级缓存，面试题通常会这样升级：

1. "AOP代理和三级缓存有什么关系"——答案就是1.2节的内容，注意提AbstractAutoProxyCreator实现了SmartInstantiationAwareBeanPostProcessor。
2. "Spring Boot 2.6为什么默认关闭循环依赖"——因为循环依赖本质是设计味道，Spring官方从2.6开始把spring.main.allow-circular-references默认设为false，倒逼大家改构造器注入或重构。2.3.x及以前默认允许，这也是很多老项目升级时报警告的原因。
3. "为什么没有把代理提前到一级缓存"——一级缓存放的是完整Bean，提前放半成品不符合语义，而且getSingleton的语义在整个BeanFactory里都被依赖，不能随便改。
4. "三级缓存里的ObjectFactory到底返回什么"——返回的是getEarlyBeanReference的调用结果，不是getBean。这个坑很多人踩，建议写个小Demo打印返回值的类型。

说到AOP源码，热点词里的"proxy factory"其实就是ProxyFactory，Spring AOP对目标对象创建代理的核心类。快速入门可以先忽略一堆Advisor、Pointcut概念，盯住ProxyFactory.getProxy()：它内部会判断目标是接口就用JDK动态代理，没有接口就用CGLIB，然后把Advice包装成Advisor挂到代理链上。

2. Spring Boot版本矩阵：2.3.x、2.6.x、3.x到底怎么选

2.1 两年多过去了，为什么还有那么多2.3和2.6在跑

打开公司仓库扫一眼，Spring Boot 2.3.x和2.6.x的存量项目依然不少。原因很现实：项目在稳定运行、升级要付出测试成本、老代码里可能存在循环依赖或javax.*依赖，升级到Boot 3不是改个版本号那么简单。

但"还能跑"不等于"一直能跑"。2.3.x对应Spring Framework 5.2.x，已经过了社区维护生命周期；2.6.x和2.7.x对应Framework 5.3.x，5.3.x是社区长期支持分支，到现在还有补丁更新（比如热词里的Spring Framework 5.3.41下载，就是5.3.x的新补丁版本）。这里有个判断技巧：Framework 5.3.x是最后一个还维护的5.x分支，对应Boot 2.7.x；Boot 2.3已经跟不上官方安全更新了。

如果让我给选型建议，就三条：

• 遗留系统在跑2.3.x：短期内能不动就不动，但必须评估安全补丁；新功能业务模块可以尝试独立升级到Boot 2.7，为后续迁移做铺垫。
• 不得不用JDK8的新项目：选Boot 2.7.x，这是最后支持JDK8的版本线，尽量别选2.6，2.6默认把循环依赖关了，团队改造成本高。
• 新建项目：明确选Boot 3.x，开局就是JDK17，用jakarta.*命名空间，面向未来。

2.2 2.x、3.x、Spring Framework版本怎么对应

很多人搞不清Boot版本和Framework版本的关系，其实一句话：Spring Boot是启动器，Spring Framework才是底层框架。Boot通过依赖管理统一拉取Framework版本。对应关系大致如下：

jar包下载也顺带说一句：不建议去网站上手动下载spring的jar包，容易把版本线搞乱。用Maven坐标最省心，比如spring-framework-bom版本的pom.xml里，由Boot统一管理。补丁包的拉取也一样，把Boot版本升级到位，Framework自动跟着走。

spring证书哪里查这个话题也经常有人问——Spring官方的专业认证查询入口在VMware/Broadcom的认证体系里，Spring现任主理团队（VMware Tanzu）发布的认证证书可以在其官方认证平台上按姓名或证书编号查验。不过对大多数工程师来说，与其纠结证书，不如用证书同款知识点去刷题，面试官更认后者。

2.3 Boot 3和FastAPI不是对立面

热搜里"后端spring boot 3和python fastapi"这个提问很有意思。我的看法是：这两个框架解决的是不同生态的问题，拿它们做选择题，不如先想清楚团队和项目类型。

Boot 3的优势在于：类型安全、企业级组件全（事务、安全、消息、分布式），适合复杂业务系统、中大型团队、需要长期维护的微服务架构。FastAPI的优势在于：轻量、异步原生、AI生态好，Python的后端服务、模型服务、小工具接口用它非常顺手。

实际项目里不少团队的做法是"Python做AI模型推理服务，Java做业务主链路"。两边通过HTTP接口通信，各自发挥长处。如果你纠结选型，我建议按三个维度打分：团队主流语言、业务复杂度、周边生态依赖。团队全是Java，选Boot；业务以数据分析和模型调用为主，选FastAPI；两边都行的情况下，Boot 3的工程化能力更适合多人协作。

2.4 用IDEA社区版开发Spring Boot的三个落地方法

"IntelliJ IDEA社区版怎么用Spring Boot"也是高频问题。社区版没有Spring Initializr入口，但有三条路：

1. 浏览器打开start.spring.io，选好Spring Boot版本和依赖，下载zip解压后用IDEA社区版直接打开。这是最稳的方式。
2. 用命令行动手拉模板：curl https://start.spring.io/starter.zip -d dependencies=web,data-jpa -d javaVersion=17 -o demo.zip，本质上和网页端一样。
3. 装IDEA插件，比如社区版可用的Spring Boot Helper，但插件依赖社区版API的兼容性，目标IDEA版本升级后插件可能失效，我一般不太推荐把它作为核心路径。

社区版对Spring Boot日常开发完全够用：Maven/Gradle、断点调试、Git、终端都有。缺的其实是企业版的Spring Bean智能提示、端点运行视图这些锦上添花的功能，影响不大。

2.5 Spring MVC在笔记里的位置

Spring MVC本质上就是Spring对Web请求处理的一套组件：DispatcherServlet、HandlerMapping、Controller适配器、ViewResolver。学Boot时的@RestController、@RequestMapping之所以好用，正是因为Boot自动装配了这套MVC链路。

对新人我有个建议：别在Controller层堆业务代码。Controller只做参数接收、校验和视图响应，真正逻辑放到Service层。搜"Spring面试题"的人十有八九会碰到类似场景，但真正在代码评审里卡人的不是会不会写@RestController，而是层与层之间的依赖方向有没有搞反。

3. 读开源多商户跨境商城源码的正确打开方式

3.1 先分清两种下载需求：毕设对照和商业参考

搜"spring boot + mybatis的java开源多商户跨境商城源码下载"的人，至少分成两类。一类是写毕设的，比如"基于Spring Boot的大学生就业推荐系统的设计与实现"——这类项目本质上需要的是一个结构清晰、能跑通、答辩能讲清楚的"骨架"。另一类是想做小商城的创业者或外包开发，他们需要的是能直接改、能上线的东西。

两类需求，标准完全不同。毕设对照看重的是技术完整度：有没有注册登录、权限管理、CRUD、图表、论文能对应上的结构。商业参考则看重非功能性设计：多租户隔离、支付路由、防重复下单、日志审计、可部署性。把100个开源源码拿来比一遍，你会发现多数开源项目只满足了前者。

3.2 多商户商城的六个核心模块

一份合格的多商户B2B2C商城源码，我建议重点读这六个模块：

1. 商户端与平台端的多租户体系——数据库层面怎么隔离。
2. 商品中心——SKU、规格、属性、分类的模型设计。
3. 交易中心——购物车、订单、支付、退款状态机。
4. 结算与分账——平台抽成、商户结算、跨境场景下的多币种处理。
5. 会员/营销——用户等级、优惠券、秒杀、拼团。
6. 物流与库存——多仓库发货、库存锁定、超卖控制。

读代码的时候别先一头扎进Controller，而是先画一张模块依赖图：哪个服务依赖哪个库，哪个模块调用哪个RPC。这一步做完，整个项目的大局就清楚了。

3.3 MyBatis在多租户场景里怎么落地

多商户商城"多租户"最直接的问题是：商户A和商户B的数据怎么隔离？

常见手段有三种：

• 独立数据库：安全等级最高，但成本高。
• 共享数据库、独立Schema：隔离性好但维护成本偏高。
• 共享数据库、共享Schema、加租户ID字段：最常见的做法，低成本。

在MyBatis链路里，加租户ID有几种落地方式。最优雅的是利用MyBatis的Interceptor拦截Executor的update/query方法，在SQL层面自动拼接租户条件。具体来说就是实现org.apache.ibatis.plugin.Interceptor，在intercept方法里改写BoundSql，给WHERE条件追加商户ID。这类拦截器做得好时，业务代码完全无感知，写SELECT不用手动带merchant_id。

但要注意一个坑：多租户拦截器对原生SQL的解析能力有限。如果你在XML里写了<script>动态SQL、UNION、子查询、FOR UPDATE，解析器很可能改写错。我的建议是：拦截器只作为兜底，核心查询在SQL设计时就显式带上租户条件，人和框架双重保障。

3.4 源码读不下去怎么办：建立运行地图

把源码下下来第一件事不是看代码，是让它先跑起来。多数开源商城提供SQL初始化脚本和配置文件，把数据库建好、改完配置、启动成功，才算拿到"活"的源码。

跑起来后，按"请求路线"走读：注册一个商户→登录→发布商品→下单支付→商家发货→用户确认收货。每步去代码里找对应的Controller→Service→Mapper，记录调用链。这张运行地图比任何类图都管用。我见过不少同事下载了源码三天后就开始吃灰，原因就是直接在IDE里随机打开类文件，被继承体系淹没了。我的经验是："从用户故事反推代码路径"，不追求覆盖率，追求每一个核心路径都能讲到五层。

4. Spring Security难学，难在过滤器链的顺序

4.1 认证、授权、过滤器的实际关系

Spring Security之所以劝退，是因为它不是一个简单的工具库，而是一套过滤器链架构。你用@EnableWebSecurity定义了一个SecurityFilterChain，实际上是在配置多个过滤器如何串联：UsernamePasswordAuthenticationFilter负责登录认证，AuthorizationFilter检查URL授权，ExceptionTranslationFilter统一处理异常。

理解这套机制要注意三点：

1. 过滤器链有顺序，每个过滤器都有明确的职责。你配置的permitAll、authenticated规则是在授权过滤器里判断的，认证过滤器在前面另做一套事。
2. SecurityContextHolder是线程绑定上下文，认证成功就把Authentication对象放进去，后续业务代码通过SecurityContextHolder.getContext().getAuthentication()拿当前用户。
3. UserDetailsService是用户数据加载入口，你只需要返回一个UserDetails（用户名、密码、权限），剩下的比对逻辑框架来做。

入门最快的路径是先把过滤器链调通：表单登录、内存用户、H2控制台、放行静态资源，一步步把SecurityFilterChain的规则注释掉看效果。遇到401/403不要猜，直接看ExceptionTranslationFilter抛出的异常类型。

4.2 第三方接口放哪，不该只看"有没有权限"

热搜词里"Spring Boot对外提供的接口（给第三方）应该放在哪里？是单独的服务？还是放在对应的..."——这是很多团队在对接外部系统时纠结的问题。

答案不是非黑即白，取决于你的调用方是谁。我的决策思路是这样：

选择"单独服务"的时候，真正复杂的不是写Controller，而是处理跨服务身份传递：第三方传过来的调用凭证（access token）要在出口服务里校验，然后通过内部调用链把"服务身份"传给下游，不能让下游再签一遍。还需要设计验签、时间戳防重放、IP白名单、接口幂等。这些在单体场景不容易想到，到开放平台就全是大事。

4.3 用Sentinel做接口治理时的注意点

再说热搜里的"spring cloud sentinel datasource redis集群"。Sentinel是阿里开源的流量治理组件，限流、熔断、降级都在里面。但很多团队第一次用它，是直接把规则写在application.yml或Sentinel控制台界面里，这样有两个问题：

1. 规则和代码耦合，改规则要重启。
2. 多实例部署时，每台机器规则不同步，集群里就会出现"限流一半"的诡异现象。

把Sentinel数据源接到Redis集群，思路就是：把限流降级规则集中存到Redis，客户端启动时拉取规则，同时通过Redis的发布订阅监听规则变更，控制台改完规则后所有实例即时生效。实现上，引入sentinel-datasource-redis依赖，在配置里指定Redis地址、频道和规则类型，FlowRule等数据源会自动完成远端加载和订阅。

spring: cloud: sentinel: datasource: flow: redis: redis-port: 6379 redis-host: 192.168.x.x channel: sentinel-rule-channel rule-type: flow

这套方案在规则少、变更不频繁的时候很够用。但规则一多（几十条以上），Redis里的Key管理和规则版本回滚就会麻烦，那时候可以考虑Nacos数据源，用推模式配合控制台做规则配置中心。选型逻辑就是：Redis偏轻、Nacos偏重治理，按团队基础设施来。

5. Spring AI生态观察：从2.0热点到A2A协议

5.1 Spring AI到底解决了什么问题

"Spring AI"是Spring官方把LLM能力引入Java生态的尝试，它做的事情和当年Spring Data对数据库做的事类似：抽象统一接口，屏蔽各家大模型API的差异。

Spring AI的核心抽象就是ChatModel，甭管是OpenAI、通义千问还是百炼上的qwen模型，你只需要注入不同实现的ChatModel，调用chat.call(prompt)即可。写Java后端的人不用再贴一堆HTTP请求代码去调各家SDK。Spring AI 2.0已经作为一个相对成熟的版本发布，支持了工具调用、结构化输出、多模态等能力。

我当时上手时的感受：通义千问、百炼平台的接入路径比想象中简单，官方文档以Spring AI 2.0版本为例，配置好api-key和base-url，把ChatModel注入Service，一个小型客服问答接口就通了。

5.2 阿里云百炼和spring-ai-alibaba的状态

搜"spring ai alibaba停更了吗"的人，大概率看到过GitHub仓库更新频率不稳定的历史。这个问题我按第二手信息说：Spring AI Alibaba是阿里云百炼对接Spring AI官方标准的实现，会跟随Spring AI的大版本走。如果你用的是阿里云百炼的qwen3.7等模型，目前建议直接使用百炼官方文档推荐的starter，不必自己封装请求层。

注意一个容易混淆的点：阿里云有一个独立的SDK生态（如dashscopeSDK），和Spring AI官方规范下的spring-ai-alibaba不是一回事。选哪个取决于你是不是要在Spring生态里复用统一抽象。如果是为了快速做Demo，用阿里自己的SDK；如果项目里未来可能切换多家模型，用Spring AI Alibaba更划算。

5.3 Agent和A2A：新东西要先分清名词

"Spring AI Agent"和"A2A Spring"是两码事，经常被放在一起搜。

Agent在Spring AI 2.0里的落地方式是：把工具方法用@Tool注解暴露给模型，模型通过对话推理决定要不要调用工具。比如做一个天气查询Agent，写一个@Tool("查询城市天气")方法，模型在用户问到天气时自动填充城市参数并调用它。你的业务代码只负责定义工具，编排由AI完成。

A2A（Agent2Agent）则是Google提出的一套Agent间通信协议，解决"多个独立Agent之间怎么发现彼此、怎么传递任务、怎么返回结果"的问题。Spring AI官方在新版本里对A2A协议有兼容作用——消息按JSON-RPC格式走，Agent之间通过URL互相调用。对普通业务开发，A2A暂时不影响日常功能，但如果你想做"多Agent协作"的架构，它会是以后的基础设施。

5.4 把Dify工作流转成Java代码的现实路径

"Dify工作流转成Spring AI Java代码github"这个热搜很有意思。用过Dify的人都知道，可视化工作流搭起来非常快：一个输入节点→一个大模型节点→一个知识库检索节点→一个条件分支→输出。但到了Java后端要接同一个业务链路，不可能在Java代码里再搭一套可视化编排，只能翻译成可执行的代码结构。

我的映射经验是这样的：

核心心法只有一个：别试图把可视化编排整个搬到Java里，而是把Dify里的"数据流转"拆成"节点的执行顺序和依赖关系"，用Service层的代码依次串起来。Dify适合产品原型和运营快速验证，Java代码适合上线和高并发，两者定位不同。

实操上，我会先打开Dify里的导出JSON，看清节点之间的连线，画出数据从哪个输出端流向哪个输入端，然后按从上到下的顺序手写Java方法。如果工作流带了知识库，记得在Spring里初始化好VectorStore和Embedding模型，这一步和Dify后台配置知识库是一一对应的。

6. Spring Boot监控从需求到落地

6.1 你以为的监控和实际要的监控

"spring boot实现监控，都有哪些需求和功能?"这个热搜太真实了——新手以为监控就是"服务活着没"，实际上线后才发现远远不止：

• 健康检查：/actuator/health，这是最重要的。
• 应用指标：内存、CPU、线程数、GC次数。
• HTTP请求指标：吞吐、平均响应时间、错误率。
• 数据源指标：活跃连接、空闲连接、慢SQL。
• 日志级别动态调整：不用重启项目就能改logger级别。
• 线程快照和堆快照：排查死锁、OOM。
• 外部依赖调用：第三方接口延迟，出问题先定位是不是上游挂了。

更实际的一点：监控不只是"看面板"，而是"报警→定位→处置"的闭环。只接数据不配报警等于没监控。所以我做监控的标准是：基础设施类指标用Prometheus+Grafana，应用健康类指标用Boot的Actuator暴露，再加一套Spring Boot Admin做实例注册与可视化的轻量入口。

6.2 Actuator端点开哪些，别一股脑全开

Actuator默认只暴露了health和info，生产环境建议按需开放。我的常用配置长这样：

management: endpoints: web: exposure: include: health,info,metrics,loggers,threaddump,env endpoint: health: show-details: always loggers: enabled: true

其中heapdump在生产环境要慎重，这个端点会导出整个JVM堆内存快照，Java进程占多少内存就导出多大文件，频繁调用会把磁盘打爆。shutdown端点默认关闭是正确的，别手贱打开。env端口在某些内网环境里可以开，但有敏感配置值暴露给管理页面的风险，需要配合权限控制。

如果你用Spring Boot Admin，客户端只要暴露给Admin服务器所需的那几个端点就行，不需要全开公网。

6.3 Spring Boot Admin的部署套路

Spring Boot Admin提供一套现成的可视化UI，服务端和客户端两部分组成：

• 服务端：建一个独立的Spring Boot应用，引入spring-boot-admin-starter-server，主类加@EnableAdminServer。
• 客户端：每个需要被监控的服务引入spring-boot-admin-starter-client，配置spring.boot.admin.client.url指向服务端地址。

<dependency> <groupId>de.codecentric</groupId> <artifactId>spring-boot-admin-starter-server</artifactId> <version>3.3.3</version> </dependency>

版本匹配是这里最容易踩的坑：Spring Boot Admin 2.x对应Boot 2.x，Admin 3.x对应Boot 3.x。用错版本，客户端注册老是失败，看日志半天找不到原因。

6.4 规则动态下发：为什么用Redis做Sentinel数据源

回到前面提过的Sentinel Redis数据源，换一个角度理解它的必要性。

如果没有动态数据源，限流规则就只能写在本地配置或控制台内存里。控制台内存型规则最大的痛点是：Sentinel控制台默认只做展示和单机操作，改动不会自动同步到所有实例。你在线上去掉一条限流规则，结果只有你连的那一台机器生效，其他机器还在限流。

Redis数据源的架构价值就是"规则集中、动静分离"：实例启动时从Redis拉一次全量规则，之后订阅规则变更频道；控制台推送新规则到Redis，所有在线实例同时收到更新。配置的运行机制就是发布订阅，规则在内存里热加载，不需要重启。

在集群规模大于5个实例、规则调整频繁的场景下，强烈建议把规则数据源落进Redis或Nacos，别依赖控制台。改造成本不高，收益是治理能力上了一个台阶。

收尾之前的几句大实话

这篇笔记写到现在，其实是有意把热搜词按"原理—版本—工程—安全—AI—监控"这条线串了一遍。如果只让我留三句话：

第一，Spring的根基在Bean生命周期和AOP，这两块弄透，三级缓存、代理、事务、Security、AI工具调用全都是同一个套路的不同应用场景。看到BeanPostProcessor、ObjectFactory出现时不要再慌，它们其实是同一个故事里的角色。

第二，版本选型和技术选型没有"最正确"，只有"最匹配"。老项目别盲目升级，新项目别留恋旧版本。把2.3、2.6、3.x的差异点写在项目文档里，远比在代码里偷偷调allow-circular-references要省心。

第三，学习Spring最快的方式是带着问题读源码，而不是抱着视频课从头看到尾。视频能带你把项目跑起来，但只有断点打在doCreateBean和getEarlyBeanReference上的时候，你才真正开始懂Spring。Spring实践视频可以看，但不能只看不写，写个最小Demo、跑一个循环依赖、打印一次过滤器链，这些动手实验比任何"十小时速通"都值。