聊到“Spring中集成Hibernate”，很多人的第一反应可能是：这都什么年代了，Spring Boot + JPA一把梭不香吗？这话没毛病，但我在实际维护老项目和排查线上问题时发现，真正理解Spring和Hibernate这两个框架是怎么“咬合”在一起的人，其实不多。尤其是碰到Could not open Hibernate session for transaction这类经典异常时，不会看底层涉及的三方组件——SessionFactory、事务管理器、Session绑定关系——就只能靠重启大法碰运气。

这篇内容，我不打算讲那种照本宣科的官方文档翻译。我会以一次真实项目里的集成过程为主线，把版本选型、依赖配置、SessionFactory托管、事务边界设计、常见异常排查，包括Spring Boot场景下Hibernate的新玩法，都掰开揉碎了讲一遍。不管你是刚学SSH的老派新手，还是在Spring Boot里被JPA“自动配置”惯坏了想补齐底层知识的开发者，这篇文章应该都能给你一些实操层面的参考。

1. 集成前的版本选型与依赖管理

1.1 为什么Spring和Hibernate需要“集成层”

先想明白一个底层问题：Hibernate本身是独立的ORM框架，它有自己的一套配置、会话管理和事务体系；Spring则是一个容器框架，负责对象创建、依赖注入和声明式事务。两者要协同工作，关键不在于“把Hibernate的类交给Spring管理”这么简单，而在于两个框架的会话生命周期和事务边界必须统一。

Hibernate的原生开发模式里，你需要手动做这几件事：创建Configuration、解析映射、构建SessionFactory、每次操作前openSession、在finally里closeSession。这套流程放在Spring容器里会有几个痛点：SessionFactory创建过程重复且浪费资源、Session生命周期没人统一管理、事务提交回滚逻辑散落在业务代码里。所以Spring提供了spring-orm模块，里面包含LocalSessionFactoryBean和HibernateTransactionManager，前者负责把SessionFactory的构建过程收编进容器，后者负责把Hibernate的事务纳入Spring的声明式事务管理体系。你后面看到的所有集成配置，本质上都是围绕这两个核心类转。

1.2 框架版本对应关系速查

版本选型是集成Hibernate的第一道坎，也是我见过翻车率最高的地方。你用Spring 6配Hibernate 5.2，编译期可能不报错，运行期直接给你NoClassDefFoundError: javax/persistence/Entity——因为Hibernate 6已经全面切换到Jakarta命名空间，把javax.persistence换成了jakarta.persistence，而Spring 6也同步做了这个迁移。所以版本搭配不能随便来。

我自己维护的老项目至今还在Spring 5.3.x + Hibernate 5.6.15.Final这个组合上，稳定跑了三年多。新项目如果起步，直接用Spring Boot 3.x + Hibernate 6也是可以的，但要注意实体类注解的import路径变化，以及hibernate.properties里一些过时配置项的移除。

1.3 Maven依赖的最小集合

以经典的非Boot项目为例，pom.xml里最精简的依赖组合是：

<dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>5.3.31</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-orm</artifactId> <version>5.3.31</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-core</artifactId> <version>5.6.15.Final</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> <scope>runtime</scope> </dependency> <dependency> <groupId>com.zaxxer</groupId> <artifactId>HikariCP</artifactId> <version>4.0.3</version> </dependency>

spring-context提供IoC容器核心能力，spring-orm提供集成Hibernate的适配类，hibernate-core是ORM引擎本体。这里有个隐藏点：为什么Spring没有把Hibernate依赖内嵌到spring-orm里？因为ORM框架是可选集成项，Spring需要同时兼容Hibernate、MyBatis、JPA等多种方案，所以依赖维度上必须由使用者自己声明。你还需要一个连接池，HikariCP在性能和稳定性上都优于老牌的DBCP和C3P0，Spring的默认数据源策略也倾向HikariCP，这个选择不用犹豫。

2. 核心配置设计与背后的原理逻辑

2.1 LocalSessionFactoryBean到底做了什么

很多资料把LocalSessionFactoryBean简单描述成“Spring提供的SessionFactory工厂类”，这个说法不够深入。它的完整职责是：读取你配置的数据源、实体扫描路径、方言等属性，代替你手动创建Hibernate的Configuration对象，然后构建出SessionFactory，并把这个重量级单例放入Spring容器。

