MySQL + Hibernate 连不上数据库，先查 hibernate.connection.url
格式对不对
最常见的连不上不是密码错，而是 JDBC URL 写成 MySQL 8 之前的格式。MySQL 8 默认启用
caching_sha2_password插件，老驱动不认，会报
Public Key Retrieval is not allowed或直接卡在连接超时。
正确写法（MySQL 8.0+ + Hibernate 5.4+）：
hibernate.connection.url=jdbc:mysql://localhost:3306/mydb?useSSL=false&serverTimezone=UTC&allowPublicKeyRetrieval=true&characterEncoding=utf8
allowPublicKeyRetrieval=true是关键，不加就拒绝握手
serverTimezone=UTC避免时区解析异常（比如报
The server time zone value '...' is unrecognized） 用
&而不是
&—— XML 或 properties 文件里写错会导致参数被截断
save() 和 persist() 看似一样，但 flush 时机决定是否立即发 SQL
两者都把对象变成持久态，但触发 INSERT 的时机不同：前者可能立刻执行 SQL（取决于当前 Session 是否已 flush），后者只保证在事务提交前 INSERT，更轻量。
典型误用场景：循环里反复调用
save()，每轮都可能触发一次 INSERT，性能崩；换成
persist()+ 手动
session.flush()控制节奏更稳。
save()返回生成的主键值，
persist()不返回（void） 如果 Session 已 dirty（有未刷数据），
save()可能顺带 flush 其他待更新对象，造成意外交互 JPA 规范只定义
persist()，
save()是 Hibernate 特有 API，跨框架迁移时建议优先用前者
LazyInitializationException 不是配置漏了，而是 Session 在 view 层就关了
报这个错，90% 情况不是
@OneToMany(fetch = FetchType.LAZY)写错了，而是 Controller 返回 JSON 时，Hibernate 已经关闭 Session，但 Jackson 还在反射 getter 触发代理加载。
解决路径很窄，别试“加
@Transactional到 service 外层”这种粗暴方案——它会让事务拖到视图渲染完，锁表风险高。 最稳：用
@EntityGraph显式声明需要 JOIN 的关联字段，一次查全 次选：DTO 手动拷贝，用
BeanUtils.copyProperties()或 MapStruct，彻底脱离实体代理 禁用：在
application.properties加
spring.jpa.open-in-view=true—— 它会让 Session 绑定整个 HTTP 请求，掩盖问题但埋下连接泄漏隐患
Hibernate 怎么知道该 UPDATE 还是 INSERT？靠的是对象的「持久化状态」，不是主键空不空
很多人以为
id == null就 INSERT，
id != null就 UPDATE，这是错觉。真正判断依据是 Session 缓存里有没有这个
id对应的已加载对象（即 persistent 状态）。你 new 出来一个 id=100 的对象直接
save()，Hibernate 仍当它是 transient，会 INSERT 并忽略你设的 id。
想强制 UPDATE 已存在记录，必须走
merge()：
MyEntity e = new MyEntity();
e.setId(100);
e.setName("new name");
session.merge(e); // 查缓存/DB，有则更新，无则 INSERT
merge()返回的是托管对象，原对象仍是 detached，别继续改原对象 如果确定主键一定存在且要覆盖，
load()+ set +
update()更高效（避免 merge 的两次查询） 使用
@GeneratedValue(strategy = GenerationType.IDENTITY)时，merge 无法跳过 INSERT 阶段，因为 ID 必须由 DB 生成
ORM 的核心不是“自动拼 SQL”，而是维护对象状态机与数据库行之间的映射关系。一旦脱离这个视角，所有“为什么没更新”“怎么多插了一条”的问题都会变成玄学。
