当用户邮箱作为外键被 addresses 表引用时，直接修改 users.email 会触发 PostgreSQL 外键约束异常；正确做法是在更新用户邮箱的同时，显式同步更新所有关联地址的 owner_email 字段。
当用户邮箱作为外键被 `addresses` 表引用时，直接修改 `users.email` 会触发 postgresql 外键约束异常；正确做法是在更新用户邮箱的同时，显式同步更新所有关联地址的 `owner_email` 字段。
该错误的根本原因在于：Address 实体通过 @JoinColumn(name = "owner_email", referencedColumnName = "email") 将 users.email 设为外键，而 PostgreSQL 默认启用 引用完整性检查 —— 即不允许更新或删除被其他表引用的主键/唯一键值。虽然 email 字段在 User 实体中并非主键（id 才是），但它被声明为 @Column(unique = true) 并作为外键目标，因此数据库层面仍强制执行约束。
CascadeType.ALL 对此无效，因为级联操作（如 PERSIST, MERGE, REMOVE）仅作用于 JPA 管理的关联对象生命周期（如 Address 实例），而 owner_email 是一个冗余映射字段（非实体引用），其值不会被 JPA 自动同步更新。
✅ 正确解决方案是在业务逻辑层显式维护一致性：
public void changeEmail(String email, String password, String newEmail) throws AuthenticationException {
try {
authenticationManager.authenticate(new UsernamePasswordAuthenticationToken(email, password));
User user = userRepository.findByEmail(email)
.orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND));
// 1. 更新用户邮箱
user.setEmail(newEmail);
// 2. 同步更新所有关联地址的 owner_email 字段
if (user.getAddresses() != null) {
user.getAddresses().forEach(address -> address.setOwnerEmail(newEmail));
}
// 3. 一次性持久化（JPA 会自动 flush 变更）
userRepository.save(user);
} catch (BadCredentialsException e) {
throw new ResponseStatusException(HttpStatus.FORBIDDEN);
}
}⚠️ 注意事项：
- 确保 Address 类中已定义 setOwnerEmail(String) 方法，并标记 @Column(name = "owner_email", insertable = false, updatable = false) 的字段仍可通过 setter 修改（JPA 允许对 insertable/updatable = false 的字段进行内存赋值，只要其对应列由其他机制（如 @ColumnTransformer 或手动 SQL）保障写入）；
- 若 addresses 使用 FetchType.LAZY，需在调用 getAddresses() 前确保 Session 未关闭（推荐在事务内执行，或使用 @Transactional 注解）；
- 更健壮的做法是结合数据库级 ON UPDATE CASCADE（需在建表时配置），但 Spring Data JPA 不自动创建该约束，需手动在 DDL 或 Flyway 迁移脚本中添加：
ALTER TABLE addresses DROP CONSTRAINT fkoixwfhgxuda232r3m5llu7few, ADD CONSTRAINT fkoixwfhgxuda232r3m5llu7few FOREIGN KEY (owner_email) REFERENCES users(email) ON UPDATE CASCADE;
- 若业务允许，可考虑改用 user_id 作为外键（即 @JoinColumn(name = "user_id")），避免对业务字段（如 email）的强依赖，提升数据模型稳定性。
总结：外键引用的业务字段变更必须“双写”——既更新主表，也同步更新从表中对应的外键列。这是领域逻辑与数据库约束协同设计的关键实践。
