GORM 查询需动态适配 React 表格列请求：前端通过 ?fields=id,name,email 传白名单字段，后端校验后拼接 SELECT 子句，用 db.Raw().Scan(map[string]interface{}) 接收结果；分页参数须校验 page≥1、pageSize∈[1,100]；Count 查询需独立会话且条件与主查一致；返回前统一格式化 time.Time 和 float64 类型以避免前端解析错误。
如何让 GORM 查询动态适配 React 表格的列请求
React 表格（如 react-table 或 AG Grid）常通过前端传来的 columns 字段声明需要哪些字段，后端不能硬编码 SELECT * 或固定字段列表。GORM 本身不支持运行时拼接 SELECT 字段，必须手动构造 SELECT 子句并用 Raw() 或 Scan() 配合 map[string]interface{} 处理。
常见错误是直接对结构体调用 Find()，结果返回多余字段、触发 N+1、或因字段缺失 panic；更隐蔽的问题是用了 Select("id, name") 但没同步更新 Scan() 目标类型，导致字段映射错位。
- 前端应通过 query 参数（如
?fields=id,name,email,created_at）传递所需列名，后端校验白名单后再拼接 - 使用
db.Raw("SELECT ? FROM users WHERE ...", clause.Expr{SQL: strings.Join(allowedFields, ", ")})不安全，改用字符串拼接 + 白名单过滤（map[string]bool{"id":true, "name":true, ...}） - 查询结果必须用
map[string]interface{}接收，不能用结构体：否则 GORM 会按结构体字段名绑定，忽略动态列或报sql: Scan error on column index X - 注意 PostgreSQL 对大小写敏感，MySQL 默认忽略——统一转小写校验字段名可避免环境差异
GORM 分页 + 动态列组合时 count 查询怎么写才不出错
分页必须先查总数，但 Count() 无法复用 Raw() 的 SELECT 字段逻辑，且 Count() 忽略 Select()。若直接 db.Model(&User{}).Where(...).Count(&total)，可能因 JOIN 或 WHERE 中引用了动态列字段而失败（比如前端只要 name，但 count 语句里没 JOIN 关联表，却在 WHERE 里用了 profile.bio）。
- count 查询必须和主查询共享完全相同的
WHERE、JOIN、GROUP BY条件，但去掉SELECT和ORDER BY；可用Session(&gorm.Session{NewDB: true})克隆查询对象再清理字段 - 避免用
Count()直接扫全表：加Limit(1)并捕获RowsAffected是更可控的方式，尤其当表无主键或含复杂视图时 - 如果动态列涉及 JSON 字段（如
info->>'age'），count 查询中不能出现该表达式——需提前识别并从 count 查询中剥离
React 表格分页参数怎么安全映射到 GORM 的 Offset/Limit
前端表格组件通常传 page=2&pageSize=20，但直接算 Offset = (page-1)*pageSize 有整数溢出、负数、超大页码风险。GORM 的 Limit() 和 Offset() 对非法值不校验，可能触发全表扫描或 SQL 报错。
- 强制设置
pageSize上限（如 100），超出则截断并记录 warn 日志，防止恶意请求拖垮数据库 -
page必须 ≥ 1，pageSize必须 ≥ 1，否则返回 400 并附带错误字段名（如{"field":"page","message":"must be >= 1"}） - 不要用
Offset()模拟游标分页；大数据量时改用基于主键/时间戳的WHERE id > ? LIMIT ?，否则 offset 越大越慢 - PostgreSQL 可用
OFFSET ... ROWS FETCH NEXT ... ROWS ONLY，但 GORM 未封装该语法，仍得走Limit()/Offset()，所以务必前置校验
为什么 map[string]interface{} 返回给 React 时日期变字符串、数字变 float64
GORM 用 Scan() 填充 map[string]interface{} 时，数据库的 TIMESTAMP 会转成 time.Time，INT 变 int64，但 JSON 序列化时 time.Time 默认格式化为字符串，int64 在 JavaScript 里能表示，但 float64（来自 DECIMAL 或 AVG）会丢失精度。前端表格看到 "created_at": "2024-05-20T14:23:11Z" 是对的，但 "score": 99.00000000000001 就不对了。
- 在返回前遍历
map[string]interface{}，对time.Time类型调用.Format("2006-01-02T15:04:05Z07:00")统一格式 - 对
float64类型，检查是否为整数值（math.Floor(v) == v），是则转int64再序列化，避免 JS 精度问题 - 禁止用
json.MarshalIndent直接输出，应封装一层转换函数，否则前端无法区分 “0”（字符串）和 0（数字） - 这个环节最容易被跳过——开发时数据量小看不出问题，上线后财务类数字报表开始出错才排查
