不推荐将 try...catch 作为常规值校验手段；应优先采用显式验证逻辑（如正则、类型检查、预判解析），仅在无法避免异常场景（如 JSON.parse）时谨慎使用，并始终捕获具体错误类型。
不推荐将 `try...catch` 作为常规值校验手段；应优先采用显式验证逻辑（如正则、类型检查、预判解析），仅在无法避免异常场景（如 `json.parse`）时谨慎使用，并始终捕获具体错误类型。
在 JavaScript 开发中，用 try...catch 来“试探性”验证数据有效性（例如检查 JSON 字符串是否合法、十六进制颜色是否格式正确）是一种常见但易被滥用的模式。虽然它能“工作”，但存在可读性差、性能开销隐性、错误边界模糊等多重问题。
✅ 正确做法：优先使用主动验证，而非被动捕获
1. 对 JSON.parse 的优化
JSON.parse() 是少数真正需要 try...catch 的场景之一（因无标准 JSON.isValid() 方法），但可封装为健壮工具函数，避免重复逻辑：
function safeParseJSON<T>(str: string | null, fallback: T): T {
if (!str || typeof str !== 'string') return fallback;
try {
return JSON.parse(str) as T;
} catch (e) {
console.warn('Invalid JSON in localStorage:', str, e);
return fallback;
}
}
// 使用示例
const config = safeParseJSON(localStorage.getItem('config'), { theme: 'light' });注意：绝不使用空 catch {} —— 必须明确捕获 SyntaxError 或至少 e instanceof SyntaxError，避免掩盖其他意外错误。
2. 对颜色值等结构化数据：彻底避免 try...catch
像 hex2Rgb() 这类函数，本应具备输入前置校验能力。应重构为纯验证函数（返回布尔值）或安全转换函数（返回 null/undefined 而非抛错）：
function isValidHexColor(str: string): boolean {
if (!str || typeof str !== 'string') return false;
const hexRegex = /^#([0-9A-F]{3}|[0-9A-F]{6}|[0-9A-F]{8})$/i;
return hexRegex.test(str);
}
// 安全设置颜色（无异常风险）
const storedColor = localStorage.getItem('hexColor');
setColor(isValidHexColor(storedColor) ? storedColor : '#000000');这种写法语义清晰、零异常开销、易于单元测试，且符合防御性编程原则。
⚠️ 关键注意事项
- 性能影响：try...catch 在 V8 等引擎中会禁用部分 JIT 优化，频繁用于控制流将显著拖慢执行速度；
- 可维护性陷阱：catch 块若未区分错误类型，可能意外吞掉 ReferenceError 或网络异常等真正需关注的问题；
- 团队一致性：若项目中已约定“校验走 if，异常只处理不可预知故障”，强行用 try 校验会破坏契约，增加协作成本。
✅ 总结建议
| 场景 | 推荐方式 |
|---|---|
| JSON 解析 | 封装 safeParseJSON，catch SyntaxError |
| 颜色/邮箱/URL/数字格式校验 | 正则 + 类型检查，返回布尔值 |
| 默认值兜底 | 使用空值合并 ?? 或三元运算符 |
| 复杂对象结构校验 | 引入 zod / yup 等运行时 Schema 库 |
记住：异常应处理“意外”，而非“预期中的无效输入”。把校验逻辑显式化、模块化、可测试化，才是健壮前端代码的基石。