关键在于，LocalSessionFactoryBean本身是一个FactoryBean<SessionFactory>，Spring容器从它这里拿到的不是这个Bean本身，而是它getObject()方法返回的SessionFactory实例。你可以在任何需要的地方直接注入SessionFactory，就像它是一个普通Bean一样，实际上背后是工厂产品。这种间接层带来的好处是，SessionFactory的构造时机、初始化失败处理、单例生命周期全部交给容器控制。

用XML方式配置时，核心逻辑长这样：

<bean id="dataSource" class="com.zaxxer.hikari.HikariDataSource"> <property name="jdbcUrl" value="jdbc:mysql://localhost:3306/test_db"/> <property name="username" value="root"/> <property name="password" value="123456"/> <property name="driverClassName" value="com.mysql.cj.jdbc.Driver"/> </bean> <bean id="sessionFactory" class="org.springframework.orm.hibernate5.LocalSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="packagesToScan" value="com.example.entity"/> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect">org.hibernate.dialect.MySQL8Dialect</prop> <prop key="hibernate.show_sql">true</prop> <prop key="hibernate.format_sql">true</prop> <prop key="hibernate.hbm2ddl.auto">update</prop> </props> </property> </bean>

这里需要解释两个参数。packagesToScan指定实体类扫描包路径，Hibernate会自动把这个包下所有标注了@Entity的类注册到映射配置里，省去了早期hbm.xml映射文件的手工维护。hibernate.hbm2ddl.auto设置为update表示启动时自动比对实体类和数据库表结构并更新，开发环境方便，生产环境我强烈建议改为validate或者干脆关掉，理由在后面常见问题里展开。

2.2 事务管理器的选型与事务绑定机制

Spring集成Hibernate的事务管理器是HibernateTransactionManager，配置时把它挂到你前面创建的sessionFactory上：

<bean id="txManager" class="org.springframework.orm.hibernate5.HibernateTransactionManager"> <property name="sessionFactory" ref="sessionFactory"/> </bean> <tx:annotation-driven transaction-manager="txManager"/>

<tx:annotation-driven>的作用是启用@Transactional注解驱动，Spring容器会扫描标注了该注解的Bean，为它们生成事务代理对象。这个配置默认会去找容器里名为transactionManager的Bean，所以如果你的Bean名不叫这个，必须显式指定transaction-manager属性。

事务绑定的核心机制是：HibernateTransactionManager在事务开始时，调用sessionFactory.getCurrentSession()获取一个与当前线程绑定的Session，这个绑定关系是Hibernate内部通过ThreadLocal实现的。后续所有DAO操作拿到的都是同一个Session，事务提交时统一flush并提交，异常时统一回滚并关闭资源。这也就是为什么DAO层的代码不需要手动openSession和closeSession——生命周期被事务管理器接管了。

Java Config方式等价配置如下，这也是我目前在新一些的非Boot项目里更推荐的做法：

@Configuration @EnableTransactionManagement @ComponentScan("com.example") public class AppConfig { @Bean public DataSource dataSource() { HikariDataSource ds = new HikariDataSource(); ds.setJdbcUrl("jdbc:mysql://localhost:3306/test_db?useSSL=false&serverTimezone=Asia/Shanghai"); ds.setUsername("root"); ds.setPassword("123456"); ds.setDriverClassName("com.mysql.cj.jdbc.Driver"); return ds; } @Bean public LocalSessionFactoryBean sessionFactory() { LocalSessionFactoryBean factory = new LocalSessionFactoryBean(); factory.setDataSource(dataSource()); factory.setPackagesToScan("com.example.entity"); Properties props = new Properties(); props.setProperty("hibernate.dialect", "org.hibernate.dialect.MySQL8Dialect"); props.setProperty("hibernate.show_sql", "true"); props.setProperty("hibernate.hbm2ddl.auto", "update"); factory.setHibernateProperties(props); return factory; } @Bean public HibernateTransactionManager transactionManager() { HibernateTransactionManager tm = new HibernateTransactionManager(); tm.setSessionFactory(sessionFactory().getObject()); return tm; } }

