Beego ORM 的 OrderBy 必须链式调用且位于 Limit/Offset 前，参数为纯字段名字符串：升序直接写如 "name"，降序加负号如 "-created_at"；支持多字段如 "status", "-updated_at", "id"，严格按顺序生效，NULL 排序依赖数据库行为，字段名错误或类型不匹配将导致静默失效。
Beego ORM 的 OrderBy 用法和参数格式
Beego 的 ORM 排序必须通过 OrderBy 方法链式调用，不能写在 Where 或 Limit 后面随意拼接。参数是字符串，字段名**不加表名前缀**，也不用反引号或引号包裹，直接写字段名即可；升序不加修饰，降序需在字段名前加减号 -。
常见错误：写成 "name ASC"、"`created_at` DESC" 或 "user.name" —— 这些都会被忽略或报错。
-
qs.OrderBy("name")→ 按name升序 -
qs.OrderBy("-created_at")→ 按created_at降序 -
qs.OrderBy("status", "-updated_at", "id")→ 多字段排序：先按status升序，相同再按updated_at降序，再按id升序
多字段排序时的执行顺序和空值影响
Beego ORM 的 OrderBy 是严格按参数顺序生效的，等价于 SQL 中的 ORDER BY status ASC, updated_at DESC, id ASC。但要注意：如果某字段允许 NULL，MySQL 默认把 NULL 排在最前（升序）或最后（降序），而 PostgreSQL 行为相反；Beego 不做干预，完全交由数据库处理。
如果你依赖确定的 NULL 排序位置（比如希望 NULL 总排最后），得改用 Raw 查询手动写 COALESCE 或 IS NULL 判断，ORM 层无法抽象这一层。
- 升序字段含 NULL：MySQL 中会最先出现，可能不符合业务预期
- 多个字段组合排序时，前一字段值相等才触发后一字段比较，逻辑清晰但不可跳过中间字段
- 字段名拼写错误（如大小写不一致）不会报错，但排序失效——建议用结构体字段名严格对照
与 Limit/Offset 配合时的常见陷阱
排序必须在 Limit 和 Offset 之前调用，否则会被忽略。Beego ORM 的查询构建是“声明式”的，执行顺序由方法调用顺序决定，不是最终 SQL 的语法顺序。
错误写法：qs.Limit(10).OrderBy("-id") → OrderBy 实际不生效。
- 正确顺序：
qs.OrderBy("-id").Limit(10) - 分页场景务必先
OrderBy再Limit+Offset，否则同一页数据可能重复或遗漏 - 如果没写
OrderBy，MySQL 返回结果顺序不确定，尤其在 InnoDB 聚簇索引变动后，不要依赖默认顺序
字段类型不匹配导致排序异常的典型表现
当对字符串字段按数值逻辑排序（如 "10"、"2"、"11"）却没加类型转换时，数据库会字典序排成 "10", "11", "2"。Beego ORM 不做类型推断或隐式转换，它只负责把 OrderBy 字符串原样传给 SQL。
这种情况在 ID 字段存为 varchar、版本号字段、编码编号等场景很常见。
- 解决方案只有两种：改字段类型为整型，或用
Raw手动写CAST(id AS SIGNED) - 时间字段如果存的是字符串（如
"2023-01-01"），OrderBy("-created_at")可以正常工作，因为 ISO 格式字符串字典序 ≈ 时间序；但如果是"01/01/2023"就会乱序 - JSON 字段、TEXT 字段无法用于高效排序，即使写了
OrderBy，数据库也可能放弃使用索引，查慢且不稳定
Beego 的 OrderBy 看似简单，但字段定义、数据库行为、调用时机这三处稍有偏差，结果就可能完全不对——尤其是上线后数据量变大，排序错位才暴露出来。
