await本身不保证数据一致性，但通过明确表达执行顺序、配合状态管理与错误处理可奠定基础：需串行关键步骤、用闭包隔离并发请求、采用不可变更新、分层捕获异常。
await 本身不直接“保证”数据一致性，但它提供了关键的控制力——让开发者能用同步风格明确表达执行顺序和依赖关系，从而为一致性打下基础。真正起作用的是你如何组织 await 的位置、配合状态管理与错误处理。
串行关键步骤，避免状态错位
多个有先后依赖的操作（比如删数据后刷新列表），必须用 await 依次等待，确保前一步完成、状态更新后再走下一步：
- ✅ 正确：await deleteItem(id); await fetchList(); —— 删除完成才拉新列表，UI 显示的永远是最新快照
- ❌ 错误：deleteItem(id); fetchList(); —— 两个 Promise 并发执行，列表可能在删除前就渲染了旧数据
- ⚠️ 隐患：fetchList().then(render) 写在 deleteItem 后面但没 await —— 渲染时机不可控，容易显示中间态
用闭包隔离并发请求，防止响应错乱
用户快速连点或输入时，多个异步请求可能并发发出，但后发先至的响应若覆盖了先发的结果，就会导致 UI 显示错乱。靠闭包绑定每次调用的上下文：
- 维护一个 per-call 的 isPending 标志，重复触发直接返回已有 Promise
- 生成唯一 requestId，在 fetch 完成后比对 ID，丢弃过期响应
- 把 token、重试计数等临时状态放在闭包里，而不是全局变量，避免不同请求互相污染
配合不可变更新，让状态变化可追溯
await 等到数据后，不要直接 push、splice 或赋值属性，而是创建新对象/数组：
- 添加项：state.items = [...state.items, newItem]，而非 state.items.push(newItem)
- 更新某条：state.items = state.items.map(i => i.id === id ? {...i, name} : i)
- 这样即使回调延迟执行，也不会意外改写正在渲染的旧状态，UI 始终基于确定版本渲染
分层捕获异常，不让失败破坏整体状态
不是所有错误都要中断流程。根据业务语义决定 catch 的粒度：
- 单个请求容错：获取头像失败，用默认图替代，不影响主流程 —— 单独 try/catch
- 强依赖链回滚：下单 → 扣库存 → 发通知，任一失败必须撤销前面操作 —— 外层统一 try/catch + 手动补偿逻辑
- 绝不写 catch(e) {}；至少 console.error 或 re-throw，否则问题静默消失