注意transactionManager里我调用的是sessionFactory().getObject()，而不是直接把LocalSessionFactoryBean实例传进去。因为LocalSessionFactoryBean是工厂Bean，getObject()返回的才是真正要用的SessionFactory。在Java Config中直接用sessionFactory()方法返回的Bean实例传给事务管理器，容器会自动完成工厂产品的解引用，但为了明确意图，显式调用getObject()更不容易出错。

3. 从零搭建一个Spring + Hibernate的完整示例

3.1 实体类与映射注解

假设我们做一个员工管理场景，实体类放在com.example.entity包下：

package com.example.entity; import javax.persistence.*; import java.io.Serializable; import java.util.Date; @Entity @Table(name = "t_employee") public class Employee implements Serializable { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "id") private Long id; @Column(name = "name", nullable = false, length = 64) private String name; @Column(name = "department") private String department; @Temporal(TemporalType.TIMESTAMP) @Column(name = "create_time") private Date createTime; // getter/setter 略 }

这里的注解用的是javax.persistence包，因为咱们现在还是Hibernate 5时代。如果你用的是Hibernate 6，记得把import改成jakarta.persistence。@GeneratedValue(strategy = GenerationType.IDENTITY)对应MySQL的自增主键，加上方言配置的配合，Hibernate插入时会自动省略主键字段并把生成的主键回填到实体对象。@Temporal(TemporalType.TIMESTAMP)在字段类型为java.util.Date时必须显式标注，否则数据库列类型可能被映射成date而不是datetime，这个细节很容易被忽略。

3.2 DAO与Service分层设计

DAO层的核心思路是直接操作SessionFactory获取当前线程绑定的Session：

@Repository public class EmployeeDao { @Autowired private SessionFactory sessionFactory; private Session getSession() { return sessionFactory.getCurrentSession(); } public void save(Employee employee) { getSession().save(employee); } public Employee findById(Long id) { return getSession().get(Employee.class, id); } public List<Employee> findAll() { return getSession().createQuery("from Employee", Employee.class).list(); } public void update(Employee employee) { getSession().update(employee); } public void delete(Employee employee) { getSession().delete(employee); } }

注意getCurrentSession()返回的Session必须在事务上下文中使用，否则会报Could not obtain transaction-synchronized Session。这个设计不是缺陷，而是强制你把数据访问放入事务边界内，避免Session泄漏。如果你确实有只读查询不想开启事务，可以用openSession()手动操作并在finally里关闭，但绝大多数场景下走事务是更稳妥的。

Service层负责事务边界管理与业务逻辑：

@Service public class EmployeeService { @Autowired private EmployeeDao employeeDao; @Transactional(readOnly = true) public Employee getEmployee(Long id) { return employeeDao.findById(id); } @Transactional public Long createEmployee(String name, String department) { Employee employee = new Employee(); employee.setName(name); employee.setDepartment(department); employee.setCreateTime(new Date()); employeeDao.save(employee); return employee.getId(); } @Transactional public void changeDepartment(Long id, String newDept) { Employee employee = employeeDao.findById(id); employee.setDepartment(newDept); employeeDao.update(employee); } }

这里有两个值得注意的事务配置点。getEmployee标注了readOnly = true，提示事务管理器走只读路径，Hibernate会做一些session flush的优化，但MySQL方言下效果有限，更大意义是语义清晰。changeDepartment方法中，findById返回的实体处于持久态，理论上修改字段后事务提交时Hibernate会自动脏检查更新，不需要显式调用update，不过显式调用也不会有副作用，代码意图更明确，我在老项目里保留了这个习惯。

3.3 启动容器与验证运行

用Java Config方式启动，测试代码如下：

public class MainApp { public static void main(String[] args) { AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class); EmployeeService service = ctx.getBean(EmployeeService.class); Long id = service.createEmployee("张三", "研发部"); System.out.println("生成主键: " + id); Employee emp = service.getEmployee(id); System.out.println("查询结果: " + emp.getName() + " - " + emp.getDepartment()); service.changeDepartment(id, "产品部"); Employee updated = service.getEmployee(id); System.out.println("更新结果: " + updated.getDepartment()); ctx.close(); } }

