Spring MVC：如何在父对象更新前校验嵌套对象的ID是否存在

方案1：自定义类型转换器 + 捕获绑定错误（最优适配你的场景） #

该方案直接在数据绑定阶段执行校验，不会产生无效实例，完全符合你要求的「绑定阶段校验」需求。

实现步骤 #

1. 自定义Converter<String, Owner>，转换失败直接抛出异常：

@Component
public class StringToOwnerConverter implements Converter<String, Owner> {

    @Autowired
    private OwnerRepository ownerRepository;

    @Override
    public Owner convert(String source) {
        // 空值直接返回null，对应用户主动清空Owner的合法场景
        if (source == null || source.isBlank()) {
            return null;
        }
        try {
            int ownerId = Integer.parseInt(source);
            return ownerRepository.findById(ownerId)
                    // 查不到直接抛出异常，Spring会自动记录为绑定错误
                    .orElseThrow(() -> new IllegalArgumentException("无效的Owner ID：" + source));
        } catch (NumberFormatException e) {
            throw new IllegalArgumentException("Owner ID必须为数字");
        }
    }
}

2. Spring MVC会自动识别这个Converter，转换失败时会将错误信息写入BindingResult，你只需要在控制器中优先判断绑定错误即可：

@PostMapping("updatePet")
public String updatePet(@Validated Pet pet, BindingResult bindingResult) {
    // 先判断绑定错误（包含Owner ID不存在的错误）
    if (bindingResult.hasErrors()) {
        return "editPet";
    }
    petRepository.save(pet);
    return "redirect:/editPet";
}

3. 前端可以直接取出该错误提示给用户，完全符合业务预期：用户主动清空Owner ID会正常绑定为null，输入无效ID会直接返回错误提示，不会出现无感知置空的问题。

方案2：新增原始输入字段做对比校验（无全局改动，适合局部场景） #

如果你不想修改全局的类型转换逻辑，可以在表单中新增一个隐藏/显式的ownerIdInput字段，提交后通过原始输入值和绑定结果对比判断：

实现步骤 #

1. 表单中调整字段定义：

<!-- 原owner ID输入框，名字改为ownerIdInput，不再直接绑定到pet.owner -->
<input type="text" name="ownerIdInput" th:value="${pet.owner?.id}">

2. 控制器中手动校验：

@PostMapping("updatePet")
public String updatePet(@Validated Pet pet, BindingResult bindingResult, 
                        @RequestParam(required = false) String ownerIdInput) {
    // 校验Owner ID输入
    if (ownerIdInput != null && !ownerIdInput.isBlank()) {
        if (pet.getOwner() == null) {
            // 输入了ID但绑定结果为null，说明ID无效
            bindingResult.rejectValue("owner", "owner.invalid", "输入的Owner ID不存在");
            return "editPet";
        }
    }
    petRepository.save(pet);
    return "redirect:/editPet";
}

该方案不需要调整全局转换逻辑，只针对当前业务场景做局部适配，侵入性更低。

避坑说明 #

你之前尝试的返回无效Owner实例的方案确实不推荐，上述两种方案都不会产生无效的持久化对象，完全兼容框架本身null值的安全处理逻辑，同时满足无效ID的校验需求。

内容的提问来源于stack exchange，提问作者kosmasd