GORM 本身不提供日志分页能力，它只是 ORM 工具；所谓“GORM 在日志分页中的实践”，本质是用 GORM 查询数据库里的日志表，并手动实现分页逻辑——而这个逻辑在 CI/CD 流水线中极易因并发写入、时间戳漂移、ID 不连续等问题翻车。
直接说结论：GORM 本身不提供日志分页能力，它只是 ORM 工具；所谓“GORM 在日志分页中的实践”，本质是用 GORM 查询数据库里的日志表，并手动实现分页逻辑——而这个逻辑在 CI/CD 流水线中极易因并发写入、时间戳漂移、ID 不连续等问题翻车。
为什么不能直接用 OFFSET + LIMIT 做流水线日志分页
很多团队一开始会写类似 db.Offset((page-1)*size).Limit(size).Find(&logs) 的代码，结果上线后发现：第 3 页突然跳过 2 条日志、刷新后同一页内容变化、高并发时返回重复或漏掉的记录。
- 流水线日志是高频追加写场景，
id主键可能不严格递增（比如用 UUID 或分布式 ID 生成器） -
OFFSET在大数据量下性能陡降，MySQL 8.0 之前还会锁表扫描前 N 行 - CI/CD 系统常有重试、回滚、并行阶段，日志插入时间戳可能乱序，按
created_at排序分页也不可靠
推荐用游标分页（cursor-based pagination）替代页码分页
核心思路：不传 page=3，而是传上一页最后一条日志的唯一、有序标识（如 id 或 timestamp+id 组合），查“比它更新”的下一批。
- 必须确保游标字段有索引，且值全局唯一、单调可比较；推荐用自增
id或带毫秒精度的created_at+id - GORM 查询写法示例：
db.Where("id > ?", lastID).Order("id ASC").Limit(50).Find(&logs) - 前端需保存并透传
next_cursor，后端响应里带上新游标：{"logs": [...], "next_cursor": "12345"} - 注意边界：首次请求无游标，用
ORDER BY id DESC LIMIT 50拿最新一批，再反向翻页
流水线日志表设计必须适配分页查询模式
别直接复用业务库的通用日志表结构。CI/CD 日志有强时效性、高写入、低更新特征，表结构要为游标分页服务：
- 主键必须是数值型自增
id（不用 UUID），且禁止逻辑删除（避免游标断层） - 加联合索引：
INDEX idx_pipeline_id_created_at_id (pipeline_id, created_at, id)，支撑按流水线 ID + 时间范围快速定位 - 定期归档旧日志（如 >90 天），避免单表超千万行拖慢游标查询；归档后保留元数据表映射游标偏移
- 避免在日志表里存大字段（如原始 job stdout），应存压缩后的 URL 或分表存储，否则
LIMIT 50也会变慢
云原生环境下 GORM 连接池与事务需显式控制
在 Kubernetes 中跑 CI/CD 服务，Pod 可能被频繁重建，GORM 默认连接池配置（MaxIdleConns=2, MaxOpenConns=0）会导致连接泄漏或超时失败。
- 务必设置
db.SetMaxIdleConns(10)和db.SetMaxOpenConns(30)，值根据并发日志读请求数调整 - 日志分页查询无需事务，但若涉及“标记已读”“清理过期”等操作，必须用
db.Transaction()包裹，且超时设短（context.WithTimeout(ctx, 3*time.Second)） - 注意 GORM v2 的
WithContext()是非侵入式，但若底层用 pgx 驱动，需额外配置pgxpool.Config.MaxConns避免连接耗尽
真正容易被忽略的点：游标分页不是加个 WHERE id > ? 就完事——它要求整个日志写入链路（从 runner 上报 → API 接收 → GORM 插入）全程保证顺序性和幂等性。一旦某次插入因网络重试导致两条日志 ID 乱序，下游分页就不可靠。所以生产环境必须在 API 层做接收顺序校验，而不是把问题留给 GORM 查询层扛。
