异常冒泡与事件循环错误处理是JavaScript中同步与异步错误传播的两种机制：前者沿调用栈向上寻找catch，后者通过unhandledrejection事件兜底未处理的Promise拒绝。
异常在调用栈中“冒泡”和事件循环中异常未被捕获时的传播路径，本质是两个不同机制的协同作用：前者属于同步执行上下文中的控制流行为，后者涉及异步任务调度与错误兜底策略。理解它们如何衔接，是写出健壮 JavaScript 代码的关键。
调用栈里的异常冒泡：从抛出点向上逐层寻找 catch
当 throw 执行时，JavaScript 引擎立即中断当前函数执行，将异常对象沿调用栈向上传递，每经过一层函数，就检查该层是否有 try...catch 或 try...finally（finally 不拦截异常，但会执行）。一旦命中 catch，冒泡终止；若直到全局作用域仍无捕获，就触发“未捕获异常”。
- 冒泡只发生在同步调用链中，不跨异步边界（比如
setTimeout内部抛出的异常，不会冒泡到外层try） -
async/await函数内部的throw会被包装成 Promise rejection，不再走传统调用栈冒泡，而是进入 Promise 错误处理链 - 构造函数、getter/setter、箭头函数等，只要在同步执行中抛出，都遵循同一冒泡规则
事件循环中的异常处理链：Promise rejection 与 unhandledrejection
异步操作（如 Promise、setTimeout、fetch）产生的异常无法被外层同步 try 捕获，而是交由事件循环在对应微任务或宏任务执行完毕后统一判断：如果 Promise 被 reject 且没有绑定 .catch() 或 await 后续处理，就会触发 unhandledrejection 事件。
-
Promise.reject()或await一个失败 Promise 时，若无响应处理，该 rejection 会在本轮微任务队列清空后被标记为“未处理” - 浏览器和 Node.js 都提供
window.addEventListener('unhandledrejection')或process.on('unhandledRejection')来监听并记录这类错误 - 注意：
unhandledrejection不是“异常冒泡”，它不改变调用栈，也不中断执行，只是运行时发出的警告信号
async/await 是两者的交汇点：同步语法 + 异步语义
async 函数返回 Promise，其内部 throw 等价于 return Promise.reject(...)。因此，await 表达式看似像同步调用，实则把异常从 Promise rejection 转换为可被外围 try...catch 捕获的形式——但这仅限于 await 所在的那层 async 函数内。
- 写法
try { await fn() } catch (e) { ... }中的catch捕获的是fn()返回 Promise 的 rejection，不是调用栈冒泡 - 若忘记
await直接调用 async 函数，得到的是 Promise，异常仍走 Promise 链，不会进入外层同步try - 多个
await连续调用时，每个 rejection 都需独立处理，否则可能遗漏中间环节的错误
实际建议：分层防御，不依赖单一兜底
靠 unhandledrejection 监听来“捕获所有错误”是一种被动补救，容易掩盖逻辑缺陷。应主动在关键路径上设置处理边界。
- 对用户可感知的操作（如按钮点击、表单提交），用
try...catch包裹await调用，并给出明确反馈 - 对底层工具函数（如封装的 API 请求），默认返回 Promise 并确保有
.catch()或reject处理，避免裸露 rejection - 在应用入口或路由守卫中统一监听
unhandledrejection，仅用于日志记录和监控，不用于业务恢复 - 避免在
finally中抛出新异常，否则会覆盖原始错误，破坏调试线索
