Java案例深度复盘：那记搓射，代码层面真的“正确”吗？
目录导读
- 引言：从球场到键盘的隐喻
- 案例背景：一段“搓射”式的代码逻辑
- 技术拆解：用Java语法还原决策现场
- 多维评估：结果导向 vs 过程理性
- 问答环节：选择”的四个灵魂拷问
- 正确性从来不是非黑即白
从球场到键盘的隐喻
足球场上，一脚搓射（Chip Shot）往往在电光火石间决定成败——是挑过门将的轻盈，还是被扑出的懊悔，而在Java开发中，我们每天都在做类似的“搓射”选择：用哪种设计模式？是否该抛异常？缓存穿透时是回源还是降级？本文将通过一个真实Java案例，剖析“选择是否正确”这一命题的深层逻辑,并给出可落地的判断框架。
案例背景：一段“搓射”式的代码逻辑
假设我们有一个订单系统，核心方法是createOrder(OrderDTO dto)，在一次代码评审中,开发者小A写出了如下逻辑：
public boolean createOrder(OrderDTO dto) {
// 模拟“搓射”——直接尝试入库，若主键冲突则视为重复订单，返回false
try {
orderMapper.insert(dto);
return true;
} catch (DuplicateKeyException e) {
log.warn("重复订单，订单号：{}", dto.getOrderNo());
return false;
}
}
关键背景：该接口QPS高达2000，订单号由外部系统传入，极端情况下可能重复，团队内部争论焦点：用异常控制流程是否正确？ 有人赞同“简洁高效”，有人痛批“用异常当if用，是反模式”。
技术拆解：用Java语法还原决策现场
异常控制流的成本真相
在Java中，try-catch不仅在抛出时存在栈快照开销（JIT后优化为轻量级），更严重的是语义污染——DuplicateKeyException本意是“数据库层异常”，却被用来表达“业务层的重复”这一正常业务分支，依据《Effective Java》第69条：“异常应仅用于异常情况”,这里显然越界。
更“正确”的搓射姿势
若不使用异常,常见替代方案：
- 前置查询：
selectByOrderNo先查一遍，再insert，但存在“检查后插入”的竞态窗口,需配合唯一索引兜底。 - 幂等表：单独建一张
idempotent_key表，用INSERT IGNORE或INSERT ... ON DUPLICATE KEY UPDATE,以原子操作返回0或1。
// 改进版：利用数据库方言，无异常无竞态 int result = orderMapper.insertIgnore(dto); // 返回受影响行数 return result == 1;
核心权衡点
- 可读性：异常流让业务意图被异常处理代码淹没。
- 性能：在极高频路径上,异常对象的创建与填充对于GC是压力源。
- 可测试性：单元测试中
doThrow模拟异常，会让测试关注点在“如何触发错误”，而非“业务规则是否正确”。
多维评估：结果导向 vs 过程理性
从“结果”看——这个选择在当时是“有效”的
- 代码量最少,开发时间短。
- 在低并发、低规格环境下,性能差异可忽略。
- 因重复订单量占比<0.1%,所以运行半年无事故。
从“原则”看——这个选择是“危险”的
- 隐含耦合：DB异常被暴露到Service层，未来换数据库（如MongoDB）则崩溃。
- 监控误报：将重复订单误记为ERROR日志，导致告警噪音,掩盖真实故障。
- 后续扩展：若需要支持“重复时更新”或“计数”,异常分支根本无法承载。
关键评判标准：是否可逆？
- 如果这是临时性能测试代码,可接受。
- 如果是核心交易链路的长期代码,则欠债。
问答环节：选择”的四个灵魂拷问
Q1：什么时候“用异常控制流程”是可以接受的？
答：当异常真正代表“不确定的、意外的系统级错误”时，例如连接池耗尽、磁盘IO失败，对于业务规则（如重复）,必须视为正常流。
Q2：如果不依赖异常，如何保证最终一致性？
答：使用数据库的唯一索引+
INSERT IGNORE（MySQL）或ON CONFLICT（PostgreSQL）,配合业务表内的幂等标记位。
Q3：代码评审时，如何用一句话说服同事？
答：“你是在用异常表达if，还是在用if表达意外？”——如果是前者,请重构。
Q4：如果历史代码已这样写，如何优雅演进？
答：第一步，包装一个新方法
createOrderIdempotent，内部用INSERT IGNORE；第二步，加一个feature flag，灰度切换流量；第三步，确认稳定后删除旧方法，并收窄异常类型只捕获DataAccessException。
正确性从来不是非黑即白
回到开头的“搓射”——如果守门员站位靠前、球速快，搓射是天才；如果门将不动、后卫贴身，搓射是失误。Java案例同理：在没有唯一索引的旧库上，异常流可能是唯一选项；但在现代工程标准下，它是技术债，是掩盖在“能跑”之下的“风险点”。
最终判断：不是看“是否抛了异常”，而是看这个选择是否最小化了意外复杂度，在此案例中，更优解是使用数据库原生幂等语义,而非强迫异常充当业务信使。
一句话收尾：代码如足球，真正的“正确”不是看到结果才回头评价，而是在起脚瞬间，你的决策模型是否包含了所有概率。
