前端达人FRONTEND / 工程与实践在 React 里展示列表数据时，很多开发者常面临三种交互选择：传统数字翻页、手动点击“加载更多”按钮，以及下滑自动触发的无限滚动。
这三种方式没有绝对的优劣之分，而是服务于不同的用户目标与工程场景：
• 如果用户的主要任务是定位、比对、查找特定数据或需要记录页码，优先考虑数字翻页；
• 如果用户以持续浏览为主，同时希望保留对加载时机与页面底部的控制，加载更多按钮往往是结构简单且体验受控的选择；
• 如果页面属于短图文、高频刷新的沉浸式信息流，自动无限滚动能提供连贯的浏览感受，但需要投入更多精力处理请求防重、重试机制与滚动位置。
理解它们的核心分水岭，首先在于理清 React 状态如何处理新拿到的一批数据。
1. 底层状态差异：数据替换还是增量追加？
翻页与滚动加载在交互上看似不同，但在组件内部的数据更新逻辑上，可以提炼为两种基本模式。
这里的 setItems 来自组件内部的 useState，newItems 则是当前异步请求返回且确认有效的最新一批数据。在实际开发中，处理同一批响应时各自代表一种更新方案，示例中分别运行，不要当作连续步骤。例如已有条目为 [{ id: 1 }, { id: 2 }]，新拿到 [{ id: 3 }, { id: 4 }]：
• 翻页模式下更新结果为 [{ id: 3 }, { id: 4 }]（旧数据被全量替换）；
• 追加模式下更新结果为 [{ id: 1 }, { id: 2 }, { id: 3 }, { id: 4 }]（新数据拼接在末尾）。
// 假设已通过异步请求成功拿到当前有效响应 newItems// 模式 A：翻页模式（全量替换，列表中只保留当前页数据）setItems(newItems);// 模式 B：追加模式（增量拼接，常见于加载更多按钮与无限滚动）setItems((prevItems) => [...prevItems, ...newItems]);
• 数据全量替换：每次切页都重置列表，渲染的条目数基本保持在单页容量之内，逻辑直观，但连续切换时用户无法同时对照上下两页。
• 数据增量追加：新数据不断排在现有列表后方，用户能顺畅向后查阅，但随着加载批次增加，内存中维护的数组与页面 DOM 结构都会持续增长。
2. 传统数字翻页：适合定位与核对的确定性交互
当用户需要明确的“空间位置感”时，数字翻页是符合直觉的选择。
典型场景
• 表格与数据检索：后台管理、工单对账、日志查询等场景，用户往往需要明确知道“当前处于第几页”，或者跳转到末页。
• 依赖 URL 记录状态：应用可以将页码同步到 URL 参数（如 ?page=3），便于用户刷新页面或复制链接分享给他人。需要注意的是，URL 记录页码并不自动保证数据完全一致；如果后台在此期间有数据新增、删除或排序变动，同一页码对应的内容可能会发生位移。
• 页面底部包含重要操作：若页面底部常驻有帮助中心、友情链接或合规信息，分页能让用户轻松触达底部。
异步处理要点
快速切页时，容易出现早发出的慢请求覆盖晚发出的快请求的问题（竞态）。在 React 中通过 useEffect 拉取数据时，通常建议在清理函数中设置一个失效标记，若当前切页已发生变化，则忽略已过期的异步响应，避免写入陈旧状态。
3. 手动“加载更多”按钮：兼顾连贯与受控的折中方案
如果你的业务不适合切断式的翻页，但又不想承担自动无限滚动的时序复杂度，在列表底部放置一个“加载更多”按钮是非常务实的折中。
核心优势
• 保留对界面的控制权：滚动到底部时，页面不会自动拉长，用户可以正常查看页脚内容，或停下来核对当前已展示的条目。
• 状态提示与重试逻辑自然：按钮本身就是天然的交互载体，在未请求时显示“加载更多”，请求中展示等待状态，请求失败时切换为“加载失败，点击重试”。
• 无须处理视口监听时序：不需要引入交叉观察器，避免了滚动监听带来的重复触发隐患。
关键防重注意点
由于加载更多依赖用户主动点击，如果用户在网络延迟期间连续快速点击，或者在移动端误触，很容易触发多次重复请求。因此，在触发请求的事件处理逻辑中，必须在发起前做状态校验；若当前已有在途请求，直接拦截后续触发。
4. 自动无限滚动：顺畅浏览背后的工程细节
无限滚动通常借助现代浏览器的 IntersectionObserver，在列表末尾放置一个不可见的哨兵元素（Sentinel），当哨兵接近或进入可视区域时自动触发下一批数据请求。
这种方案在社交媒体与图文流中能带来沉浸体验，但如果要上线使用，需要防范以下细节：
1. 失败重试不能用 setPage(p => p)
很多初学者在处理无限滚动失败重试时，容易写出 setPage(p => p)。在 React 中，如果传入的新值与当前状态相同，React 会跳过更新，依赖 [page] 的 Effect 根本不会重新执行。重试逻辑应当显式调用重新拉取的函数，或借助独立的重试计数触发，且重试时必须针对当前失败的同一批数据，不能在失败未解决时跳到下一页。
2. 交叉监听器与在途请求控制
IntersectionObserver 的持续相交本身不会每帧通知；但在完成加载后重新 observe 同一个依然可见的目标时可能再次通知。需要明确的是，正常串行补足一屏数据并不等于重复请求同一批数据。组件中应确保同一列表实例的各个触发入口（如初次拉取、滚动监听或重试动作）共用同一套在途状态，在当前批次完成响应与状态写入前，避免发起新的请求。
3. 长列表的渲染与数据保留
当无限滚动加载了数十批甚至上百批数据后，DOM 节点数量会成倍增加，可能引发滚动卡顿。 如果引入虚拟列表（例如 TanStack Virtual），它通过计算仅挂载当前可见区域及外围缓冲区的 DOM 节点来降低渲染压力；但必须认清的是，虚拟列表只管理 DOM 节点挂载，保存在 React 状态或客户端缓存中的数据对象并不会因此被自动释放，数据层的内存管理依然需要由应用本身考虑。
5. 接口契约：Offset 与 Cursor 的适用边界
前端列表的展现形式与后端接口的分页设计并非死板绑定，常见的后端接口有两种：
1. 基于偏移量的分页（Offset / Page）：
• 形式通常为 page=2&limit=20。
• 优点在于实现简单、支持直接跳至特定页码。
• 局限在于，若列表在用户翻页过程中频繁有新数据插入或删除，基于偏移量的计算可能会导致用户在下一页看到上一页刚浏览过的条目，或者遗漏被推移的数据。
2. 基于游标的分页（Cursor）：
• 形式通常由接口返回一个游标标记 nextCursor，前端在请求下一批时按约定回传该标记。
• 优点在于能较好地应对动态追加的数据流，不易出现偏移量滑动导致的重复；
• 局限在于它依赖后端建立稳定的排序规则，并且能区分相同排序值的数据，通常不支持在未获取前置数据前直接跳转到任意数字页。游标机制能改善数据滑动问题，但并不等同于后端提供了全局无并发冲突的瞬时快照。
6. 列表选型建议
在为新功能选择列表交互模式时，可以按以下维度梳理：
1. 强定位、需核对、需跳转：首选传统数字翻页，便于明确当前范围与定位目标条目；
2. 探索式查阅、希望控制节奏与触达页脚：优先考虑手动点击加载更多按钮，逻辑直接、状态受控；
3. 沉浸式长流内容、浏览连续性高于单项定位：采用自动无限滚动，并务必在实现中做好在途请求防重、显式同批重试机制以及必要的 DOM 优化准备。
另外需要特别提醒的是，用户点进详情页再返回时的列表数据、页码位置、筛选排序条件以及滚动距离，需要在项目中确认保存与恢复策略，可利用框架或浏览器已有能力，三种交互模式本身都不会自动保证这些状态被持久化。
