这种代码，几乎所有项目都有：

if (id == null) {
    throw new RuntimeException("id 不能为空");
}
if (name == null || name.isBlank()) {
    throw new RuntimeException("name 不能为空");
}

一个方法一两行，看着没什么问题。 但当这种判断：

• 出现在每个新增方法
• 出现在每个修改方法
• 出现在每个查询方法

代码的噪音会非常大。

实际上，这类判断完全可以统一前移，而不是写在业务逻辑中。

参数合法性，本质上是输入问题，而不是业务问题。

例如：

• 是否为空
• 长度是否合法
• 数值范围是否合理

这些判断：

• 和具体业务无关
• 规则稳定
• 不应该污染核心逻辑

统一处理后，业务代码只关心一件事：参数是可信的。

很多业务方法，一上来就是：

Pet pet = petMapper.selectById(id);
if (pet == null) {
    throw new RuntimeException("数据不存在");
}

这类判断看似合理，但问题在于：

• 每个方法都在查一次
• 每个方法都在写同样的判断
• 异常信息还可能不统一

更糟的是，有些地方忘了写，有些地方写得不一样。

“数据是否存在”本身是一个通用规则，不是某个业务的专属逻辑。

这是业务代码里最容易膨胀的一类。

if (status != Status.INIT) {
    throw new RuntimeException("当前状态不允许操作");
}

刚开始只有一个地方用，没问题。 后来你会发现：

• A 操作判断一次
• B 操作判断一次
• C 操作判断一次

而且判断条件还略有差异。

这种判断如果完全散落在业务代码里，后期几乎一定会出问题。

说清楚一点：不是所有判断都适合统一处理。

下面这些判断，最好还是留在业务代码中：

• 强业务规则判断
• 和当前功能强相关的流程判断
• 需要结合多步业务上下文的判断

比如：

if (isFirstAdopt && userAge < 18) {
    // 特殊业务限制
}

这种判断，本身就属于业务表达，统一反而会降低可读性。

当你把“通用判断”抽出去之后，业务方法通常会变成这样：

public void update(UpdatePetDTO dto) {
    Pet pet = loadAndCheck(dto.getId());
    checkUpdatable(pet);
    doUpdate(pet, dto);
}

代码的变化不是变“少”，而是变“干净”：

• 每一行都有业务含义
• 没有重复的防御性判断
• 出问题时定位非常快

如果你在写判断时，心里出现过这种想法：

“这个判断别的地方好像也写过”

那它大概率就该被统一。

再给你一个更狠但好用的判断方式：

这个判断，是“所有人都要遵守的规则”，还是“这个功能才需要的规则”？

• 所有人都要遵守 → 可以统一
• 只有这个功能需要 → 留在业务里

这个判断，在真实项目里几乎不会翻车。

很多人担心： 统一处理会不会不灵活？

恰恰相反。

当判断逻辑：

• 集中
• 明确
• 有固定入口

你反而更清楚：

• 哪些规则是全局的
• 哪些规则是局部的
• 改动会影响到哪里

最危险的不是统一，而是“大家各写各的”。

        业务代码乱，往往不是因为业务复杂， 而是因为不该出现在那里的判断，出现得太多了。把“通用判断”从业务代码里拿走， 留下的，才是真正需要你思考的业务。