应最小化try_catch范围，仅包裹可能抛异常的关键语句（如json.parse、网络请求等），避免包含日志、循环或无关计算；优先用类型检查、可选链等防御性编程替代异常处理，并确保catch块轻量高效。

限制 try_catch 的代码块范围，核心是只包裹**可能抛出异常且必须捕获处理的最小语句**，避免把大量常规逻辑、IO、循环或无关计算包进去。过大范围不仅增加异常处理机制的运行时负担（如栈展开、异常对象构造），还掩盖真实错误边界，影响调试和性能。

只包裹真正可能抛异常的调用

很多方法（尤其是涉及外部依赖的）明确声明或实际会抛异常，例如文件读写、网络请求、JSON 解析、类型强制转换等。这些才是 try 的合理目标：

• ✅ 好： try { const data = JSON.parse(input); } catch (e) { ... }
• ❌ 差： try { console.log('start'); const data = JSON.parse(input); console.log('done'); } catch (e) { ... } —— 日志和普通语句不该在其中

避免在循环内重复包裹相同操作

如果循环体中某步固定会抛异常（如解析每行 JSON），不要为每一项都建一个 try_catch；可提取为独立函数，在外层统一处理，或使用预校验降低异常发生率：

• 优先校验： if (input.trim() && input.startsWith('{')) { try { ... } catch {...} }
• 或封装： function safeParse(s) { try { return JSON.parse(s); } catch { return null; } }，再在循环中调用

用更轻量的防御性检查替代部分 try_catch

对可预测的失败场景（如属性访问、类型判断），用条件判断比触发异常更高效：

• ❌ 不必要： try { value.toUpperCase(); } catch (e) { ... }
• ✅ 更优： if (typeof value === 'string') { value.toUpperCase(); } else { ... }
• 同理，用 obj?.prop、Array.isArray()、Number.isFinite() 等代替靠异常兜底

确保 catch 块不引入新开销

catch 本身不是瓶颈，但常见误用会放大代价：

• 避免在 catch 中执行耗时操作（如同步日志写入、复杂格式化、重试网络请求）
• 不要无差别捕获后忽略：catch (e) { /* empty */ } —— 掩盖问题且白花开销
• 如只需记录，用 console.error(e) 或轻量上报，而非构造新错误或深拷贝堆栈