async函数不直接优化瀑布流，需配合并发控制（如promise.all）、分批限流、缓存、预加载和优先级调度等策略；单纯串行await反而加剧瀑布流。
async 函数本身不直接优化瀑布流请求，关键在于如何用它配合并发控制、缓存、预加载等策略来减少串行等待。单纯写 await fetch() 接一个又一个，反而强化了瀑布流——这不是 async 的问题，而是调用方式的问题。
用 Promise.all 并发替代串行 await
瀑布流本质是前一个请求完成才发下一个。若多个请求彼此独立（如获取用户信息、头像、权限配置），应并行发起，而不是链式 await：
- ❌ 错误示范（典型瀑布）：
await api.getUser();<br>await api.getAvatar();<br>await api.getPermissions();
- ✅ 正确做法（并发）：
const [user, avatar, perms] = await Promise.all([<br> api.getUser(),<br> api.getAvatar(),<br> api.getPermissions()<br>]);
按需分批 + 并发数限制
如果必须顺序加载（比如分页列表），但又要避免单个请求卡住全部流程，可用 Promise.all 分批 + 控制并发量：
- 把 20 个分页请求分成每 3 个一组，并行拉取，组间保持顺序
- 用 p-limit 或手写简单限流器，避免瞬间打爆服务端或触发浏览器并发上限（通常 6~10 个）
- 示例逻辑：先发第 1–3 页，等这组全返回再发第 4–6 页，而非一页接一页等
结合缓存与条件跳过
async 函数里加一层判断，避免重复请求已知数据：
- 用 Map / WeakMap 缓存近期结果，key 可以是 URL 或参数序列化字符串
- 对幂等接口（如 GET /user/123），检查缓存命中就直接 resolve，不发网络请求
- 搭配
AbortSignal.timeout()或自定义超时，防止某个请求长期阻塞后续逻辑
提前启动 + 请求优先级调度
利用 async 的非阻塞特性，在 UI 交互前或空闲时预热关键请求：
- 用户进入页面前，预先
fetch('/common-config')；点击“详情”按钮前，提前fetch('/related-data') - 用
requestIdleCallback或setTimeout(..., 0)把低优先级请求延后，保障首屏关键请求更快完成 - 对非关键资源（如埋点上报、日志上传），用
void asyncFn()火种式触发，不 await 不阻塞主流程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
