企业官网建设流程全解析

1. 项目概述：为什么在Spring Boot里还要同时聊JDBC和JPA？

在某高校后端开发实训课上，我带过一批刚学完Java基础、正啃《Spring实战》第4章的学生。第一周作业是“写个用户注册接口”，结果交上来的代码五花八门：有人用原生DriverManager.getConnection()手拼SQL，连PreparedStatement的?占位符都漏写；有人直接把@Entity类扔进@RestController返回JSON，数据库字段名和JSON键对不上还死活查不到原因；还有人卡在@Transactional不生效上，反复重启应用——其实就差一行@EnableTransactionManagement没加。这些不是理论漏洞，是真实踩出来的坑。

这恰恰说明一个问题：Spring Boot的自动配置再强大，也掩盖不了底层数据访问机制的本质差异。你用JdbcTemplate执行一条INSERT，和用JPA调用userRepository.save()，表面看都是“存数据”，但背后走的是两条完全不同的技术路径：前者是面向SQL的命令式操作，后者是面向对象的声明式映射。不厘清这个区别，就像开车不看仪表盘——油表见底了还在猛踩油门。

所以这篇内容不是教你怎么“选一个”，而是带你把JDBC和JPA放在同一张解剖台上，看清它们的肌肉走向、神经连接和供血路径。你会看到：

• JdbcTemplate如何把String sql = "INSERT INTO user(name, age) VALUES(?, ?)"这种字符串，安全地编译成预编译语句并绑定参数；
• SimpleJdbcInsert怎么通过反射读取实体类字段，自动生成INSERT INTO user (name, age) VALUES (:name, :age)这样的命名参数SQL；
• JPA的EntityManager如何在save()时触发一级缓存检查、脏数据检测、级联保存，甚至可能悄悄执行多条SQL；
• 当你需要批量插入10万条日志时，为什么JdbcTemplate.batchUpdate()比JpaRepository.saveAll()快3倍以上，而JPA却要开@Modifying+@Query才能绕过实体生命周期。

关键词全部落在“Spring Boot”“JDBC”“JPA”“JdbcTemplate”“SimpleJdbcInsert”这五个词上，没有一个跑偏。它适合三类人：刚从SSM框架转过来想搞懂Spring Boot数据层的同学、正在做性能压测发现DAO层拖后腿的工程师、以及需要给团队写内部技术规范的技术负责人。接下来，我们就从设计源头开始拆解。

2. 核心设计思路：为什么Spring Boot要保留两套数据访问方案？

2.1 JDBC与JPA的根本分歧：SQL驱动 vs 对象驱动

先说结论：JDBC是SQL的搬运工，JPA是对象的翻译官。这个比喻不是为了好记，而是直指核心。

JDBC（Java Database Connectivity）本质是一套标准API，定义了Connection、Statement、ResultSet这些接口。Spring的JdbcTemplate只是对它的封装——它不改变JDBC的DNA，只是帮你省去try-catch-finally里关连接的样板代码。你写的每一条SQL，最终都会原封不动地发给数据库执行。比如：

String sql = "SELECT id, name, email FROM user WHERE status = ? AND created_at > ?"; List<User> users = jdbcTemplate.query(sql, new BeanPropertyRowMapper<>(User.class), "ACTIVE", LocalDateTime.now().minusDays(7) );

这里sql字符串就是你的“命令”，jdbcTemplate.query()就是执行命令的“士兵”。士兵不会质疑命令是否合理，也不会帮你把User对象自动转成INSERT语句——它只忠实地执行你下达的每一行指令。

而JPA（Java Persistence API）是另一套哲学。它不关心SQL，只关心Java对象。你定义一个@Entity类：

@Entity @Table(name = "user") public class User { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(name = "user_name") private String name; @Column(name = "email_addr") private String email; }

然后调用userRepository.save(new User("张三", "zhang@example.com"))，JPA实现（如Hibernate）会干这些事：

1. 检查User对象是否在一级缓存中（避免重复加载）；
2. 判断id为null，确定这是新对象，走INSERT流程；
3. 根据@Table和@Column注解，拼出INSERT INTO user (user_name, email_addr) VALUES (?, ?)；
4. 绑定参数，执行SQL；
5. 把生成的主键值回填到User.id字段；
6. 将该对象放入一级缓存，后续同ID查询直接返回。

