await只等待promise结果，不控制任务生命周期；它暂停async函数执行并交还控制权，但任务启动、结束及取消需依赖外部机制如abortsignal或手动清理。
await 不控制异步任务本身的生命周期，它只暂停当前 async 函数的执行，等待 Promise 状态 settled（fulfilled 或 rejected）后继续；任务是否运行、何时结束，由其自身逻辑和调用时机决定。
await 本质是“等待结果”，不是“管理任务”
await 表达式会暂停所在 async 函数的执行，把控制权交还给事件循环，直到右侧 Promise 进入 fulfilled 或 rejected 状态。它不干预 Promise 内部的定时器、网络请求、事件监听等实际行为——这些早已在 Promise 构造时启动。
- 比如
await fetch('/api')：fetch 请求在 Promise 创建时就已发出，await 只是等响应返回并解析为 Response 对象 - 再如
await new Promise(r => setTimeout(r, 1000))：setTimeout 在 Promise 构造函数中立即执行，await 等待的是 1 秒后那个 resolve 调用触发的状态变更
任务可能“提前结束”或“持续运行”，await 无法终止它
await 对 Promise 后续状态无影响力。若 Promise 内部启动了长期运行的操作（如长轮询、WebSocket 连接、未清理的定时器），即使 await 完成，那些操作仍可能继续。
- 常见陷阱：用
await Promise.race([apiCall(), timeout(5000)])实现超时，只是让 await 提前跳出，但原 apiCall() 的网络请求仍在后台进行，可能稍后才完成或失败 - 真正取消需依赖具体机制：fetch 支持
AbortSignal，axios 有 cancel token，自定义 Promise 需手动设计清理逻辑
多个 await 是串行等待，不改变各任务的并发性
写多个 await 并不意味着任务被“串行化执行”。它们的启动时机取决于 Promise 创建的位置：
- 如果写成
await a(); await b();：b() 在 a() 返回的 Promise settle 后才调用，天然串行 - 如果写成
const p1 = a(); const p2 = b(); await p1; await p2;：a() 和 b() 几乎同时启动，await 只是依次等待结果，实际是并发执行
错误处理边界由 await 所在位置决定
await 将 Promise rejection 转为同步异常，因此 try/catch 的范围决定了哪个错误能被捕获。它不改变 Promise 本身的 reject 行为，只影响异常传递路径。
-
try { await badApi() } catch(e) { ... }：捕获 badApi() 返回 Promise 的 reject - 若忘记 await 或漏写 try/catch，reject 会变成未处理拒绝（unhandled rejection），触发全局 error 事件或 Node.js 的 process.on('unhandledRejection')
不复杂但容易忽略：await 是协程式的等待语法糖，不是任务调度器。要控制生命周期，得从 Promise 构建阶段入手——传入 abort 信号、设置超时、主动清理资源，而不是指望 await 做更多。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
