slice()分页本身不耗内存，关键在按需调用、避免预存全量分块；正确做法是每次仅slice当前页，用索引映射替代切片更优。
直接用 slice() 做分页本身不消耗额外内存，但它不能“确保”内存安全——真正起作用的是你**不提前生成所有页、不保留全量数据副本、不一次性渲染或遍历整个数组**。关键在于用法逻辑，而非 slice 本身。
只截取当前页，不预存所有分页结果
错误做法：把完整数组按页全部切开，存成二维数组（如 [[…], […], […] ]）——这会立刻复制全部数据，内存翻倍。
正确做法：每次只调用 array.slice(start, end) 获取当前页数据，用完即弃。浏览器垃圾回收器能及时释放未被引用的切片。
- 页码切换时，重新计算
start = (page - 1) * size和end = start + size，再调用slice - 不要缓存
allPages = chunk(array, size)这类全量分块结果，除非数据量极小（
配合生成器，实现按需分片（推荐大数据场景）
对上万条数据，用生成器函数避免任何中间数组累积：
立即学习“Java免费学习笔记（深入）”；
function* paginate(arr, size) {
for (let i = 0; i yield arr.slice(i, i + size);
}
}
- 调用
const pages = paginate(hugeArray, 50)不产生任何子数组 - 只有执行
pages.next().value时，才临时生成一页数据，用完即丢 - 适合与
for await...of配合做流式处理，或结合虚拟滚动按视口加载
边界检查 + 提前终止，避免无效 slice
slice() 超出范围时返回空数组或截断结果，看似安全，但若页码极大（如 page = 100000），计算 start = (page - 1) * size 可能产生超大数值，虽不报错，却浪费 CPU 和潜在内存（如触发内部优化路径）。
- 先校验：
if (page Math.ceil(arr.length / size)) return []; - 对只读展示场景，可直接限制最大可访问页码（如最多到第 200 页），防止用户输入恶意页码
- 服务端已分页时，前端不应持有全量数组，此时
slice根本不该出现——应由后端控制数据边界
替代思路：不用 slice，改用索引映射
如果只是渲染列表并需要显示“第 X 条”，完全不必切出新数组。直接用原数组 + 当前页索引计算位置：
- 渲染第
page页第i项（从 0 开始）→ 访问arr[(page - 1) * size + i] - 配合
Array.from({ length: size }, (_, i) => …)生成虚拟项结构，不创建实际子数组 - 特别适合虚拟滚动库（如 react-window），它们内部根本不调用
slice，而是靠坐标映射实时读取