运行后观察控制台Hibernate打印的SQL，你会发现三条操作对应各自的insert、select、update语句。这就是show_sql开启的效果，它能让你直观感受Hibernate在背后执行的SQL，对于排查懒加载、N+1查询等问题是不可或缺的工具。我个人的习惯是开发环境打开show_sql和format_sql，并配合日志输出绑定参数，生产环境关闭。

4. 集成过程中最常见的六个坑与排查实录

4.1Could not open Hibernate session for transaction的完整拆解

这个异常基本是所有SSH集成者的第一道鬼门关，它的完整信息通常是：

org.springframework.transaction.CannotCreateTransactionException: Could not open Hibernate session for transaction; nested exception is org.hibernate.exception.GenericJDBCException: Unable to acquire JDBC Connection

我在排查过大量此类问题后，总结出三层原因定位法。第一层：连接池是否正常？看异常堆栈的最深层，如果是连接超时、Access denied、Unknown database这类，先确认数据库连通性、账号权限、JDBC URL的时区与SSL配置。MySQL 8的URL必须带serverTimezone=Asia/Shanghai，否则会因时区问题连不上。第二层：事务管理器是否正确绑定SessionFactory？如果报No Hibernate Session bound to thread或者提示无法获取当前Session，检查HibernateTransactionManager的sessionFactory属性是否指向了由LocalSessionFactoryBean.getObject()产出的那个实例。第三层：事务注解是否真的生效？如果Service类没被Spring扫描到、或者方法被private修饰，@Transactional不会起作用，Session也就不会被事务管理器绑定。

曾经有个同事在XML配置里把sessionFactoryBean的id写成了sf，事务管理器的name指向没问题，但忘了改<tx:annotation-driven transaction-manager="txManager"/>里的名字，导致Spring在容器里找不到名为transactionManager的Bean，直接启动失败。这类低级错误在XML时代特别常见，换成Java Config后大部分能被编译器提前发现，这也是我推荐新项目使用注解配置的原因之一。

4.2SessionFactory获取Session的两种方式之争

Hibernate提供openSession()和getCurrentSession()两个方法获取Session，两者在集成后有着完全不同的生命周期语义。openSession()每次都会创建全新的Session，你必须手动close，事务边界需要自己控制。getCurrentSession()获取的是与当前事务线程绑定的Session，由事务管理器统一管理，事务结束自动关闭，前提是当前确实处于事务上下文。

很多初学者在DAO里习惯用openSession()，然后发现每次查询后返回的对象脱离了Session上下文，紧接着访问懒加载属性就抛LazyInitializationException。这正是没有理解两种方式差异导致的结果。在Spring集成场景下，DAO层务必统一使用getCurrentSession()，把Session生命周期完全交给Spring容器管理。如果你需要用编程式事务，那另当别论，但那是少数场景。

4.3Unknown entity异常：实体扫描的隐蔽坑

报错长这样：

org.hibernate.MappingException: Unknown entity: com.example.entity.Employee

最常见原因是packagesToScan配置的包路径和实体类实际所在包不一致，比如实体类在com.example.domain，配置扫描写成了com.example.entity。另一种隐蔽情况是实体类没有标注@Entity注解，Hibernate扫描时不会注册它。还有一种情况，就是多个LocalSessionFactoryBean共用同一个数据源，但各自的扫描路径配置不一致——这种现象在分库分表的老系统里见过，每个SessionFactory只认自己扫描到的实体，跨SessionFactory查询就报Unknown entity。

排查这类问题，最快的方式是在Hibernate初始化日志里看一列：Hibernate: bind entity [com.example.entity.Employee]或类似信息。如果日志里根本没有这一行，说明实体压根没有被扫描到，直接去核对扫描路径和注解。

4.4 懒加载与N+1查询：性能隐患的两兄弟

Hibernate最大的特点是支持懒加载，比如查询部门时，部门的员工列表默认不会马上查出来，而是等你实际访问时才触发SQL。这在单个实体查询时很高效，但在循环中访问每条的关联集合时会退化为经典的N+1问题：先查N条部门记录，再每条部门各发一条查询员工SQL，一共N+1条SQL，性能断崖式下跌。

