不能用 try-catch 代替正常逻辑判断，根本原因是异常创建和抛出开销巨大（需分配内存、记录完整调用栈、栈展开、触发 gc），而 if 判断仅需纳秒级 cpu 指令，性能相差百至千倍，且混淆语义、降低可维护性。
不能用 try-catch 代替正常逻辑判断，根本原因在于：异常的创建和抛出本身开销巨大，而逻辑判断是轻量级的 cpu 指令。两者不在同一数量级，混用会把毫秒级操作拖慢成毫秒甚至百毫秒级。
异常抛出的成本远高于一次条件检查
每次 throw 新建一个异常对象时，JVM 或 JS 引擎必须：
- 分配堆内存构建异常实例
- 同步捕获完整调用栈（逐层记录方法名、文件、行号）
- 触发栈展开（stack unwinding），跳过中间所有调用帧
- 可能触发 GC 压力（尤其短生命周期异常频繁生成）
相比之下，if (x == null) 或 x != null 是一条或几条机器指令，耗时纳秒级。实测表明：抛一次异常的开销通常是普通判断的 100–1000 倍。
典型反模式：用异常探测“是否存在”
比如在 Java 中这样写：
try {
user = userDao.findById(id);
return user.getName();
} catch (EmptyResultDataAccessException e) {
return "未知用户";
}
这实际把“查无结果”这个常见业务状态，错误地建模为异常事件。正确做法是：
- 让 findById 返回 Optional
或 null - 用 if (user.isPresent()) 或 if (user != null) 判断
数据库查不到用户不是程序崩溃，而是预期中的分支路径——不该付出异常的代价。
性能退化在高频场景中会被放大
循环内、高并发接口、实时计算等场景下，这种误用后果更严重：
- 每秒处理 1 万次请求，若其中 30% 触发异常 → 每秒新建 3000 个异常对象
- 不仅 CPU 被栈跟踪拖慢，还增加 GC 频率，可能引发 STW（Stop-The-World）暂停
- 日志中大量重复堆栈掩盖真正故障点
而对应地，用 if 判断相同条件，几乎不增加额外负担。
语义混淆导致可维护性下降
即使性能尚可容忍，滥用 try-catch 还会破坏代码本意：
- 阅读者默认 catch 块处理的是意外、罕见、需告警的错误，而非常规流程
- 把空集合、参数缺失、配置未设置等常见情况扔进 catch，会让后续维护者反复怀疑“这里是不是真出了 bug”
- 监控系统难以区分真实异常与人为制造的“伪异常”，报警阈值失真
异常机制的设计初衷是处理“不可预测的运行时故障”，不是替代 if-else 的语法糖。
