JavaScript错误处理关键在于识别、分类与精准传递：try...catch仅捕获同步运行时错误，异步错误需Promise.catch或async/await配合；应增强错误上下文、合理分层拦截，并以全局监听为最后防线。
JavaScript 中的错误处理不是加个 try...catch 就算完事——真正影响健壮性的，是错误是否被识别、是否被分类、是否被传递到合适的位置。
什么时候该用 try...catch，什么时候不该用
try...catch 只对同步代码中的运行时错误有效；对异步操作（比如 fetch、setTimeout 里的抛错）、Promise 拒绝、事件回调里的异常，它默认捕获不到。
- 适合：解析 JSON、调用可能抛错的第三方库方法（如
JSON.parse()、localStorage.setItem()）、手动校验逻辑 - 不适合：直接包住整个
async函数体（除非你明确 await 了 Promise 并希望捕获其 rejection） - 注意：
try...catch无法捕获Uncaught ReferenceError这类语法/顶层执行错误，这类必须靠window.onerror或window.addEventListener('error')
Promise.catch() 和 async/await 中的错误处理差异
两者本质一致，但写法和控制粒度不同。关键不是“哪个更好”，而是“在哪一层拦截更合理”。
-
Promise.catch()更适合链式调用中局部兜底，比如只关心某次fetch失败是否重试，不希望影响后续 then 的流程 -
async/await + try...catch更适合业务逻辑块级错误聚合，例如一个表单提交涉及校验、API 调用、本地缓存三步，任一失败都应统一提示并中断 - 常见坑：
await Promise.reject('err')不会触发外层try...catch，除非你没写await—— 忘加await是最隐蔽的漏捕获原因
如何让错误真正“可定位”而不是只留 TypeError: Cannot read property 'x' of undefined
原生错误堆栈在压缩后基本不可读，且缺少上下文。需要主动增强。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
立即学习“Java免费学习笔记（深入）”；
- 在
catch块里不要只打印err.message，至少带上当前模块名、关键变量值（如console.error('[user-api] fetch failed for uid:', uid, err)） - 用
err.stack结合source-map工具还原原始行号，否则生产环境堆栈毫无意义 - 对自定义业务错误，建议抛出带类型和元数据的对象：
throw Object.assign(new Error('Order validation failed'), { code: 'VALIDATION_ERROR', fields: ['email'] })
全局错误监听不能代替局部处理
window.addEventListener('error') 和 window.addEventListener('unhandledrejection') 是最后防线，不是主力方案。
- 它们能帮你发现漏掉的异常，但无法阻止页面崩溃或恢复状态
- 二者捕获的错误对象结构不同：
error事件传的是ErrorEvent，需取event.error才是真正的Error实例；unhandledrejection的event.reason可能是字符串、普通对象，不一定是Error - 不要在这些监听器里做复杂逻辑（如重发请求），容易引发二次错误；只做日志上报 + 简单降级提示
最难的部分从来不是语法怎么写，而是判断“这个错误我该现在处理，还是交给上层，还是根本不管”。边界模糊时，优先保用户操作流不中断，再考虑日志精度和恢复能力。
