企业官网建设流程全解析

做Java后端开发这些年，要说绕不开的一个技术栈，那一定是Spring。面试官问基础会问Spring，公司新项目立项会先用Spring Boot，微服务架构一摆出来又是Spring Cloud，连这两年大模型应用开发升温之后，官方也很快推出了Spring AI。很多人把这整套东西叫“Spring全家桶”，但真正把它用明白、把原理吃透的人并不多。我见过太多人拿着Spring Framework的源码下载下来却不知道从哪看起，也见过不少应届生把“三级缓存”背得滚瓜烂熟，结果一问“为什么需要三级缓存、二级为什么不行”就卡住。这篇文章想做的，就是把我这些年用Spring、教Spring、踩坑填坑的经验梳理出来，尽量用说人话的方式讲清楚：全家桶里到底都有什么，每个模块解决什么场景问题，底层原理值得死磕到什么程度，以及2025年的今天，Spring AI、Agent这些新东西要怎么接进现有系统。

文章适合三类人看：刚学完Java SE、正准备往企业级开发走的初学者，已经被Spring Boot用得很熟、但面试总是栽在原理上的中级开发，还有想踩住Spring AI这波热点的技术负责人。不同基础的读者根据自己的情况跳着读即可，但我建议至少在“三级缓存”和“Spring AI”这两块停留一下，前者是面试和框架设计的经典题，后者决定了你接下来三年的技术方向。

1. 先搞清楚Spring全家桶到底是什么

1.1 从EJB时代到Spring：这套技术栈到底在解决什么问题

聊全家桶之前，得先知道它从哪来。在Spring出现之前，Java企业级开发的主流方案是EJB（Enterprise JavaBeans）。当时的EJB有多麻烦，老程序员应该都还记得：要写一堆XML、要部署到重量级应用服务器里、要遵循一堆规范，而且不好测试。Rod Johnson在2002年写了《Expert One-on-One J2EE Design and Development》，核心观点是“不用EJB也能开发企业应用，而且可以更轻量更好用”，Spring Framework就是在这个背景下诞生的。

Spring最开始解决的核心问题就两个：对象管理和对象间依赖管理。传统代码里，一个Service要new一个Dao才能干活，对象之间的耦合关系写死在代码里，想替换实现就得改代码重新编译。Spring用IoC（控制反转）把对象的创建权从业务代码手里拿过来，统一交给容器管理；你只需要声明“我要用哪个Service”，容器会在合适的时机把一个已经装配好的实例给你。这个设计思路到今天依然是全家桶的基石。Spring AOP则解决另一个问题：日志、事务、权限这些横切逻辑如果散落在每个业务方法里，会非常难维护。AOP允许你把这些公共逻辑抽出来，在运行时“织入”到目标方法前后，业务代码里不用写一行重复代码。

理解了这个背景，你就会明白Spring全家桶并不是一堆随机拼凑的框架。它有一条清晰的演进主线：Framework确立IoC和AOP的核心思想，MVC解决Web层，Boot解决配置繁琐和部署问题，Cloud解决分布式环境下的协作问题，Security解决安全问题，AI则把大模型能力拉进Java生态。每个模块都是在上一个模块解决不了的新问题中生长出来的。

1.2 全家桶里每一块“桶”，各自管什么场景

我给不少团队做过技术选型，经常会被问到“全家桶到底要学哪些”。我的建议是先分清模块职责，再按需组合。下面这张表是我整理的模块速查，按实际项目中的使用频率排列：

实际项目里，最常见的组合是Spring Boot + Spring MVC + Spring Data（或MyBatis）+ Spring Security，这是一套标准的单体后端底座。当一个系统膨胀到几十个模块、多个团队并行开发时，才会引入Spring Cloud系列。而Spring AI属于增量选项，哪怕你现在的项目很传统，也可以单独抽一个服务做AI能力。

这里想多说一句：全家桶不是“全部都要上”。我在调研时见过不少团队从单体直接冲上Spring Cloud全家桶，结果注册中心、网关、链路追踪全上了，业务代码却没多少，运维成本反而翻了几倍。工具永远为业务服务，单体能解决的复杂度不要提前交给微服务。

2. 底层核心原理：IoC、AOP、三级缓存，面试经典题背后的设计逻辑

2.1 Bean的生命周期与三级缓存：为什么二级缓存不够用