你看，你没写一句SQL，但背后发生了6步逻辑。这就是“对象驱动”的代价与收益：你获得开发效率，但失去对SQL执行路径的绝对控制权。

提示：很多初学者以为“用了JPA就不用写SQL了”，这是巨大误解。当JPA生成的SQL性能差（比如N+1查询）、或需要复杂关联更新时，你依然得写@Query原生SQL。JPA不是SQL的替代品，而是SQL的“高级调度员”。

2.2 Spring Boot的务实选择：不替你做决定，但给你最顺手的工具

Spring Boot的spring-boot-starter-jdbc和spring-boot-starter-data-jpa两个starter，并非互斥选项，而是分层供给：

• spring-boot-starter-jdbc提供JdbcTemplate、SimpleJdbcInsert、NamedParameterJdbcTemplate等，定位是轻量、可控、贴近SQL。它适合：

  • 报表类查询（大量GROUP BY、WINDOW FUNCTION）；
  • 批量数据迁移（从老系统导数据，字段映射复杂）；
  • 对性能极度敏感的场景（如金融交易日志写入，要求微秒级响应）；
  • 需要精确控制事务边界的场景（比如一个方法里既要更新订单又要调用第三方支付，必须保证两者原子性）。

• spring-boot-starter-data-jpa则提供JpaRepository、@Query、@EntityGraph等，定位是快速建模、减少样板、支持领域驱动。它适合：

  • CRUD为主的业务系统（CMS、OA、CRM）；
  • 需要快速迭代的MVP产品（用@Entity定义模型，几分钟就能生成REST API）；
  • 团队有较强领域建模能力（能合理设计@OneToMany、@ManyToMany关系）；
  • 需要审计、软删除、多租户等横切关注点（通过@MappedSuperclass统一注入）。

Spring Boot没强制你二选一，是因为现实项目从来不是非黑即白。我参与过的一个电商后台系统，商品管理模块用JPA（因为SKU、SPU、分类关系复杂），而订单对账模块用JdbcTemplate（因为要对比千万级订单表和银行流水表，需手写MERGE INTO语句）。这种混合模式才是工程常态。

2.3 JdbcTemplate与SimpleJdbcInsert的分工逻辑：谁该负责什么？

很多人把SimpleJdbcInsert当成JdbcTemplate的“升级版”，这是典型误区。它们解决的是不同维度的问题：

举个实际例子：假设你要插入用户，但邮箱字段允许为空，而数据库设了DEFAULT CURRENT_TIMESTAMP。用JdbcTemplate：

// 必须显式写出所有字段，空值用null占位 String sql = "INSERT INTO user(name, email, created_at) VALUES(?, ?, ?)"; jdbcTemplate.update(sql, "李四", null, LocalDateTime.now());

而SimpleJdbcInsert可以这样：

// 只传非空字段，created_at由数据库默认值填充 SimpleJdbcInsert insert = new SimpleJdbcInsert(jdbcTemplate) .withTableName("user") .usingGeneratedKeyColumns("id"); // 告诉它主键是自增的 Map<String, Object> params = new HashMap<>(); params.put("name", "李四"); // email没put，就相当于NULL；created_at没提，就用DEFAULT Number generatedId = insert.executeAndReturnKey(params);

看到区别了吗？JdbcTemplate像一把瑞士军刀，功能全但每用一次都要自己调校；SimpleJdbcInsert像一把专用螺丝刀，只干插入一件事，但拧螺丝又快又准。Spring Boot保留两者，正是因为它尊重不同场景下的“工具理性”。

3. 核心细节解析：手把手拆解JDBC与JPA的关键实操环节

3.1 JdbcTemplate的三大核心能力：查询、更新、批量操作

查询：BeanPropertyRowMapper不是万能的，但足够聪明

JdbcTemplate.query()最常用的RowMapper是BeanPropertyRowMapper，它通过反射将ResultSet列名映射到Java Bean属性。但这里有两个关键细节常被忽略：

第一，列名匹配规则：BeanPropertyRowMapper默认按snake_case转camelCase。比如数据库列user_name会自动映射到User.name字段（前提是User类有setName()方法）。但如果列名是USERNAME，它就找不到setUsername()——因为默认策略是underscore_to_camel_case。解决方案是显式指定：

