async函数中异常处理的时间复杂度为o(1)，因其仅涉及栈帧切换和错误对象传递，不依赖输入规模或数据结构遍历，耗时来自异步任务本身而非try/catch机制。
async 函数本身不改变异常处理的时间复杂度，它只是 Promise 的语法糖，异常捕获逻辑仍由 JavaScript 引擎在事件循环中同步执行，时间开销为 O(1)。
异常抛出与捕获是常数时间操作
当 await 后的 Promise 被 reject，或 async 函数体内 throw 错误时，V8 引擎会立即中断当前 async 函数的执行上下文，并将错误对象传递给最近的 try/catch 块（或 rejection handler）。这个过程不依赖输入数据规模 n，也不遍历任何结构，仅涉及栈帧切换和错误对象传递。
- throw 和 catch 的底层实现基于引擎内置的控制流机制，与数组长度、请求次数、嵌套深度等无关
- 即使在深度嵌套的 async 函数调用链中（如 A → B → C），错误向上冒泡也只经过已激活的 async 栈帧，帧数由调用深度决定，而非数据量
- 对比：遍历 1000 个元素的 for 循环是 O(n)，而一次 throw + 一次 catch 是固定步骤，始终为 O(1)
真正影响耗时的是异步操作本身，不是异常处理机制
async/await 的“耗时”来自它所等待的异步任务（如 fetch、setTimeout、数据库查询），而非 try/catch 结构。异常处理只是对这些任务结果的响应动作。
- 例如 await fetch('/api/user') 失败时，网络超时可能耗时 5000ms，但 catch 块内 console.error(err) 的执行仍只需微秒级
- Promise.reject(new Error()) 构造和抛出是 O(1)；Promise.all([...]) 中某个子 Promise 拒绝，也不会让 .catch() 变成 O(n)
- 错误堆栈生成（stack trace）虽有轻微开销，但属于常数级附加成本，不随 n 增长，不计入主导项
并发场景下异常处理仍保持 O(1) 单次开销
使用 Promise.all、Promise.race 等组合多个 async 操作时，每个独立 await 或 catch 的时间复杂度不变。整体流程的性能瓶颈在于 I/O 并发能力或 Promise 集合大小，而非异常分支逻辑。
- Promise.all([p1, p2, p3]) 中任一拒绝 → .catch() 触发：仍是单次错误分发，O(1)
- Promise.allSettled([...]) 返回全结果数组：遍历结果是 O(n)，但这是数据聚合行为，不属于“异常处理”本身的复杂度
- 安全封装模式如 const [err, data] = await safe(fetch(...))：解构赋值和数组访问均为 O(1)
注意：不要混淆「异常发生频率」与「异常处理复杂度」
一个函数被调用 1000 次且每次都 throw，总时间是 1000 × O(1) = O(n)，但这反映的是调用频次，不是单次异常处理的复杂度。算法分析关注单次操作随输入规模 n 的增长趋势，而 async 函数内部的异常路径没有这样的变量依赖。
- 输入规模 n 若指“请求列表长度”，则 forEach + await 是 O(n) —— 因为 await 执行了 n 次，每次 O(1)，总和 O(n)
- 但其中每一次 try/catch 块的进入、错误捕获、变量赋值，仍是 O(1)
- 就像调用 1000 次 console.log() 是 O(n)，但单次 console.log() 是 O(1)
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