Spring面试题里出镜率最高的“三级缓存”，指的其实是DefaultSingletonBeanRegistry里的三张Map。先记住它们的角色：

• 一级缓存singletonObjects：放已经创建完成的成品Bean实例。
• 二级缓存earlySingletonObjects：放提前暴露的半成品Bean实例，此时可能还没完成属性填充。
• 三级缓存singletonFactories：放ObjectFactory工厂对象，用来延迟生成半成品实例。

一个单例Bean从创建到可以使用，大致经历实例化、属性填充、初始化三步。正常情况下，Bean创建完直接进一级缓存。问题出在循环依赖上：A依赖B，B又依赖A。如果A先创建，属性填充时发现需要B，于是转去创建B；B创建时属性填充又需要A，但A还没创建完，此时如果找不到A的引用，B就会失败。

没有三级缓存也能解决一部分循环依赖，方案是提前暴露A的半成品：A实例化完了，先把还没填充属性的A放进二级缓存。B拿到这个半成品A，完成自己的创建，再回去把B注入给A。这样A也能最终完成。那为什么还需要三级缓存？关键在AOP代理。

假设A需要被切面代理，Spring要返回的是一个代理对象“AProxy”，而不是原始的A对象。如果B注入的是从二级缓存里拿到的“半成品原始A”，而最终放入一级缓存的是“AProxy”，那就会出现两个不同对象，B持有的A引用和最终容器的A实例不一致。这不是小问题，因为AOP代理包裹了事务、权限等逻辑，B拿到原始对象等于这些能力都失效了。

三级缓存的设计就是为了把“生成代理对象”这个动作推迟。三级缓存里存的是ObjectFactory工厂，正常情况下它返回原始半成品对象；如果检测到有AOP，getEarlyBeanReference会在这个时间点创建代理对象返回。因为代理对象的创建被延迟到了“有人需要这个引用”的时候，B拿到的就已经是代理，最终容器里存的也还是这个代理，引用就一致了。用一句人话总结：三级缓存不是给循环依赖兜底的，是为了让“循环依赖+AOP”两条功能线能同时成立。

有不少人问过我“能不能不要二级缓存直接三级？”不行。三级缓存里的工厂只调用一次，工厂执行完就会在二级缓存里放一份结果，防止同一个Bean被反复创建代理。整个设计环环相扣，少一层都会出问题。顺带提醒一句：Spring Boot 2.6开始默认不允许循环依赖，启动时直接报错。我这个老油条的建议是，新项目永远不要依赖循环依赖来解耦，重构掉A对B的强引用，用构造器注入、事件机制或者@Lazy来绕开，比在配置里调allow-circular-references=true要干净得多。

2.2 AOP与代理：Spring是怎么把Bean悄悄“包一层”的

AOP是Spring第二个核心。很多人在业务里写过@Transactional，却不知道它背后是AOP在干活。方法上的注解为什么能生效？因为Spring在你的Bean外面包了一层代理对象，调用方法时先经过切面逻辑（打开事务），再执行真实方法（提交或回滚）。如果你拿到的不是代理，而是原始对象，那@Transactional就静默失效了，这是事务失效最常见的坑。

Spring实现动态代理有两种方式：JDK动态代理和CGLIB。JDK动态代理要求目标类实现接口，通过Proxy.newProxyInstance生成一个实现了目标接口的代理对象，方法调用会被InvocationHandler截获。CGLIB则通过生成目标类的子类来代理，不要求接口，所以普通类也能代理。Spring Boot 2.x之后默认使用CGLIB，因为现在很多Service类根本不写接口，用JDK代理会直接报错。

面试中经常被追问的ProxyFactory是Spring AOP的底层核心类。理解它其实不难：你要让一个Bean拥有AOP能力，本质上就是告诉Spring三件事——横切逻辑是什么（Advice通知）、在什么条件下应用（Pointcut切入点）、怎么把两者合并进代理（Advisor增强器）。ProxyFactory做的事情，就是把这些配置统一起来，然后决定用JDK还是CGLIB去创建最终的代理对象。Spring在Bean初始化阶段会调用AbstractAutoProxyCreator检查当前Bean是否匹配某个切面，匹配就创建代理，不匹配就返回原始Bean。

