分页需安全解析参数、优化SQL查询路径、合理设计响应结构；空值/负数/超大数须校验，禁用SELECT ，避免COUNT()查总数，推荐游标分页保障单调性。
分页参数怎么安全解析
Go Web 接口里直接用 strconv.Atoi(r.URL.Query().Get("page")) 是常见但危险的做法——空值、负数、超大数字都会 panic 或返回错误结果。必须做显式校验和默认值兜底。
推荐写法：
page := 1
if p := r.URL.Query().Get("page"); p != "" {
if n, err := strconv.Atoi(p); err == nil && n > 0 {
page = n
}
}
size := 20
if s := r.URL.Query().Get("size"); s != "" {
if n, err := strconv.Atoi(s); err == nil && n > 0 && n <= 100 {
size = n
}
}
-
page和size都要非零正整数，且size建议硬性限制上限（如 100），防 SQL 注入或 OOM - 不要依赖中间件统一解析：不同接口对分页语义可能不同（比如有的用 offset/limit，有的用 cursor）
- 避免用结构体绑定（如
json.Unmarshal或schema.Decode）自动转 int——失败时静默设为 0 会导致查出意外数据
数据库层怎么高效跳过前 N 条
用 OFFSET 在 MySQL/PostgreSQL 里查第 1000 页（OFFSET 99999）会越来越慢，因为数据库仍需扫描并丢弃前面所有行。这不是 Go 层能优化的问题，得从查询策略改。
- 优先考虑游标分页（cursor-based pagination）：用上一页最后一条记录的
id或created_at作为下一页起点，SQL 变成WHERE id > ? ORDER BY id LIMIT ? - 如果必须用页码分页，给
ORDER BY字段加联合索引（如INDEX (status, created_at, id)），确保排序不走 filesort - 避免
SELECT *分页：只查业务必需字段，减少网络和内存开销
响应结构怎么设计才不埋坑
前端需要知道总条数、当前页、是否还有下一页，但「总条数」在大数据量下查 COUNT(*) 成本极高，不能无脑返回。
