try-catch 应仅包裹明确的危险点（如 json.parse、localstorage.getitem、第三方 api 调用），避免包裹整段业务逻辑；需正确处理异步错误、保留原始堆栈、合理使用 promise.allsettled 和全局错误监听。
try-catch 该包多大范围？
只包裹可能抛出异常的最小代码块，不是整个函数或逻辑流。比如 JSON.parse()、localStorage.getItem()、第三方 API 调用，这些是明确的“危险点”。盲目包裹整段业务逻辑，会让真实错误被静默吞掉，调试时只剩 undefined 或空状态。
常见错误现象：catch 里只写 console.log(e) 就完事，没 re-throw、没 fallback、没上报；或者把异步操作（如 fetch）直接塞进 try 却忘了它返回 Promise，结果根本捕获不到网络失败。
- 同步错误（
ReferenceError、JSON.parse("invalid")）能被try-catch捕获 -
fetch成功返回 Promise，但 HTTP 404/500 不会 reject，需手动检查response.ok - 未被捕获的 Promise rejection 会触发
unhandledrejection全局事件，应监听并记录
throw 新错误时要不要保留原堆栈？
要。直接 throw new Error("上传失败") 会丢失原始错误位置和上下文，尤其在封装工具函数时。现代 JS 支持 Error.cause（Chrome 93+、Node.js 16.9+），可显式关联原因：
try {
await uploadFile(data);
} catch (err) {
throw new Error("文件上传失败", { cause: err });
}
不支持 cause 的环境（如旧版 Safari），可用扩展属性临时保留：
立即学习“Java免费学习笔记（深入）”；
try {
await uploadFile(data);
} catch (err) {
const wrapped = new Error("文件上传失败");
wrapped.originalError = err;
throw wrapped;
}
注意：不要用字符串拼接堆栈（err.stack），它不可靠且难以解析；也不要只存 err.message，会丢掉类型、code 等关键字段。
async/await 场景下 catch 怎么写才不漏错误？
每个 await 都应处于受控的 try-catch 中，或确保其 Promise 被 .catch() 显式处理。混用 async 和 .then() 容易导致错误丢失。
- ✅ 正确：单个 await + try-catch
- ✅ 正确：多个 await 放同一 try 块（若它们逻辑强相关）
- ❌ 错误：
someAsync().then(...).catch(...)在 async 函数里——这会脱离外层 try 控制 - ❌ 错误：用
Promise.all([a(), b()])却不处理其中某个 rejected 的情况
对并发请求，推荐：
const results = await Promise.allSettled([
fetch("/api/user"),
fetch("/api/config")
]);
const [userRes, configRes] = results;
if (userRes.status === "rejected") {
console.error("用户接口失败：", userRes.reason);
}
全局错误边界有用吗？什么时候该用？
前端框架（React/Vue）的错误边界（Error Boundary）只捕获渲染阶段的同步错误，对事件处理器、定时器、Promise rejection、服务端渲染（SSR）错误无效。纯 JS 项目没有内置机制，只能靠 window.onerror 和 window.addEventListener("unhandledrejection") 补位。
真正该加全局兜底的场景只有两个：
- 收集未处理的运行时错误（用于监控，不是修复）
- 展示友好的降级 UI（如“页面加载异常，请刷新”），但必须配合本地日志上报，否则等于盲操作
注意：window.onerror 拿不到跨域脚本的详细错误（会显示为 Script error.），需给 <script></script> 标签加 crossorigin 属性，并确保服务端返回 Access-Control-Allow-Origin 头。
错误处理最常被忽略的一点：不是所有异常都需要立刻 catch。有时让错误冒泡到上层统一处理，比每层都加 try 更清晰。关键是分清哪些错误可恢复（如网络抖动重试）、哪些不可恢复（如 JSON schema 严重不匹配），后者往往该直接上报而非掩盖。