解决方案我按优先级排一下。第一，业务场景确实需要关联数据时，在HQL中用left join fetch或join fetch一次性查出来，这是性能和代码最干净的方式：

String hql = "select d from Department d left join fetch d.employees";

第二，如果不想改查询语句，在实体映射的@OneToMany(fetch = FetchType.EAGER)上设置饥渴加载，但这样会让所有场景都加载关联数据，单条查询时反而浪费。第三，借助Hibernate的batch_size和default_batch_fetch_size配置，把N+1降为N/batch+1，这是改动最小的优化手段。default_batch_fetch_size设置在hibernateProperties里，一般建议16、32或64，我见过很多项目从这个参数上白捡了可观的性能提升。

懒加载的另一个常见坑是LazyInitializationException，错误信息大概是：

failed to lazily initialize a collection, no session or session was closed

原因很简单：Session在事务提交后关闭了，但你持有的实体对象上了懒加载的关联属性还没初始化。解决办法有三种：事务边界内完成所有关联访问（最正统）；在web应用中配置OpenSessionInView拦截器（把Session生命周期延长到整个请求，Spring提供了OpenSessionInViewFilter，但代价是长事务和高内存占用，需要谨慎使用）；查询时用join fetch把数据主动查出来。我个人在非web场景（比如定时任务和批处理）坚决不用OSIV，在web场景也只在简单管理系统里用，复杂业务里宁可把查询写清楚，也不愿意让Session挂着不释放。

4.5 方言配置与DDL自动更新的生产环境警示

Hibernate方言hibernate.dialect是生成SQL的依据。MySQL 8必须用org.hibernate.dialect.MySQL8Dialect，用老版本的MySQL5Dialect会导致分页SQL语法错误或者部分函数不兼容。我曾经遇到一个项目，开发环境MySQL 5.7用的是MySQL5InnoDBDialect，升级数据库到MySQL 8后忘了同步升级方言，结果所有带LIMIT ? OFFSET ?的分页SQL全部报错，因为Hibernate按5.x方言生成了LIMIT ? OFFSET ?，MySQL 8也支持这种语法，但在某些老版本方言下会生成LIMIT offset, rows的旧写法，还是会有兼容性问题。所以升级数据库版本时，方言必须列入复核清单。

hbm2ddl.auto的值有none、update、validate、create、create-drop五个选项。开发环境可以用update，Hibernate会自动比对实体类和数据库表结构，把缺的表和列自动补上，甚至可以推断加索引。生产环境用update非常危险：Hibernate对列类型变更、索引重构等操作有时会做不完整的推断，而且每次启动都要扫描全库表结构比较，启动变慢。生产环境推荐validate，启动时校验映射和实际表结构的一致性，不一致直接报错，这能第一时间暴露数据库和代码不同步的问题。

4.6 连接池与数据库断连的经典故障

生产环境长时间运行后，第二天早上第一个请求偶尔卡住几秒甚至报连接异常，这个现象十有八九是数据库端主动断开了空闲连接，而连接池里的连接自己还不知道。MySQL的wait_timeout默认8小时，空闲超过8小时的连接会被服务端关闭。HikariCP默认的池内连接生命周期很长，不知道对外连接已经被数据库回收了，于是取出这种“僵死连接”去执行SQL时报通信异常。

三个层面的解决方案叠加使用效果最稳。数据库层面，确认wait_timeout、interactive_timeout的合理值。连接池层面，HikariCP配置connection-test-query或者利用JDBC4的isValid()方法做连接活性检测，再设置合理的connectionTimeout、idleTimeout、maxLifetime。maxLifetime要小于数据库的wait_timeout，社区经验是数据库8小时，HikariCP的maxLifetime设到5~6小时比较安全。Hibernate层面，可以在hibernateProperties里配置hibernate.connection.isolation和hibernate.connection.autocommit，但重点还是连接池的健康检查。我这里给一个经过生产验证的HikariCP配置作为参考：

spring: datasource: hikari: connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000 maximum-pool-size: 20 minimum-idle: 5 connection-test-query: SELECT 1

maximum-pool-size不必开太大，20够大多数中小规模业务使用。连接池大小和数据库连接数是两个独立维度，盲目调大连接池在并发不高时反而是浪费，而且超过数据库上限反而引入连接管理开销。