BeanPropertyRowMapper<User> mapper = BeanPropertyRowMapper.newInstance(User.class); mapper.setCaseInsensitive(true); // 忽略大小写 mapper.setMappedClass(User.class); List<User> users = jdbcTemplate.query(sql, mapper, params);

第二，空值处理陷阱：如果数据库字段为NULL，而Java Bean属性是基本类型（如int age），BeanPropertyRowMapper会抛NullPointerException。必须改用包装类型Integer age。这是硬性约束，没有绕过办法。

更新：update()方法的返回值是黄金指标

JdbcTemplate.update()返回int，表示影响的行数。这个数字不是摆设，而是验证逻辑正确性的第一道防线：

// 删除用户前，先检查是否存在 String checkSql = "SELECT COUNT(*) FROM user WHERE id = ?"; int count = jdbcTemplate.queryForObject(checkSql, Integer.class, userId); if (count == 0) { throw new UserNotFoundException("用户不存在"); } // 执行删除 String deleteSql = "DELETE FROM user WHERE id = ?"; int affected = jdbcTemplate.update(deleteSql, userId); if (affected != 1) { // 如果返回0，说明WHERE条件没匹配到任何行 throw new RuntimeException("删除失败：未找到ID为" + userId + "的用户"); }

很多线上Bug就源于忽略这个返回值。比如你写UPDATE user SET status='DELETED' WHERE id=?，但id传错了，update()返回0，程序却继续往下走，导致业务状态不一致。

批量操作：batchUpdate()的两种姿势与性能真相

JdbcTemplate.batchUpdate()有两种重载：

1. batchUpdate(String sql, BatchPreparedStatementSetter pss)：适用于SQL相同、参数不同的场景（如批量插入用户）；
2. batchUpdate(String[] sql)：适用于SQL不同的场景（如一条INSERT、一条UPDATE混用）。

重点说第一种，因为它最常用也最容易出错：

// 错误示范：在循环里反复创建PreparedStatement List<User> users = getUsersToInsert(); for (User user : users) { String sql = "INSERT INTO user(name, email) VALUES(?, ?)"; jdbcTemplate.update(sql, user.getName(), user.getEmail()); // 每次都编译SQL！ } // 正确示范：用batchUpdate一次编译，多次执行 String sql = "INSERT INTO user(name, email) VALUES(?, ?)"; jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() { @Override public void setValues(PreparedStatement ps, int i) throws SQLException { User user = users.get(i); ps.setString(1, user.getName()); ps.setString(2, user.getEmail()); } @Override public int getBatchSize() { return users.size(); } });

性能差距有多大？实测1000条记录：

• 循环update()：耗时约850ms（每次编译+执行）；
• batchUpdate()：耗时约120ms（一次编译，1000次执行）。

原理很简单：数据库对预编译语句（Prepared Statement）有缓存机制。batchUpdate()让数据库只编译一次INSERT INTO user(name, email) VALUES(?, ?)，后续1000次都复用这个执行计划。而循环update()等于让数据库编译1000次相同的SQL，纯属浪费。

注意：batchUpdate()的批处理大小不是越大越好。MySQL默认max_allowed_packet=4MB，如果单条SQL参数太大，可能触发包超限。建议单批控制在100~500条，根据字段长度实测调整。

3.2 JPA的核心生命周期：save()背后隐藏的6个步骤

JpaRepository.save()看似简单，但它是JPA实体状态机的入口。理解这个状态机，是避免“数据没保存”“版本号冲突”等问题的关键。

JPA定义了四种实体状态：

• Transient（瞬时）：刚new出来的对象，没和EntityManager关联；
• Persistent（持久）：已调用save()或find()，在EntityManager一级缓存中；
• Detached（游离）：EntityManager关闭后，对象仍存在内存中；
• Removed（删除）：调用delete()后，等待flush()真正删除。

save()方法的行为取决于当前状态：

这就是为什么你有时save()后数据库没变化——因为对象已经是Persistent状态，且字段没变，JPA认为无需UPDATE。

更隐蔽的问题是Detached状态。比如你在Controller里查出一个User，传给Service层修改，再save()：

// Controller User user = userRepository.findById(1L).orElseThrow(); model.addAttribute("user", user); // 传给前端 // Service（在另一个事务里） user.setName("王五"); userRepository.save(user); // 这里user是Detached状态！

此时save()会先执行SELECT查一遍（因为要merge），再UPDATE。如果并发高，两次查询间数据被别人改了，就会覆盖别人的修改。正确做法是：

