uni-app前端无法直接分页，必须由后端返回total字段并配合uni-pagination组件实现；pageSize变更时需手动重置current为1并清缓存，否则导致空白页。
uni-app 本身不直接操作数据库，分页必须由后端服务完成，前端只负责传参、渲染和翻页控制。 所有“uni-app 实现数据库分页”的说法，本质是前端配合后端接口完成分页交互——你看到的 uni-pagination 只是个 UI 组件，它不连数据库，也不执行 SQL。
为什么不能在 uni-app 前端做真正的数据库分页
uni-app 运行在客户端（小程序、App、H5），没有权限直连 MySQL、PostgreSQL 或云数据库（除非用 uniCloud 且显式开启 DB 权限，但即便如此，也需走云函数封装）。所谓“前端分页”，实际只有两种情况：
- 数据量极小（slice() 就够了
- 真分页：每次点击页码，uni-app 发起新请求，把
page和pageSize（或start）传给后端，后端查数据库时用LIMIT offset, size或OFFSET-FETCH等语法返回对应数据
混淆这两者，会导致上线后列表卡死、内存溢出或数据错乱。
uni-pagination 的正确传参方式：current 和 pageSize
uni-pagination 默认使用 current（当前页码，从 1 开始）和 pageSize（每页条数）两个参数。你必须在请求中把它转成后端能用的格式：
- 如果后端接口要求
page=2&size=10→ 直接传{ page: e.current, size: this.pageSize } - 如果后端用
start偏移量（如start=10&pageSize=10）→ 计算为(e.current - 1) * this.pageSize - 务必校验
e.current是否合法（≥1，≤Math.ceil(total / pageSize)），避免传负数或超大值触发后端异常
示例代码片段：
pageChanged(e) {
this.pageIndex = e.current;
uni.request({
url: 'https://api.example.com/list',
data: {
start: (e.current - 1) * this.pageSize,
pageSize: this.pageSize
},
success: res => {
this.list = res.data.items;
this.total = res.data.total;
}
});
}后端必须返回 total 字段，否则分页器无法计算总页数
uni-pagination 的 :total 属性不是可选的——它决定了是否显示末页按钮、总页数、禁用逻辑。如果后端只返回数组，没带总数，分页器会显示 “1 / ?” 或直接失效。
- MySQL 场景：必须额外执行
SELECT COUNT(*) FROM table WHERE ...，和主查询并行或合并（如子查询） - uniCloud 场景：用
db.collection('xxx').count()+.skip().limit()两次调用，或聚合管道$facet一次返回 - 别用前端算
list.length当 total：那只是当前页条数，不是全量
常见错误是后端只返回 data: [...] ，前端硬写 :total="100" —— 这会让搜索、筛选后的分页完全错乱。
容易被忽略的边界点：pageSize 变更与缓存同步
用户切换每页显示 10/20/50 条时，uni-pagination 不会自动重置 current。这意味着：
- 当前是第 5 页（共 100 条，每页 20 条），切到每页 50 条后，
current还是 5，但第 5 页已不存在（总共才 2 页） - 必须手动将
current重置为 1，并重新请求 - 如果用了本地缓存（如
uni.setStorageSync存页码），也要一并清理，否则下次打开还是从非法页开始
这个逻辑不在组件内，必须你写在 pageSize 改变的监听里，否则上线后用户会频繁遇到“空白页”或“404”。