5. Spring Boot时代的Hibernate集成新姿势

5.1 自动配置里的Spring + Hibernate

Spring Boot出现后，传统Spring XML装配Hibernate的方式被自动配置大幅简化。如果你用了spring-boot-starter-data-jpa这个起步依赖，哪怕代码里一行Hibernate配置都不写，Spring Boot也会通过HibernateJpaAutoConfiguration自动完成数据源创建、SessionFactory构建、事务管理器装配。它的底层仍然是前面说的那套机制：LocalContainerEntityManagerFactoryBean对应传统XML里的LocalSessionFactoryBean，JpaTransactionManager对应HibernateTransactionManager，只是换成了更通用的JPA规范接口。

核心配置浓缩到application.yml里几行：

spring: datasource: url: jdbc:mysql://localhost:3306/test_db?useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver jpa: hibernate: ddl-auto: update show-sql: true properties: hibernate: format_sql: true default_batch_fetch_size: 16

spring.jpa.hibernate.ddl-auto就是传统Hibernate属性的一个映射，它也有none、validate、update、create、create-drop相同的语义。Boot环境下如果你只引入了JPA起步依赖，但是既不配数据源URL，又不配driver，启动会直接失败，因为Spring Boot默认并没有内置数据库地址。

实体类的命名策略在Boot里如果不配置，默认是Spring的SpringPhysicalNamingStrategy，它会将驼峰命名的实体字段转换为下划线命名的数据库列，比如departmentName变成department_name。这个行为和原生Hibernate的默认命名策略有差异，从传统XML项目迁移到Boot项目时可能踩到表结构对不上的坑，需要在properties下显式指定：

spring: jpa: hibernate: naming: physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl

5.2 从传统XML迁移到Boot时的几个注意点

去年我把一个老的Spring XML项目迁移到Spring Boot 2.7，整体很顺利，但有三个细节记忆深刻。第一是实体扫描路径的变化，Boot下实体类默认扫描主启动类所在包及子包，老项目实体类如果放在不同包根路径下，必须用@EntityScan显式指定扫描路径。第二是事务管理器名称，传统XML你叫txManager完全没问题，Boot自动配置默认找transactionManager，如果你自定义了事务管理器且名字不一样，记得用@Primary或@Qualifier处理多事务管理器的歧义。第三是Hibernate属性里的过时项，比如hibernate.current_session_context_class在容器环境下不需要手动设置，Boot会替你配好，手动配置反而可能和自动配置冲突。

另外补充一点，如果你的项目原本引入的是spring-boot-starter-jdbc但没引入JPA，那么Hibernate核心库不会出现在classpath里，HibernateJpaAutoConfiguration也不会生效，你需要手动定义LocalSessionFactoryBean。如果项目里混用了MyBatis和Hibernate两个ORM框架，建议彻底划分清楚各自的数据源和事务管理器，不要在一个Service事务里同时操作两个ORM的DAO，否则事务边界会非常混乱，出了问题很难排查。

6. 最后的实操体会

回到这套Spring集成Hibernate的方案本身，我的体会是：框架搭配越老牌，底层机制越值得花时间吃透。你理解了LocalSessionFactoryBean是Spring容器和Hibernate引擎之间的翻译层，理解了HibernateTransactionManager通过ThreadLocal绑定Session和事务，线上那些奇形怪状的异常就都有了明确的排查路径。

建议拿到一个老项目，第一件事不是改代码，而是先把它的Bean定义和事务边界画出来：哪些Bean由容器管理，SessionFactory在哪儿注册，哪些方法标了事务注解，事务传播行为是什么。这些搞清楚了，后面不管是加表、改查询还是换连接池，心里都不会发怵。

至于工具链的选择，虽然现在Spring Boot + JPA是绝对的主流，传统XML装配方式看起来有些过时，但底层原理完全复用。年轻人入行如果只熟悉自动配置，遇到Could not open Hibernate session这类异常时往往无从下手，反而是那些被XML时代折磨过的老工程师一眼就能定位问题。所以这篇内容我不是想教你回到旧时代，而是想说：理解了底层的Session和事务绑定关系，你在任何框架版本面前都能游刃有余。