// 在Service里重新查一次（推荐） User dbUser = userRepository.findById(user.getId()).orElseThrow(); dbUser.setName(user.getName()); userRepository.save(dbUser); // 或者用@Version乐观锁（需User类加@Version Long version）

3.3 SimpleJdbcInsert的三个隐藏技巧：超越基础用法

SimpleJdbcInsert常被当作“玩具”，但它有几个生产环境真有用的技巧：

技巧一：动态表名与字段名

SimpleJdbcInsert支持运行时指定表名和字段，这对多租户场景极有价值。比如SaaS系统中，不同客户数据隔离在不同表：

// 表名格式：user_tenant_001, user_tenant_002... String tenantId = getCurrentTenantId(); String tableName = "user_tenant_" + tenantId; SimpleJdbcInsert insert = new SimpleJdbcInsert(jdbcTemplate) .withTableName(tableName) .usingGeneratedKeyColumns("id"); Map<String, Object> params = Map.of("name", "赵六", "email", "zhao@example.com"); Number id = insert.executeAndReturnKey(params);

技巧二：复合主键的优雅处理

当表有联合主键（如order_id + item_seq）时，SimpleJdbcInsert也能处理：

SimpleJdbcInsert insert = new SimpleJdbcInsert(jdbcTemplate) .withTableName("order_item") .usingColumns("order_id", "item_seq") // 显式指定主键列 .withSchema("sales"); // 指定schema Map<String, Object> params = Map.of( "order_id", 1001L, "item_seq", 1, "product_name", "iPhone 15", "quantity", 2 ); // executeAndReturnKey()返回CompositeKey对象，可强转 CompositeKey key = (CompositeKey) insert.executeAndReturnKey(params);

技巧三：批量插入的性能开关

SimpleJdbcInsert本身不支持批量，但可以结合JdbcTemplate.batchUpdate()使用：

// 先用SimpleJdbcInsert生成SQL模板 SimpleJdbcInsert insert = new SimpleJdbcInsert(jdbcTemplate) .withTableName("user") .usingGeneratedKeyColumns("id"); String sql = insert.getInsertString(); // 获取INSERT语句 // 再用batchUpdate执行 jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() { @Override public void setValues(PreparedStatement ps, int i) throws SQLException { User user = users.get(i); ps.setString(1, user.getName()); ps.setString(2, user.getEmail()); } @Override public int getBatchSize() { return users.size(); } });

这样既享受了SimpleJdbcInsert自动生成SQL的便利，又获得了batchUpdate()的批量性能。

4. 实操过程详解：从零搭建对比Demo，逐行分析执行效果

4.1 环境准备：最小化依赖与配置

我们用Spring Boot 3.2（最新稳定版）搭建一个极简项目，只引入必要依赖：

<!-- pom.xml --> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <scope>runtime</scope> </dependency> </dependencies>

H2数据库用于本地演示，配置application.yml：

spring: datasource: url: jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE driver-class-name: org.h2.Driver username: sa password: h2: console: enabled: true # 开启H2控制台，访问 http://localhost:8080/h2-console jpa: database-platform: org.hibernate.dialect.H2Dialect hibernate: ddl-auto: create-drop # 每次启动重建表，方便演示 show-sql: true properties: hibernate: format_sql: true

注意：ddl-auto: create-drop仅用于开发。生产环境必须设为validate或none，由Flyway/Liquibase管理DDL。

4.2 数据库建模：一张表，三种写法

我们只建一张user表，但用三种方式操作它，凸显差异：

CREATE TABLE user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL, email VARCHAR(100), status VARCHAR(20) DEFAULT 'ACTIVE', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

对应的Java实体：

