异常捕获真有性能代价？家里智能设备代码里的小秘密

晚上回家，按下开关，灯没反应。你皱眉，手机打开App，发现家里的温控系统又报错了。刷新日志一看，满屏都是 try-catch 捕获的异常信息。这时候你可能纳闷：这些天天在后台抓错的代码，会不会拖慢整个系统？

异常捕获不是免费的

很多人写代码时习惯性地把一大段逻辑包进 try-catch 里，觉得“反正不抛错就没事”。可实际上，异常机制本身是有开销的。特别是在频繁触发或深层嵌套的场景下，异常捕获会带来明显的性能损耗。

比如你家的智能窗帘控制模块，每秒钟检查一次光照强度。如果每次判断都因为配置缺失抛出异常，再被捕获处理，那系统资源很快就被堆栈追踪、异常对象创建这些操作吃掉。

别用异常做流程控制

有个老程序员常说：“异常是用来处理‘异常’的，不是用来当 if 用的。”这话在家用 IoT 设备开发里特别适用。

下面这种写法看着省事，实则隐患大：

try {
    value = config.get("threshold");
    process(value);
} catch (NotFoundException e) {
    value = DEFAULT_THRESHOLD;
}

明明可以用判断避免的空值问题，非得靠抛异常来走默认逻辑。每次触发，JVM 都要生成完整的堆栈快照，时间成本远高于一次 null 判断。

提前预防比事后补救更轻量

更好的方式是先查后用：

if (config.contains("threshold")) {
    value = config.get("threshold");
} else {
    value = DEFAULT_THRESHOLD;
}
process(value);

这样既清晰又高效，不会因为一个配置项让整个控制线程卡顿。

你家的扫地机器人要是每转一圈都“假装”撞墙一次来测试避障逻辑，那电池撑不了多久。同理，代码里靠频繁抛异常来判断状态，设备响应自然变慢。

生产环境别打印全栈日志

调试阶段打详细日志没问题，但上线后还让每个异常都输出完整堆栈，磁盘和CPU都会吃不消。尤其是一些高频触发的传感器读取任务，日志文件几天就能涨到几个GB。

合理的做法是分级处理：严重错误才记录堆栈，普通情况只记关键信息，甚至异步写入日志队列，避免阻塞主流程。

就像你不会让智能音箱每分钟播报一次系统状态，代码里的“报警声”也得学会控制音量。