不推荐将 try-catch 作为常规值校验手段；应优先采用显式验证逻辑（如正则、类型检查、解析前预判），仅在无法避免异常场景（如 json.parse）时谨慎捕获特定错误。
不推荐将 try-catch 作为常规值校验手段；应优先采用显式验证逻辑（如正则、类型检查、解析前预判），仅在无法避免异常场景（如 json.parse）时谨慎捕获特定错误。
在 JavaScript 开发中，用 try...catch 检查数据有效性（例如验证 JSON 字符串或十六进制颜色值）看似“能用”，但本质上违背了异常处理的设计初衷：异常应表示意外的、非预期的运行时故障，而非可预见的输入校验失败。滥用 try...catch 会导致代码可读性下降、性能损耗（V8 等引擎对异常路径有显著开销），且掩盖真实错误意图。
✅ 正确做法：优先使用主动验证（Fail-fast, No Exception）
以 hex2Rgb 为例，不应依赖其抛出异常来判断颜色合法性，而应提供独立的校验函数：
function isValidHexColor(str) {
if (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');
类似地，对于 JSON 解析，可封装为安全解析函数，显式区分「解析失败」与「默认回退」逻辑，避免重复 setItem 和重复 parse：
function safeJsonParse(key, fallback = null) {
const raw = localStorage.getItem(key);
if (!raw) {
localStorage.setItem(key, JSON.stringify(fallback));
return fallback;
}
try {
return JSON.parse(raw);
} catch (e) {
// ✅ 明确捕获 SyntaxError，避免吞掉其他异常
if (e instanceof SyntaxError) {
console.warn(`Invalid JSON in localStorage key "${key}", resetting to fallback.`);
localStorage.setItem(key, JSON.stringify(fallback));
return fallback;
}
throw e; // 其他错误仍需上抛
}
}
// 调用更清晰、无副作用
const config = safeJsonParse('appConfig', { theme: 'light' });
⚠️ 关键注意事项
- 禁止裸 catch{}：必须指定错误类型（如 catch (e) { if (e instanceof SyntaxError) {...} }），否则会静默吞掉 ReferenceError、网络错误等真正需关注的问题；
- 避免重复操作：原代码中 localStorage.setItem(key, fallback) 在 try 前和 catch 中各执行一次，存在竞态与冗余风险；
- 性能敏感场景慎用：频繁触发异常会显著拖慢执行速度（尤其在循环或高频事件中）；
- 团队一致性优先：若项目已约定 try/catch 用于轻量校验（极少数遗留系统），应在文档中明确规范，并统一错误类型与日志策略。
✅ 总结
| 场景 | 推荐方式 |
|---|---|
| JSON 解析 | try...catch(SyntaxError) 封装为 safeJsonParse() |
| 颜色/邮箱/URL 校验 | 正则 + 类型检查（isValidHexColor()） |
| 数字范围/必填校验 | 直接条件判断（if (val == null || val |
| 外部 API 响应结构校验 | 使用运行时类型库（如 Zod、io-ts）或手动 schema 检查 |
让错误成为例外，而非流程；让验证逻辑显式、可测、可复用——这才是健壮前端代码的基石。