@Entity @Table(name = "user") public class User { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(name = "name", nullable = false) private String name; @Column(name = "email") private String email; @Column(name = "status", length = 20) private String status = "ACTIVE"; @Column(name = "created_at") private LocalDateTime createdAt; @Column(name = "updated_at") private LocalDateTime updatedAt; // 构造函数、getter/setter省略 }

4.3 JDBC操作实录：JdbcTemplate与SimpleJdbcInsert的现场对比

场景一：单条插入，看SQL生成差异

写一个测试方法：

@Test void testInsertWithJdbcTemplate() { String sql = "INSERT INTO user(name, email, status) VALUES(?, ?, ?)"; int rows = jdbcTemplate.update(sql, "JDBC用户", "jdbc@example.com", "PENDING"); System.out.println("JdbcTemplate插入影响行数：" + rows); }

控制台输出：

Executing prepared SQL update Executed SQL update (1 row): INSERT INTO user(name, email, status) VALUES(?, ?, ?) JdbcTemplate插入影响行数：1

再试SimpleJdbcInsert：

@Test void testInsertWithSimpleJdbcInsert() { SimpleJdbcInsert insert = new SimpleJdbcInsert(jdbcTemplate) .withTableName("user") .usingGeneratedKeyColumns("id"); Map<String, Object> params = Map.of( "name", "SimpleJDBC用户", "email", "simple@example.com", "status", "PENDING" ); Number id = insert.executeAndReturnKey(params); System.out.println("SimpleJdbcInsert生成ID：" + id.longValue()); }

控制台输出：

Executing SQL statement [INSERT INTO user (name, email, status) VALUES (?, ?, ?)] Generated key: 2 SimpleJdbcInsert生成ID：2

关键发现：两者生成的SQL完全一样！SimpleJdbcInsert只是帮你省去了手写SQL和参数绑定的体力活，底层仍是JdbcTemplate。

场景二：批量插入，性能实测

我们插入1000条测试数据，分别用两种方式：

// JdbcTemplate.batchUpdate() long start = System.currentTimeMillis(); String sql = "INSERT INTO user(name, email, status) VALUES(?, ?, ?)"; jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() { @Override public void setValues(PreparedStatement ps, int i) throws SQLException { ps.setString(1, "BatchUser" + i); ps.setString(2, "batch" + i + "@example.com"); ps.setString(3, "ACTIVE"); } @Override public int getBatchSize() { return 1000; } }); long end = System.currentTimeMillis(); System.out.println("JdbcTemplate.batchUpdate 1000条耗时：" + (end - start) + "ms");

// JPA saveAll() start = System.currentTimeMillis(); List<User> users = IntStream.range(0, 1000) .mapToObj(i -> { User u = new User(); u.setName("JPAUser" + i); u.setEmail("jpa" + i + "@example.com"); u.setStatus("ACTIVE"); return u; }) .collect(Collectors.toList()); userRepository.saveAll(users); end = System.currentTimeMillis(); System.out.println("JPA saveAll 1000条耗时：" + (end - start) + "ms");

实测结果（H2内存数据库，本机Mac M1）：

• JdbcTemplate.batchUpdate：约95ms；
• JPA saveAll：约320ms。

差距主要来自JPA的开销：每条记录都要走EntityManager状态检查、一级缓存管理、脏数据检测。如果你的业务真的需要高频批量写入，JdbcTemplate是更务实的选择。

4.4 JPA操作实录：save()、saveAll()、@Query的执行路径剖析

场景一：save()的“静默更新”现象

写一个测试：

@Test void testSaveSilentUpdate() { // 先查出用户 User user = userRepository.findById(1L).orElseThrow(); System.out.println("查询到用户：" + user.getName() + ", 状态：" + user.getStatus()); // 修改状态 user.setStatus("INACTIVE"); // 再save userRepository.save(user); System.out.println("save后用户状态：" + user.getStatus()); }

控制台SQL输出：

select ... from user where id=? // 第一次查询 update user set ... where id=? // save时的UPDATE

注意：save()后user.getStatus()还是"INACTIVE"，但数据库已更新。这是因为JPA的save()是同步操作，执行完SQL立即生效。

场景二：saveAll()的N+1问题预警

saveAll()默认是逐条执行，但你可以开启批量：

# application.yml spring: jpa: properties: hibernate: jdbc: batch_size: 20 # 每20条合并为一个批次 order_inserts: true order_updates: true

开启后，1000条插入的SQL从1000条INSERT变成约50条（每批20条）。但注意：batch_size只对INSERT/UPDATE有效，DELETE仍逐条执行。

场景三：@Query原生SQL的不可替代性

当JPA无法满足复杂查询时，@Query是救命稻草。比如统计每个状态的用户数：

@Repository public interface UserRepository extends JpaRepository<User, Long> { @Query("SELECT u.status, COUNT(*) FROM User u GROUP BY u.status") List<Object[]> countByStatus(); // 或者用原生SQL @Query(value = "SELECT status, COUNT(*) FROM user GROUP BY status", nativeQuery = true) List<Object[]> countByStatusNative(); }

调用countByStatus()，JPA会生成：

select user0_.status as col_0_0_, count(*) as col_1_0_ from user user0_ group by user0_.status

而countByStatusNative()直接执行你写的SQL，不经过JPA解析。这是性能关键点：原生SQL绕过JPA的ORM层，执行更快，但失去数据库无关性。

5. 常见问题与排查技巧实录：那些文档里不写的坑

5.1 JDBC常见问题速查表

5.2 JPA经典陷阱与避坑指南

陷阱一：LazyInitializationException —— “懒加载异常”

现象：在Service层查出一个带@OneToMany关系的User，返回给Controller时抛org.hibernate.LazyInitializationException: failed to lazily initialize a collection。

原因：@OneToMany默认fetch = FetchType.LAZY，即用到时才查。但Controller层EntityManager已关闭，无法触发懒加载。

解决方案有三：

• 方案A（推荐）：用@EntityGraph在Repository层一次性查全

  @EntityGraph(attributePaths = {"orders", "addresses"}) List<User> findAllWithRelations();

• 方案B：在Controller层用Hibernate.initialize()强制初始化

  Hibernate.initialize(user.getOrders()); // 在返回前调用

• 方案C：改用FetchType.EAGER（不推荐，易引发N+1）。

实操心得：我在某电商项目里吃过亏。订单列表页要显示用户头像，User和Avatar是@OneToOne关系。一开始用EAGER，结果查100个订单，触发100次SELECT avatar。后来改成@EntityGraph，一次JOIN搞定，QPS从120升到380。

陷阱二：@Modifying + @Query的事务失效

现象：写了@Modifying @Query("UPDATE user SET status = ?1 WHERE id = ?2")，但执行后数据库没变化。

原因：@Modifying方法默认不开启事务，必须显式标注@Transactional。

解决方案：

@Transactional @Modifying @Query("UPDATE User u SET u.status = :status WHERE u.id = :id") int updateUserStatus(@Param("status") String status, @Param("id") Long id);

注意：@Modifying方法不能返回List或Page，只能返回int（影响行数）或void。

陷阱三：save()不触发数据库更新的“幽灵BUG”

现象：userRepository.save(user)后，数据库字段没变。

排查步骤：

1. 检查user对象的id是否为null？如果是，JPA认为是新对象，会INSERT而非UPDATE；
2. 检查user是否是Detached状态？用entityManager.contains(user)验证；
3. 检查字段是否真的被修改？JPA有脏检查机制，如果user.setName("张三")但原来就是"张三"，不会UPDATE；
4. 检查@Version字段是否冲突？并发修改时版本号不匹配会静默失败。

终极调试法：开启logging.level.org.hibernate.SQL=DEBUG和logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE，看JPA到底绑定了什么参数。

5.3 JDBC与JPA混合使用的协同要点

在真实项目中，JDBC和JPA常共存。这时要注意三点协同：

第一，事务管理器统一
必须用同一个PlatformTransactionManager。Spring Boot自动配置DataSourceTransactionManager，只要不手动定义多个事务管理器，就天然统一。

第二，一级缓存隔离
JdbcTemplate不走JPA的EntityManager，所以JdbcTemplate.update()修改的数据，JpaRepository.findById()可能查不到最新值（因为一级缓存没刷新）。解决方案：

• 调用entityManager.clear()清空缓存；
• 或用@Cacheable注解配合CacheManager做二级缓存；
• 最佳实践：读操作用JPA，写操作用JDBC，避免混合读写。

第三，数据库连接池共享
JdbcTemplate和JPA都用DataSource，所以HikariCP等连接池是共享的。这意味着JdbcTemplate.batchUpdate()占用的连接，会影响JPA的查询并发数。监控连接池活跃数（如/actuator/metrics/hikaricp.connections.active）是性能调优关键。

6. 性能与选型决策树：什么情况下该用哪个？

6.1 一张表看懂技术选型逻辑

6.2 实战决策树：跟着问题走，不跟概念走

遇到具体问题时，按此流程决策：

1. 第一步：问“这是读还是写？”

   • 读多写少 → 优先JPA（缓存友好）；
   • 写多读少 → 优先JDBC（无ORM开销）。

2. 第二步：问“SQL复杂吗？”

   • 简单WHERE条件 →