GORM不支持多语言字段的全局分页排序，必须用主表确定性字段（如id）排序+应用层fallback，禁用多语言列混合ORDER BY，总数需按业务语义独立查询，推荐游标分页。
多语言混合检索下，GORM 本身不提供开箱即用的“全局分页排序”能力——它无法自动处理不同语言字段（如 title_zh、title_en、title_ja）的统一排序权重或模糊匹配优先级。所谓“全局分页”，必须靠你手动把多语言逻辑下沉到 SQL 层或应用层聚合，否则分页结果必然错乱、漏数据、重复。
多语言字段不能直接 ORDER BY 多个列做“混合排序”
常见错误是写 Order("title_zh ASC, title_en ASC, title_ja ASC")，以为能覆盖所有语言。实际问题有三个：
- 数据库对 NULL 或空字符串的排序行为不一致：MySQL 默认把 NULL 排最前，PostgreSQL 排最后，导致同一条记录在不同库中位置漂移
- 不同语言字符集 collation 不同（比如 utf8mb4_0900_as_cs vs utf8mb4_unicode_ci），
ORDER BY结果不可比，翻页时同一页可能重复出现某条记录 - GORM 的
Preload无法跨语言字段做联合排序，Preload("Translations")查出的关联数据顺序和主表不联动，分页总数计算直接失效
正确做法是：只选一个**确定性高、有索引、非 NULL**的字段作为排序主键，比如 id 或 created_at，再用应用层做语言 fallback 渲染。不要试图让数据库“智能排序多语言”。
分页必须显式 Order + 独立 Count，且不能依赖 Preload
一旦涉及多语言关联表（如 articles ←→ article_translations），Preload 和分页共用会引发严重错位：
-
db.Preload("Translations").Offset(20).Limit(10).Find(&articles)实际执行两步：先查 10 条 article，再为这 10 条发 10 次 IN 查询 translations —— 但总数Count只统计了 article 表，而前端需要的是“带有效翻译的 article 总数”，二者语义根本不同 - 如果某 article 缺少指定语言 translation，
Preload后该字段为空，但Find仍返回 article，导致“看似有数据，实则无内容” - 总数查询若写成
db.Preload("Translations").Where("language = ?", lang).Count(&total)，GORM v2 会忽略Preload，只查主表，结果不准
实操建议：
- 分页主查询只查主表（
articles），用Order("id ASC")保证稳定 - 翻译数据用批量 IN 查询补全：
db.Where("article_id IN ? AND language = ?", articleIDs, lang).Find(&translations) - 总数严格按业务语义查：要“所有文章总数”就
db.Model(&Article{}).Count()；要“有英文翻译的文章数”就db.Table("article_translations").Select("COUNT(DISTINCT article_id)").Where("language = ?", "en").Scan(&total)
搜索+分页必须拆成两阶段：先过滤 ID，再分页取主表+翻译
多语言全文检索（如标题/正文含中文、英文、日文）无法靠 GORM 原生支持。直接 Where("title_zh LIKE ? OR title_en LIKE ?", "%关键词%") 效率低、不支持分词、无法加权。
- MySQL 全文索引只支持单语言（
MATCH(title_zh) AGAINST），跨字段 OR 会放弃索引 - PostgreSQL 的
to_tsvector需按语言分别配置 dictionary，GORM 无法自动生成适配语句 - 如果前端传
keyword=go，你不能假设它只匹配英文字段——用户可能用中文搜“Go语言”，此时得查title_zh，而非title_en
可行路径：
- 用外部搜索引擎（如 Meilisearch、Typesense）做多语言检索，返回
article_id列表和排序分数 - 后端拿这个 ID 列表做二次查询：
db.Where("id IN ?", ids).Order("FIELD(id, ?)", ids).Limit(pageSize).Offset((page-1)*pageSize).Find(&articles) - 再用这批
ids批量查对应语言的 translation，避免 N+1 - 注意
FIELD是 MySQL 特有函数，PostgreSQL 要用array_position或 CTE 模拟
游标分页是多语言场景下唯一靠谱的分页方式
传统 Offset 在多语言混合下更危险：只要任意语言字段更新，ORDER BY created_at 的稳定性就被破坏（比如中文翻译晚于英文发布，但 created_at 是主表时间）。
- 游标必须基于**主表不变字段**，首选
id（自增或 UUID），次选created_at+id组合（防时间重复） - 前端首次请求不带游标，查
ORDER BY id ASC LIMIT 20；后续请求传last_id=12345，查WHERE id > 12345 ORDER BY id ASC LIMIT 20 - 禁止在游标分页里混用
Preload或Joins，它们会让 WHERE 条件变复杂，索引失效，性能断崖下跌 - 如果业务强依赖“按最新翻译时间排序”，那就把翻译时间冗余到主表（如
latest_translation_updated_at），并加索引，而不是 JOIN 后排序
真正难的不是写代码，而是接受一个事实：GORM 的链式调用模型天然不适合多语言全局排序。越早放弃“一个 Query 解决所有”的幻想，越快落地稳定分页。
