文章目录
- 引言：数据保存下来了，列表也要跟着长大
- 一、本篇学习目标与准备
- 二、先约定参数与返回结果
- 1. 三个查询参数
- 2. 返回分页元数据
- 3. 这会改变上一篇的默认行为
- 三、completed 为什么还要使用指针？
- 四、Handler：参数不合法，就明确告诉调用方
- 1. 区分“没传”与“传了空值”
- 2. 本篇拒绝未知与重复参数
- 3. Service 也要验证范围
- 五、先筛选，再排序，最后分页
- 为什么必须明确排序？
- 六、SQLite：列表与总数共用筛选条件
- 1. 拼接结构，绑定数据
- 2. 为什么两次读取放进同一个事务？
- 3. 单连接下别混用 db 和 tx
- 4. 增加筛选索引
- 七、内存实现也要遵守同一份约定
- 八、运行：准备5条任务，再查一页未完成任务
- 1. 安装依赖并启动
- 2. 在空数据库创建5条任务
- 3. 请求未完成任务的分页
- 九、测试重点：false、总数、空页和参数边界
- 1. 两种存储共用一组行为测试
- 2. HTTP 测试检查参数确实传到了数据库
- 3. 本次实际验证了什么？
- 十、分页上线后，还要理解哪些边界？
- 1. 固定排序不等于跨请求结果固定
- 2. 深分页为什么仍然可能慢？
- 3. 前端切换筛选条件时，记得重置偏移
- 练习1：增加关键词搜索
- 练习2：增加游标分页
- 练习3：检查查询成本
- 十一、本篇小结与下一步
✍创作者：全栈弄潮儿
🏡 个人主页：全栈弄潮儿的个人主页
🏙️ 个人社区，欢迎你的加入：全栈开发社区
📙 专栏：Go零基础实战
引言：数据保存下来了，列表也要跟着长大
第21篇，我们搭建了待办事项 API；第22篇接入 SQLite，让任务在服务重新启动后仍然存在。
接下来，只要持续使用，就会出现新的问题：任务越来越多，列表接口还在一次返回全部数据。前端只想看未完成任务，却得先下载整个列表，再自己筛选。
本篇继续改造同一个项目，为列表增加分页和完成状态筛选。我们不仅要写出 LIMIT 和 OFFSET，还要讲清楚：默认返回多少条、false 怎么处理、total 应该统计什么，以及为什么总数和列表最好在同一个事务里读取。
完成以后，前端可以这样查询：
