应最小化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)或轻量上报，而非构造新错误或深拷贝堆栈
