在前端开发中，一次性渲染大批量数据的列表是性能杀手。一次性创建数万个 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 请求后端接口，后端返回该用户的菜单树（路由表）。

在 HTTP协议中，客户端必须先发起请求，服务器才能响应。这就像发邮件，你发一封，对方回一封。但如果需要开发一个即时聊天室、股票大盘或者实时视频监控的功能，让客户端每隔几秒钟问一次服务器“有新消息吗？”（轮询），既浪费带宽，延迟又高。WebSocket是解决这个问题的最优解。

一、 什么是 WebSocket？