如果你想验证自己对AOP的理解，可以试着回答下面这个问题：同一个类内部，A方法调用B方法，如果B上有@Transactional，事务还会生效吗？答案是失效的。因为外部调用进的是代理，但代理调用A后，A内部直接调B走的是this引用，绕过了代理对象。解决方式就是@Autowired注入自己，或者拆一个Bean出来，或者用AopContext.currentProxy()。这个坑我在真实项目里见到过不止一次，编码规范里都要专门写一条“禁止同类内部调用切面方法”。

2.3 手写一个MiniSpring：用最小代码理解IoC容器

我学Spring时做过一件笨但是有效的事：自己写一个迷你IoC容器。如果你也想真正理解“容器”两个字，我建议也动手试一次。思路不复杂，核心就四步：

1. 扫描包路径下所有class文件，找出标注了@Component的类。
2. 把类名转成BeanName，注册一个BeanDefinition（描述Bean如何创建的元信息）。
3. 通过反射实例化所有Bean，按构造器参数或字段解析依赖关系。
4. 把实例放入一个ConcurrentHashMap，下次getBean时直接取。

下面是我当年仿写的核心片段，刻意省略了细节，只保留主干逻辑：

public class MiniApplicationContext { private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(); private final Map<String, Class<?>> beanDefinitions = new HashMap<>(); public MiniApplicationContext(Class<?> configClass) throws Exception { // 1. 扫描@Component注解，收集BeanDefinition // 2. 循环实例化，遇到依赖递归创建 } public <T> T getBean(Class<T> clazz) { return clazz.cast(singletonObjects.get(clazz.getName())); } }

就是这几行东西，背后隐藏着整个Spring容器的骨架。当然，真正的Spring要比这个复杂几百倍：Bean作用域、循环依赖、AOP代理、懒加载、事件发布、环境变量解析、自动配置……但只要你亲手实现过最核心的“扫描-注册-实例化-注入”，再看Spring源码就不会觉得全是天书。

省流结论：手写Spring的目的不是造轮子，而是把你对框架的“敬畏感”变成“熟悉感”。很多同学看源码看不进去，就是因为没有带着问题去看。拿我这套MiniSpring当地图，再对照源码找位置，效率会高很多。

3. Spring Boot 实战：从零到一搭一个能上线的服务

3.1 自动配置到底是怎么“自动”的

Spring Boot最让人着迷的地方，就是“约定优于配置”。以前用Spring写一个Web项目，要写一堆XML配置数据源、事务管理器、视图解析器；现在只要在pom.xml里引入spring-boot-starter-web，项目就能跑起来。这个神奇效果的核心是@SpringBootApplication注解，它由三个注解组成：

• @SpringBootConfiguration：声明这是一个配置类。
• @EnableAutoConfiguration：开启自动配置大幕。
• @ComponentScan：扫描当前包及子包下的组件。所以你的启动类一定要放在包的最外层，否则扫描不到Controller和Service。

@EnableAutoConfiguration的底层，是通过读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件，里面罗列了所有自动配置类。每个配置类上面又有一堆@ConditionalOnXxx条件注解，比如@ConditionalOnClass表示“classpath里有这个类才生效”，@ConditionalOnMissingBean表示“你没自己定义才帮你配置”。条件全部满足时，这份自动配置才会生效。所以你引入了mybatis-spring-boot-starter，配置类发现classpath里有SqlSessionFactory相关类，就会自动帮你创建数据源连接工厂；等你真要用时，DataSource已经被容器管理好了。

理解自动配置对排查问题非常重要。我曾经遇到过“一个服务启动后连接的不是生产库而是本地库”的问题，排查了半天，最后发现是多环境配置加载顺序不对，application.yml里的值被自动配置类的默认值覆盖了。如果你想看某个Bean到底是谁配置出来的，可以在配置里打开debug=true，Spring Boot启动时会自动打印一份正反匹配报告，告诉你哪些自动配置生效、哪些没生效。这个功能在我调第三方Starter时救过很多次。

3.2 用IntelliJ IDEA社区版开发Spring Boot，一分钱不花

有些人以为开发Spring Boot必须用Ultimate版，因为社区版没有Spring Assistant插件，没法一键生成项目。其实完全不是。Ultimate版确实是生产力神器，但如果你在个人学习或者预算有限，IDEA Community Edition配合下面这套流程，体验也足够顺畅：

1. 用浏览器打开Spring Initializr（start.spring.io），选好语言、构建工具（Maven或Gradle）、Spring Boot版本，勾上你需要的依赖，点击Generate下载压缩包。
2. 解压后用IDEA Community直接打开项目文件夹，IDEA会识别出Maven结构，等右下角进度条走完依赖就导好了。
3. 在src/main/java下找到带main方法的启动类，右键直接Run。因为Spring Boot内嵌了Tomcat，不需要额外装服务器。
4. 接口调试建议装一个Postman或者直接用IDEA自带的HTTP Client，社区版也支持写.http文件发起请求。

社区版缺少的其实是运行配置图形界面、Spring Bean的依赖关系图、JPA面板之类的增强功能，但日常开发的核心路径都不受影响。我自己的经验是，如果用Maven命令行能跑通的命令，IDEA Community都能无缝衔接。唯一要注意的是，如果项目里用了Lombok，需要先在插件市场安装Lombok插件，否则编译直接报找不到getter/setter。

3.3 Spring Boot + MyBatis开发多商户跨境商城，到底是怎么分层设计的

这两年电商出海很热，Spring Boot + MyBatis这种传统组合依然是许多跨境商城系统的技术底座。很多开源商城源码都被冠以“多商户跨境”关键词。这类系统的业务复杂点在于三套模型要同时运转：

第一是商户隔离模型。商城平台上有很多独立商家，每个商家有自己的商品、订单、库存，但共用一套会员体系和平台规则。数据层的隔离方式通常有三种：独立数据库、共享库独立Schema、共享库共享表加tenant_id字段。跨境商城早期追求部署简单，大多采用第三种，用MyBatis拦截器在SQL后面自动追加AND tenant_id = ?，做到对业务代码几乎无感。第二种实现更干净但数据库数量多，运维成本高，目前主流大平台反而在向“库表分层组合”演进。

第二是订单状态机。跨境订单比起国内电商，多了清关、跨境物流、外币支付等环节，状态链路可能长达十几个节点。订单模块的核心不是CRUD，而是状态流转的设计——每个状态下允许什么操作、触发什么事件、走到哪个下个状态，必须用状态机规则收敛，不能任由业务代码到处改状态。这是最容易被开源项目忽略但线上最值钱的模块。

第三是支付与汇率体系。多币种、多支付渠道，意味着金额结算不能只存一个数字，至少要记录原始金额、原始币种、结算汇率和最终结算金额。我的建议是：金额一律用Decimal类型存储，绝不用浮点型；所有金额计算在应用层完成，数据库只做持久化。

如果你拿到的开源商城代码很乱，先不要急着在上面改需求。我一般建议先画清楚“商户-商品-订单-支付”四张核心表的关系，再检查权限拦截器和多租户逻辑，最后再动业务。否则线上出现商户A看到了商户B订单这种事，大多是租户隔离代码没走对。

3.4 Spring Boot服务监控：上线之后你要盯哪些指标

一个服务上线，最怕的不是功能bug，而是你完全不知道它现在健康状态。Spring Boot提供了现成的监控能力——Actuator。引入spring-boot-starter-actuator，再把management.endpoints.web.exposure.include=health,info,metrics配好，你就能通过HTTP端点看到服务状态和张量指标。/actuator/health是给负载均衡做健康检查用的，/actuator/metrics能查JVM内存、线程数、HTTP请求数等基础数据。

生产环境我建议把监控链路再扩一步：Actuator负责采集，Micrometer负责把指标转成标准格式，Prometheus负责定时拉取和存储，Grafana负责画Dashboard。这套组合是JVM应用监控的事实标准。你只要在Spring Boot里引入micrometer-registry-prometheus，Prometheus就能通过/actuator/prometheus把指标抓走。

指标怎么选？优先级从高到低是：JVM堆内存和GC情况、线程池活跃度、接口QPS和TP99延迟、数据库连接池使用率、错误率。我见过有些团队只盯着告警，CPU飙到80%才去看日志，其实更多问题在慢慢涨的堆内存和连接池泄漏上。建议把jvm_memory_used_bytes、hikaricp_connection_usage、http_server_requests_seconds_max这几个指标配成核心看板，比啥都盯着强。

4. 从单体到微服务：Spring Cloud落地经验与Security安全实践

4.1 Spring Cloud核心组件，哪些值得真正用起来

微服务是个筐啥都能装，但Spring Cloud也不是全部都要上。现在Spring Cloud Alibaba生态非常成熟，我的推荐组合是：

Nacos是我最推荐的注册中心，原因是它把“注册中心”和“配置中心”合并了。以前用Eureka还要额外搭Config Server，Nacos一个进程就把服务发现、配置管理、命名空间都干了。它还支持配置动态刷新，线上改配置不用重启服务，对Java团队太友好了。

不过也要说句公道话：如果服务数量不超过十个，我不建议一上来就微服务。分布式系统最大的敌人不是并发，是网络不确定性。调用远程服务可能超时、重试、失败，这些都要代码去处理。单体把一个模块拆出来容易，但把链路追踪、容错降级、数据一致性都治理好，难度是指数级上升的。架构选型一定要算术账：单体能不能扛住业务体量？团队有没有精力治理分布式复杂度？两个答案都是否定，那Spring Cloud就先放一放。

4.2 对外接口给第三方，应该放单独服务还是在原系统里

这个问题的标准答案不是固定的，得看接口性质。我在团队里推动过一个规则：对外部第三方提供的Open API，单独拆一个接口网关服务；对内部系统之间调用的接口，放在对应的业务服务里。

原因有几个。第一是安全域不同。对外API要暴露在外网，需要单独做鉴权、签名验签、IP白名单、限流。如果把这些逻辑塞进核心业务系统，等于把所有内部接口的暴露面都扩大了。第二是演进节奏不一致。第三方对接需求变化快，今天加一个字段，明天改一个协议，放在独立服务里不影响核心链路。第三是稳定性隔离。外部流量不可控，峰值来了可能导致整条业务链路雪崩，独立服务加网关限流可以挡住大部分异常。

实战里的落地方案，通常是三种形态：独立服务挂在自己的域名下，提供统一鉴权（AppId + Secret签名）和OpenAPI文档中心；或者基于已有网关服务对特定路径做单独路由，但业务逻辑仍写在业务服务里；或者采用BFF模式（Backend For Frontend），单独一层做协议适配和数据聚合，再调用底层核心服务。

我踩过的坑是：项目早期图省事，把第三方商户的订单查询接口直接写在订单服务里，结果半年后接口越堆越多，本地和第三方回调逻辑互相纠缠，联调环境一放通就是事故。拆出来之后，核心系统终于不再被第三方异常流量“绑架”了。所以我的态度很明确：只要接口要暴露给外部，就值得单独拆一个服务。

4.3 Spring Security认证授权，从入门到落地的完整思路

安全是整个全家桶里最容易“配完就忘”的一块。Spring Security的默认行为很苛刻：只要引入依赖，所有接口都要求认证，然后你开始配放行路径、配登录页、配用户。这个框架的设计思路，本质上是一条过滤器链（FilterChain）。你可以把它想象成进火车站：先查身份证（认证），再查行李物品（授权），最后验票进站（访问控制）。在Spring Security里，核心对象是SecurityFilterChain，它决定了哪些路径走哪套过滤器序列。

常见会话方案有两种。传统Session方案适合服务端渲染页面，登录成功后把用户信息存到Session，浏览器靠Cookie维持会话。面向移动端和前后端分离，主流方案是JWT：登录成功后服务端签发一个带签名信息的Token，客户端后续每次请求都在Authorization头带上它，服务端验签后就能知道用户是谁。

用JWT时记住一个关键点：JWT是无状态的，服务端不存会话，所以无法主动让某个Token失效。你没法通过删Session来强制下线用户，只能依赖Token的过期时间设短，再配合Refresh Token续期。有些项目为了“能主动踢人”又搞黑名单数据库，那等于又回到了有状态方案。这里的取舍要提前想清楚，不要边开发边改。

方法级权限用起来很爽。在Controller或Service方法上加@PreAuthorize("hasRole('ADMIN')")，就能实现“只有管理员能调这个操作”。但要注意，方法级权限只在Spring管理的Bean上生效，和前面说的AOP代理是同一套机制——如果你在类内部自调用，权限照样失效。我自己维护过一个管理后台，最头疼的永远是权限规则散落在代码里，后来强制要求：所有权限判断必须写在Service层而不是Controller层，方便测试，也避免接口层和业务层权限不一致。

5. Spring AI来了：大模型、Agent与Java生态的融合

5.1 Spring AI 2.0接入大模型，Java也终于有“AI原生”体验了

Spring AI的定位可以概括为：让Java开发者像用Spring Boot一样去调用大模型，不用关心各家LLM服务的HTTP细节。在Spring AI 2.0里，核心抽象是ChatClient，它相当于一个统一的大模型客户端，通过不同的Model实现去对接OpenAI、通义千问、DeepSeek等服务商。

如果你在国内使用阿里云百炼上的通义千问（比如Qwen3系列的模型），可以通过DashScope实现接入。配置上，无非是设置API Key和模型名，然后写这样一段代码：

ChatClient chatClient = ChatClient.builder(chatModel).build(); String answer = chatClient.prompt("用一句话解释什么是Spring AI") .call() .content();

代码不算多，但这个ChatClient背后包含了：请求的构建、对话上下文的保存、流式输出、工具调用、模型切换等能力。以前你要手动拼HTTP请求、处理SSE流、管理消息历史，Spring AI把这些都规范成了Java接口。从工程角度看最大的价值在于：团队切换模型服务商时，业务代码基本不用大改，改配置就能换底座。

5.2 Dify工作流怎么转成Spring AI Java代码

Dify是一个非常流行的开源AI应用开发平台，用可视化的方式编排Agent、知识库和工作流。很多团队先用Dify验证业务逻辑，跑通了再想落到自己的Java系统里。从Dify工作流到Spring AI Java代码，其实是两条技术路线：

路线一：Dify作为独立的编排服务。Java应用直接调用Dify开放API，把消息发给Dify，Dify内部的工作流跑完后返回结果。这种方式的优点是，流程调整不需要改Java代码，改Dify里的画布就行；缺点是系统多了一个重依赖，Dify挂了应用就全挂。

路线二：把工作流逻辑翻译成Java代码。Dify里的每个节点基本都能映射到Spring AI的对应能力：LLM节点映射为ChatClient.prompt()调用，知识库节点映射为向量检索（从数据库里查出相关内容拼进Prompt），条件分支映射为Java的if/else或策略模式，工具节点映射为@Tool注解的函数调用。

我自己的建议是：验证阶段用路线一，快速看到效果；正式上线如果团队Java能力强，逐步把核心链路迁移成路线二，减少中间层依赖。翻译时最需要注意的是Dify节点里写的Prompt模板——里面的变量引用、系统提示词、few-shot示例，必须原封不动搬到Java代码里，任何一个空格差异都可能导致线上行为和画布演示时不一样。

5.3 MCP与A2A：Agent之间怎么协作

Spring AI 2.0里还有两个高频词：MCP和A2A。MCP（Model Context Protocol）解决的是“模型如何访问外部工具和数据”。以前每个AI应用要单独对接数据库、文件系统、第三方API，各家协议还不一样；MCP把工具调用约定成一个通用协议，模型开发者只需要实现一套接口，就能被多个模型复用。在Spring AI里，你可以用MCP客户端把外部服务包装成AI可调用的Tool。

A2A（Agent-to-Agent）是更上一层的协议，解决的是“Agent之间的通信”问题。单个Agent能力有限，实际业务可能要几个Agent协作：一个负责查天气，一个负责订餐，一个负责日程。A2A协议定义了Agent如何发现彼此、如何传递任务、如何共享上下文，Google在2025年把它捐给了Linux基金会，Spring AI也在跟进相关支持。对Java团队来说，这意味着一套跨语言、跨框架的Agent协作标准正在成形。

作为一个后端开发者，我的观察是：大模型时代的Java价值没有被削弱，反而更立体了。模型能生成文本，但系统还需要权限、审计、交易、数据一致性，这些恰恰是Java后端最擅长的领域。Spring AI做的，就是帮你把“模型能力”和“工程能力”焊在一起。

6. Spring高级面试题与实操避坑实录

6.1 高频面试题速答表

面试官问Spring相关的问题，翻来覆去就那么几类，但几乎每一道都可以往深处追问。下面我按“基础必问、进阶常问、压轴延伸”三档整理：

备考的时候，不要只背答案，要把每个答案都手写一遍小Demo验证。比如“事务什么情况下失效”，可以在本地写一个类内部自调用的方法，打上@Transactional，故意抛出异常，观察数据有没有回滚。做过一遍，你就永远不会忘。

6.2 我在真实项目里踩过的坑

第一个坑，事务不生效。现象是接口报错后数据照样写入了。原因有三个，八成是同类内部方法自调用，其次是方法非public，最后是异常被try/catch吞掉没有抛出。排查顺序建议：优先查异常有没有被吃掉，再查是不是自调用，最后看方法访问修饰符。我甚至见过有人把@Transactional写在Controller层上，那也是无效的，Spring默认不对Controller做事务代理。

第二个坑，循环依赖突然启动失败。项目升级Spring Boot 2.6之后，启动直接报The dependencies of some of the beans in the application context form a cycle。老代码里互相注入点多，只能一个个拆。我的拆分手法是：如果A只需要B的一个方法，就把这个方法移到新类C，A和B都依赖C；如果A和B确实是强关联业务，可以引入事件机制让A监听B的状态变化，把“调用依赖”改成“事件依赖”。

第三个坑，多环境配置覆盖混乱。application.yml、application-dev.yml、application-prod.yml加载优先级很多新手搞混。Spring Boot的加载顺序是：jar包外的application.yml会覆盖jar包内的，命令行参数会覆盖一切。如果线上配置总是不生效，大概率是你在启动参数或环境变量里覆盖了，或者配置中心（比如Nacos）里的配置优先级更高。建议团队统一约定：环境相关配置统一放配置中心，本地application.yml只保留公共默认值。

第四个坑，MyBatis与Spring Boot版本兼容。MyBatis Starter的版本和Spring Boot版本要匹配，否则启动时可能会出现Property 'sqlSessionFactory' or 'sqlSessionTemplate' are required。我的习惯是去MyBatis官方GitHub找到对应Spring Boot版本的Starter版本，不要闭着眼睛用最旧或最新的。

6.3 Spring版本选择与框架源码下载，别追最新

Spring Framework版本号演进节奏很快，但我的选型原则非常保守：公司新项目用Spring Boot 3.x（基于Spring Framework 6），老项目维持Spring Boot 2.7（对应Spring Framework 5.3.x）不要轻易大版本升级。5.3基于javax命名空间，6.x基于jakarta命名空间，这种基础命名空间切换意味着整个项目的依赖都要跟着换，不是改改pom就完事的。

如果你是想看源码，下载Spring Framework 5.3.41这种具体版本，最靠谱的方式是去Maven中央仓库搜索spring-framework，选择对应版本的-sources.jar下载，然后用IDEA打开即可。不需要去官方主站找Git下载，Maven仓库里的源码包和发布包永远是匹配的。看源码时不要从ApplicationContext开始，那个入口太高级，信息量太大。建议从ClassPathXmlApplicationContext（老版本）或一个最小的AnnotationConfigApplicationContext开始，跟着refresh()方法一路往下走，走到哪算哪，逐层理解。

7. 最后，分享几点我自己的体会

做技术分享这么些年，我发现一个规律：Spring全家桶的知名度有多高，劝退率就有多高。资料太多，版本太乱，新旧概念交织，很多初学者很容易陷入“学不完”的焦虑中。但如果你退一步看，Spring跨过二十多年始终没变的就两件事：管理对象和装配依赖。把IoC和AOP理解透了，Boot的自动配置、Cloud的服务治理、AI里的工具调用，全都可以理解为这两个思想的延伸。

我自己的学习方法是“主线优先”：先通过Boot做出一个能跑的Web项目，再用一级级往下拆——看自动配置源码，看Bean创建流程，看事务如何生效，最后再回到手写MiniSpring来收口。这个过程不求快，但每过一层，你对框架的掌控感就会强一分。遇到不理解的，我就跑一个最小Demo出来，把断点打到源码里看变量变化，比看任何文章都有效。

如果你现在正处于“大概会用但心里没底”的阶段，这篇文章提到的所有方向，其实只需要挑一个点动手做一遍即可。比如就写一个最简单的Spring Boot应用，打开自动配置的debug=true日志，认认真真看一遍哪些自动配置生效了，然后追问三个为什么。一个点吃透之后，剩下的路线自己就会出现在你面前。这二十多年里Spring一直在变，但这种“用最小实验验证一个核心概念”的学习路径，从未变过。