try-catch仅捕获同步错误，异步错误需结合async/await+try-catch、unhandledrejection监听等；finally用于资源清理；应抛Error实例而非字符串，便于调试与监控。
try-catch 捕获同步错误最常用，但别漏掉 finally
JavaScript 中 try-catch 是处理同步异常的标配，但它只捕获当前执行栈中抛出的错误，对异步操作（如 setTimeout、Promise 回调）无效。常见误用是以为加了 try-catch 就能兜住所有错误，结果发现 fetch 失败或 JSON.parse 报错仍导致白屏或未处理的 Uncaught SyntaxError。
实操建议：
通过 yarn-threads-cli 与 Threads（Meta）交互。当用户想要阅读首页动态、点赞、收藏的帖子或特定帖子时使用；查看...
-
catch块里务必检查error类型，避免把null或非Error实例当异常处理 - 需要清理资源（如关闭定时器、释放锁）时，把逻辑放在
finally里，它无论是否出错都会执行 - 不要空
catch：至少记录console.error(error)或上报到监控系统
try {
const data = JSON.parse(invalidJson);
render(data);
} catch (err) {
if (err instanceof SyntaxError) {
console.error('JSON 解析失败:', err.message);
showErrorMessage('数据格式异常');
} else {
throw err; // 不认识的错误，继续上抛
}
} finally {
hideLoading();
}
async/await 必须配合 try-catch，Promise.catch 不能跨 await 链自动传递
写 async 函数时，很多人习惯在最后链一个 .catch()，但这样会漏掉 await 后面语句抛出的错误——因为 await 已将 Promise 转为同步流程，错误不再走 Promise 链。
常见错误现象：await fetch('/api') 成功，但后续 await res.json() 报错，却没被外层 .catch() 捕获。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 每个
await行都应处于try块内，或确保前一个await的 Promise 已用.catch()处理并返回“安全值” - 避免混合写法：不要在
async函数里既用try-catch又在外层调用处再链.catch()，容易重复处理或遗漏 - 注意
Promise.all：任一子 Promise 拒绝会导致整个失败，需提前用.catch(() => null)包装单个 Promise 来隔离错误
async function loadData() {
try {
const res = await fetch('/api');
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json(); // 这行可能 SyntaxError，必须在 try 内
return data;
} catch (err) {
console.error('加载失败:', err);
return null;
}
}
window.onerror 和 window.addEventListener('error') 用于捕获全局 JS 错误
这些机制能抓到未被 try-catch 捕获的运行时错误，包括脚本加载失败、语法错误、跨域脚本错误（但此时 error 对象信息受限，message 和 stack 为空）。
关键限制：它们不捕获 Promise 拒绝（unhandledrejection 是独立事件），也不捕获 console.error 手动打的日志。
实操建议：
- 必须在所有脚本执行前注册，否则早期错误会丢失
- 生产环境建议搭配
addEventListener('unhandledrejection', ...)一起使用，覆盖 Promise 场景 - 注意跨域脚本：CDN 上的 JS 报错时，浏览器出于安全限制只给
Script error.，需在<script>标签加crossorigin属性并确保服务端返回Access-Control-Allow-Origin
window.addEventListener('error', (event) => {
console.log('全局错误:', {
message: event.message,
filename: event.filename,
lineno: event.lineno,
colno: event.colno,
});
});
window.addEventListener('unhandledrejection', (event) => {
console.log('未处理 Promise 拒绝:', event.reason);
});
throw new Error() 比 throw 'string' 更利于调试和分类
直接 throw '网络超时' 看似简单，但会让错误失去堆栈、类型和标准化属性，后续无法用 instanceof Error 判断，监控系统也难做聚合分析。
实际项目中，自定义错误类或带 code 的 Error 实例能显著提升问题定位效率，比如区分业务错误（AuthError）、网络错误（NetworkError）、校验错误（ValidationError）。
实操建议：
- 所有手动抛错统一用
new Error(msg)，哪怕只是临时调试 - 添加额外字段：如
err.code = 'NETWORK_TIMEOUT'、err.meta = { url, method }，便于日志筛选 - 避免在
catch中吞掉原错误又不保留err.stack，这会让排查断层
class ValidationError extends Error {
constructor(message, field) {
super(message);
this.name = 'ValidationError';
this.field = field;
}
}
// 使用
if (!email.includes('@')) {
throw new ValidationError('邮箱格式不正确', 'email');
}
错误处理真正难的不是语法，而是决定在哪一层抛、在哪一层收、哪些该静默、哪些必须阻断用户操作。尤其在微前端或 SDK 场景下，错误边界（componentDidCatch / errorBoundary）和跨沙箱错误透传，很容易被忽略。 
