GORM 不支持原生行列转换与分页，因 pivot 结果列动态、结构体字段需静态，且 Limit/Offset 作用于原始行而非 pivot 后行；可行方案是用 db.Raw() 写明确列的 pivot SQL 子查询，外层分页并单独查总数。
GORM 本身不支持“行列转换”（pivot/unpivot）操作，更不存在针对多维矩阵数据的原生分页能力。所谓“行列转换分页”，本质是前端或中间层对聚合结果做二次处理，而 GORM 只负责把原始行数据查出来——你不能指望 db.Table("sales").Pivot("month", "product", "amount") 这种写法能跑通，它根本不是 GORM 的函数。
为什么 Pivot + 分页在 GORM 层无法直接实现
数据库层面的行列转换（如 MySQL 的 GROUP_CONCAT + MAX(CASE WHEN ...)、PostgreSQL 的 crosstab()）必须在 SQL 中完成，且结果集结构是动态的（列名由数据决定），而 GORM 的 Find(&slice) 要求目标结构体字段固定。一旦列不确定，Scan 就会失败或漏字段。
- 你无法用
db.Model(&Sale{}).Select("...").Group("product").Find(&results)得到带动态月份列的 struct —— Go 编译期类型就定死了 -
Limit/Offset是对最终结果集行数生效的，但 pivot 后的“一行”可能对应原始表的 N 行；直接套用会错乱：第 2 页可能跳过某个 product 的全部月份数据 - 总数统计也失效：
Count()查的是原始 sales 行数，不是 pivot 后的 product 行数，两者完全不等价
可行路径：先聚合再分页，而非在 pivot 结果上分页
真正可落地的做法，是把“行列转换”逻辑下沉到 SQL，用子查询包裹 pivot 结果，再对这个静态结构的结果集做分页。GORM 支持 Raw 和 Scan，这是唯一可控方式。
- 用
db.Raw()写完整 pivot SQL，确保输出列明确（如product_name, jan, feb, mar, ...），然后 Scan 到一个预定义 struct - 分页必须加在最外层：例如
SELECT * FROM (你的 pivot 子查询) AS t LIMIT ? OFFSET ?，而不是在子查询里加 Limit - 总数得另查：同样用
db.Raw("SELECT COUNT(*) FROM (你的 pivot 子查询) AS t").Scan(&total)，不能复用同一个 Raw 实例 - 排序字段必须是 pivot 后的列（如
ORDER BY product_name ASC），不能用原始表字段（如sale_date），否则 SQL 会报错
容易被忽略的三个硬伤
即使写出正确 SQL，以下三点仍会导致线上翻车：
- MySQL 8.0+ 才原生支持
PIVOT关键字，低版本只能手写CASE WHEN，字段数一多 SQL 就极难维护；PostgreSQL 需装tablefunc扩展，部署环境未必允许 - pivot 结果集宽度（列数）随业务增长而变，比如从 12 个月扩到 24 个月，Go struct 必须同步改、重新编译，无法热更新
- 如果 pivot 维度（如地区 × 时间 × 类目）超过 2 层，SQL 复杂度指数上升，
OFFSET分页性能会断崖下跌——此时应放弃行列转换，改用前端聚合（查明细 + JS pivot）或物化视图预计算
别试图让 GORM “理解”矩阵结构。它只认行和列的静态映射。真要支撑多维分析类分页，pivot 逻辑该交给数据库视图或 ClickHouse 这类 OLAP 引擎，GORM 只做最后一层取数和分页即可。
