应使用Math.ceil(count / limit)实时计算最大页码并比较：const page = parseInt(obj.curr, 10) || 1; const maxPage = Math.ceil(count / limit); const isLast = page >= maxPage，且count必须来自最新响应（如done回调中的res.count），不可依赖obj.pages或UI显示的页码。
laypage.render 里怎么知道当前页是最后一页
不能靠 obj.curr === obj.pages 判断，因为 pages 字段在 laypage 内部不总是可靠：它只在初始化时根据 count / limit 算一次，后续 count 变了（比如搜索后总数变少），pages 不会自动更新，仍用旧值。
真正有效的判断方式，是每次需要时实时计算最大合法页码：
-
const maxPage = Math.ceil(count / limit)—— 必须用当前最新的count和limit -
const isLast = obj.curr >= maxPage—— 注意用>=，因为curr可能是字符串（如跳页框输入 "999"），而maxPage是 number，隐式转换可能导致误判，建议先parseInt(obj.curr, 10) || 1 - 这个
count必须来自最新响应（比如done回调里的res.count），不能用初始化时的旧值
table.reload() 后怎么判断是否到了最后一页
表格组件的 reload 行为和 laypage 不同：它不会自动 fallback curr，而是直接忽略超限页码，保持原页不动。这意味着你传了 page: { curr: 10 }，但实际页面还停在第 4 页，此时 table.cache 和 UI 显示一致，但请求参数已错。
所以 reload 前必须手动约束：curr = Math.min(curr, Math.ceil(count / limit))。这个 count 同样不能是缓存值，得是刚从后端拿到的最新总数。
- 别在
done回调里立刻reload()—— 此时 DOM 还没刷新，table.cache仍是上一轮数据，算出的maxPage会偏大 - 如果要用
table.cache['id'].length辅助判断（比如最后一页行数不满limit），得确认该数组长度确实等于当前页真实渲染条数，而不是总数据量
jump 回调里判断最后一页要注意什么
jump 是唯一能捕获用户主动翻页动作的地方，但它首次渲染也会触发一次（first === true），这时 obj.curr 是配置里的初始值，不代表用户操作，也不反映真实分页状态。
- 必须加
if (!first)条件，否则首页加载就执行判断逻辑，可能误触发重载或状态更新 -
obj.curr在跳页框回车时是字符串（如"5"），直接参与数值比较会出问题，务必先转成整数：const page = parseInt(obj.curr, 10) || 1 - 不要在
jump里直接读obj.pages，它不是响应式字段，也不会随count动态更新
为什么不能依赖分页器 UI 上显示的“5/5”来判断
分页器上显示的 “5/5” 文案，是 laypage 渲染时基于当时 count 和 limit 算出来的，但它不保证和后端实际返回数据匹配。常见场景是：搜索后后端只返回 30 条，count: 30，limit: 20 → 应该只有 2 页，但分页器仍显示 “5/5”，因为 count 没同步更新过去。
这种 UI 和数据不一致的问题，根源在于开发者把分页状态维护交给了 UI 组件，而不是自己管理 count、limit、curr 三者的同步关系。
最易被忽略的点是：count 的来源必须唯一且及时——它只能来自最近一次成功响应的 res.count，且必须在 render 或 reload 前完成赋值，不能靠 laypage 自己猜。
