应使用 async/await 串行调用或 reduce 构建 promise 链来处理 ajax 请求的顺序依赖，避免共享变量+回调等错误方式；需重试时应封装完整流程并缓存刷新 promise。
当多个 Ajax 请求之间存在顺序依赖——比如后一个请求必须用前一个返回的数据作为参数（如登录后拿 token 再调业务接口）——就不能靠并发，而要明确控制执行链路。关键不是“等谁先回来”，而是“等谁的结果出来再发下一个”。
用 await 串行调用最直观
现代写法推荐 async/await，语义清晰、错误易捕获、调试友好：
- 每个 await 后面是一个 Promise，自然等待上一步 resolve 后才执行下一步
- 中间结果可直接赋值给变量，供后续请求使用
- try/catch 可统一处理任意环节失败，避免嵌套地狱
示例：
const user = await fetch('/api/login', { method: 'POST', body: JSON.stringify(cred) }).then(r => r.json());const profile = await fetch(`/api/user/${user.id}?token=${user.token}`).then(r => r.json());
const posts = await fetch(`/api/posts?uid=${profile.userId}`).then(r => r.json());
用 reduce 实现动态链式请求
如果请求 URL 或参数需根据前序响应动态生成，且数量不固定（如分页拉取直到无更多数据），可用 Array.prototype.reduce 构建 Promise 链：
- 初始值设为 Promise.resolve()，每次迭代返回 new Promise，确保串行
- 回调中解构上一步结果，构造下一步 fetch，并 return 它的 Promise
- 最终得到一个代表全部流程完成的 Promise
示例（分页获取所有数据）：
避免用共享变量 + 回调模拟顺序
常见错误是把两个请求写在同级，靠全局变量暂存前序结果，再在第二个回调里读取：
- 这种写法无法保证执行时序：若第二个请求比第一个快，就会读到未赋值的变量
- 即使加判断逻辑（如 while 循环轮询），也会阻塞主线程或浪费资源
- 闭包陷阱也容易发生（如 for 循环中用 var i 发起请求，i 值已变）
正确做法是把依赖关系显式表达在 Promise 链或 await 序列中，而不是靠时间巧合或状态轮询。
需要重试或刷新 token 时的处理
典型依赖场景：某请求因 token 过期返回 401，需先刷新 token，再重发原请求：
- 不要在 catch 里直接发新请求并忽略原 Promise，会导致调用方无法感知重试结果
- 应封装成一个函数，内部处理“失败 → 刷新 → 重试”完整流程，并返回最终成功结果的 Promise
- 注意避免重复刷新：可用一个 pendingRefresh Promise 缓存刷新过程，后续请求 await 同一个实例
这类逻辑一旦出现，说明依赖不止两层，建议提取为独立 service 方法，而非散落在业务代码中。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
