gorm 不处理文件分片，仅持久化分片元数据；高性能分页需避免 offset、排除大字段、加联合索引，并用游标分页替代深分页。
直接说结论：GORM 本身不处理“文件分片”，它只管数据库；所谓“高性能文件分片分页”，本质是「用数据库记录文件分片元数据 + 合理分页查这些记录」，而不是让 GORM 去读或切文件。真要分片上传/下载，得靠 HTTP multipart、流式读写、对象存储 SDK（如 AWS S3 MultipartUpload）等，GORM 只负责持久化每一片的 file_id、part_number、etag、size、uploaded_at 等字段。
为什么不能用 GORM 直接分页读文件内容
GORM 是 ORM，不是文件系统抽象层。它没有 ReadAt、Seek 或分块流控能力。试图用 db.Limit(10).Find(&parts) 去“分页加载大文件二进制”只会触发全量 BLOB 字段加载，内存爆炸且极慢。
- 常见错误现象：
SELECT * FROM file_parts WHERE file_id = ?返回 10 条记录，但每条含 5MBcontent字段 → 单次查询吃掉 50MB 内存，GC 频繁，超时率飙升 - 正确做法：数据库只存元数据，文件本体走对象存储（MinIO/S3），GORM 查的是
part_number和url（预签名链接） - 如果硬要用数据库存二进制，必须在模型里排除
content字段：用db.Select("id,file_id,part_number,etag,size,uploaded_at").Where(...).Find(&parts)
分页查分片元数据：Offset 分页的坑与绕过方式
查某文件的全部分片（比如恢复上传状态、校验完整性），常需分页拉取 file_parts 表。这里 Offset 分页在分片数超 10 万时会明显变慢——因为 MySQL 必须扫描并丢弃前 N 行，哪怕只取 20 条。
- 必须加确定性排序：
.Order("part_number ASC")或.Order("uploaded_at ASC, id ASC")，否则第 2 页可能重复或漏掉分片 - 禁止前端传裸
offset参数：攻击者发?offset=9999999&limit=1会让 DB CPU 拉满；应只接受page和page_size，并在服务端做范围校验（如page ） - 大数据量场景（单文件超 5 万片），改用游标分页：前端传上一页最后的
part_number，后端查WHERE file_id = ? AND part_number > ? ORDER BY part_number ASC LIMIT 20 - 确保
file_id + part_number有联合索引：db.Exec("CREATE INDEX idx_file_parts_file_id_part ON file_parts(file_id, part_number)")
GORM 分页查询分片元数据的实操写法
假设你已建好表：
type FilePart struct {
ID uint64 `gorm:"primaryKey"`
FileID string `gorm:"index"`
PartNumber int `gorm:"index"`
ETag string
Size int64
UploadedAt time.Time
}
安全分页查某文件的分片列表：
- 校验参数：
page≥ 1，page_size∈ [1, 100]，file_id非空且格式合法（如 UUID） - 总数查询别和分页混用：
db.Model(&FilePart{}).Where("file_id = ?", fileID).Count(&total)，不能复用带Limit/Offset的 DB 实例 - 分页查元数据（不含大字段）：
db.Where("file_id = ?", fileID).Order("part_number ASC").Offset((page-1)*pageSize).Limit(pageSize).Find(&parts) - 若需返回预签名 URL，不要在 GORM 查询里拼接，而是在循环中调用对象存储 SDK 生成，避免阻塞 DB 连接
最易被忽略的一点：分片上传完成后的「合并」操作（如 S3 CompleteMultipartUpload）和分页无关，但它的触发条件（所有分片已存库 + 全部 etag 校验通过）必须原子化检查——别用多次 SELECT 判断，而要用一条 SELECT COUNT(*) FROM file_parts WHERE file_id = ? AND status = 'uploaded' 对比总分片数，否则并发下可能误触发合并。
