gorm高并发分页必须禁用offset、独立count查询、杜绝内存过滤；因offset需真实扫描丢弃前n行，导致i/o与cpu线性上涨、超时频发、结果不一致，须改用带索引的游标分页并严格校验参数。
高并发下 GORM 查询性能崩得快，核心就三件事：别用 Offset、别让 Count 拖后腿、别在内存里做过滤——这些不是“可以优化”，而是“必须砍掉”。
为什么 Limit+Offset 在压测中直接超时
MySQL/PostgreSQL 执行 OFFSET 50000 不是跳过前 5 万行，而是真实读、排序（若没走索引）、丢弃。每翻一页，I/O 和 CPU 开销线性上涨。5000 页 ≈ 扫 100 万行，连接池迅速占满，context deadline exceeded 频发。
- 同一页刷新两次，可能返回不同顺序、甚至漏数据——因为没加确定性排序
-
db.Offset(499999).Limit(20)这种写法在 QPS > 100 时基本不可用 - 必须显式加
Order("id ASC")或Order("created_at DESC, id DESC")，否则结果不可重现 - 前端传来的
page参数必须校验：page >= 1且pageSize限制在 1–100 之间
游标分页怎么写才不漏、不重、不 panic
游标分页本质是“基于上一页最后一条记录的排序字段值继续往后取”，绕开 OFFSET 的物理扫描缺陷。但错一个细节就会出问题。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 首排序字段必须有索引、非空、高基数：
id最稳；created_at在高并发下需加id兜底，避免时间重复 - 首次请求：不带游标，
db.Order("id ASC").Limit(21).Find(&users)（多查 1 条判断是否有下一页） - 后续请求：用上一页最后一条的
id，db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users) - 前端必须传
last_id（不是页码），后端不做转换；若last_id是负数或非数字，应返回 400，不能静默处理 - URL 中的
last_id若经 base64 编码，解码必须用base64.RawURLEncoding.DecodeString，防止+或/被误解析
Count 总数查询为什么又慢又不准
db.Where("status = ?", "active").Limit(20).Offset(40).Count(&total) 这种链式调用，Count 会忽略 Limit 和 Offset，但是否忽略 Where 取决于 GORM 版本和 session 复用逻辑，极易出错。
- 简单场景：用新 session 隔离，
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total) - 复杂关联（含
Joins或子查询）：手写子查询，db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN profiles p ON u.id = p.user_id WHERE u.status = ?) AS t", "active").Scan(&total) - 子查询外层必须有别名（
AS t），否则 PostgreSQL 报错；SELECT 1是惯用写法，避免字段膨胀 - 单表数据超 50 万行时，直接放弃
total，改用查size + 1条判断has_next—— 这比COUNT(*)稳定得多
Select 字段精简和 Preload 冲突怎么避坑
Select 不是白名单过滤，它只构造 SELECT 子句，必须配合 Find/First/Scan 才生效。一旦用了 Select，Preload 就会被忽略，且无任何警告。
- 查用户列表只取
name和email，还想带Profile.avatar_url？不能同时用Select和Preload - 方案一：先
Select("id")得到 ID 列表，再Where("user_id IN ?")查关联表 - 方案二：用
Joins("JOIN profiles ON profiles.user_id = users.id").Select("users.name, users.email, profiles.avatar_url") - 结构体字段必须加
gorm:"column:name"标签，否则大小写不一致（如结构体字段Name对应数据库列name）会导致映射为空 - 敏感字段（如
Password）要在模型里显式加gorm:"-"，别指望靠Select临时屏蔽
真正卡住高并发的，往往不是 SQL 写得差，而是连接池没设对、索引没建准、或者 Go 层把 WHERE 逻辑搬到了 for 循环里。游标分页、字段精简、独立 Count、连接池参数这四块，缺一不可——少配一个，压测时就少一条活路。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
