在实现文件上传功能时，很多时候会使用 Promise.race 来控制并发：

const pool = new Set();

for (const file of files) {
  const task = upload(file);
  pool.add(task);
  task.finally(() => pool.delete(task));

  if (pool.size >= limit) {
    await Promise.race(pool);
  }
}

这段代码确实能限制同时上传几个任务，但它本质上只是一个”信号灯”——它只知道”有一个任务完成了”，却不知道是哪 一个，也不知道当前队列的真实状态。

当我们需要实现暂停、恢复、取消、状态追踪等功能时，Promise.race 就力不从心了。

在前端开发中，一次性渲染大批量数据的列表是性能杀手。一次性创建数万个 DOM 节点，导致浏览器样式计算和布局耗时巨大，会造成首屏加载白屏、滚动严重掉帧。可以使用虚拟滚动 进行优化。

1.核心思想：只渲染用户“看得见”的那部分 DOM 元素

想象一个滚动的长条，虽然数据有 10000 条，但用户的屏幕（视口）只能看到 10 条。我们只需要创建这 10 个节点的 DOM，随着滚动动态更新它们的内容和偏移量。

在前端开发中，经常会有大批量文件上传的需求。在面对“数千张高清图片批量上传”的需求时，传统的前端上传方案往往会出现各种各样的问题：

• 一次性全部上传：极易触发服务器 413 Payload Too Large 报错，且巨大的 HTTP 包体容易导致连接超时。
• 暴力循环：瞬间发起数千个 HTTP 请求，不仅会挤爆浏览器的并发限制，导致大量请求排队挂起，还可能瞬间压垮后端服务。

针对这些问题，就需要前端分批上传，下面介绍一下一种支持分组、控制并发、且具备自动重试机制的大批量文件上传策略

1. 核心设计思路

• 分批： 将 大批量文件切分成若干个小批次（比如每批 50-100 个），

在 ChatGPT 出现之前，大部分 Web 接口都是“请求-响应”模式：用户发一个请求，服务器处理完（可能需要几秒），然后一次性把结果扔回来。但在大模型时代，生成一段长文本可能需要 10 秒甚至更久。如果让用户盯着空白屏幕等 10 秒，体验会非常糟糕。于是，SSE (Server-Sent Events) 再次回到了聚光灯下。它允许服务器一边生成内容，一边通过长连接把数据“推”给前端，也就是我们看到的“打字机效果”。

1.什么是 SSE？

SSE（Server-Sent Events）是一种基于 HTTP 的单向通信机制。

方案：后端返回完整路由结构，前端动态组件映射

1. 设计思路

1. 初始状态： 路由表中只有“登录页”、“404”等基础静态路由页面。
2. 登录： 用户登录，获取 Token。
3. 获取权限： 前端拿着 Token 请求后端接口，后端返回该用户的菜单树（路由表）。