全局分页需基于缓存键（cacheKey）管理各筛选条件下的分页数据，复用已加载内容、避免重复请求，并支持状态追溯与恢复；Store 中按 cacheKey 组织 pages 缓存，翻页优先读缓存，缺页再请求，配合 history 与持久化实现毫秒级返回和刷新恢复。

全局分页不等于每次请求都重载数据，关键是在用户翻页时复用已加载的内容、避免重复请求，同时保持状态可追溯、可恢复。核心是把“当前页码”“每页条数”“筛选条件”和“各页数据”一起纳入 Store 管理，并按需缓存。

设计带缓存键的分页状态结构

不要只存 currentPage 和 pageSize，而要为每组查询条件生成唯一缓存键（cacheKey），再映射到对应的数据页集合：

• 缓存键建议由 JSON.stringify({ filter, sort, pageSize }) 生成，确保相同条件复用同一份缓存
• Store 中维护对象如：{ [cacheKey]: { data: [], total: 0, pages: { 1: [...], 2: [...] } } }
• 切换筛选条件时自动清空对应 cacheKey 下的 pages，但保留 total（避免重复查总数）

翻页时优先读缓存，缺页再请求

用户点击第 5 页时，先检查 state[cacheKey].pages[5] 是否存在：

• 存在 → 直接渲染，不发请求
• 不存在 → 发起仅获取第 5 页的请求（page=5&size=20），成功后 merge 进 pages[5]
• 若请求返回空数组或 total 变更，需同步更新 total 并清空后续页缓存（如第 6 页起可能已失效）

支持「回到前一页」与「页面刷新后恢复」

利用 Store 持久化 + 历史记录联动：

• 每次有效翻页（含筛选变更）都 push 一条轻量 history state：{ cacheKey, page }，不存数据本身
• 浏览器后退/前进时，从 history 取出 cacheKey 和 page，立即从 Store 中读取对应页数据（毫秒级响应）
• 页面刷新前用 localStorage 或 pinia/persist 插件保存当前 cacheKey + page，刷新后自动 restore 并尝试拉取缺失页

边界处理：跳页、清空、并发安全

用户输入跳转页码或重置筛选时，逻辑要明确且防抖：

• 跳转到未缓存页（如从第 2 页直接输“100”）→ 先展示 loading，请求该页；成功后再补全中间缺失页（可选，按需懒加载）
• 点击「清空筛选」→ 清除所有 cacheKey 缓存，重置为初始状态
• 多个分页区域共存（如订单页 + 日志页）→ 每个用独立 cacheKey，互不影响；Store action 加命名空间或模块隔离