Comparable 接口不参与 MyBatis 动态 SQL 字段映射，仅用于 Java 内存中集合的本地排序；MyBatis 的 ORDER BY 在数据库层面执行，两者运行阶段、作用域和技术层级完全不同。
Comparable 接口本身不参与 MyBatis 动态 SQL 的字段映射，它和 SQL 层的排序逻辑没有直接关联。它只在 Java 内存中对 List、Set 等集合做本地排序，而 MyBatis 动态 SQL 的 ORDER BY 是在数据库层面执行的——两者运行阶段、作用域、技术层级完全不同。
为什么 Comparable 无法映射到 MyBatis 动态 SQL 字段
MyBatis 的动态排序依赖的是 SQL 字符串拼接（如 ${sortField} ${sortOrder}）或 XML 中的 <choose> + <when> 映射规则；而 Comparable 是 Java 类实现的 compareTo() 方法，仅影响 Collections.sort() 或 Arrays.sort() 等 JVM 内存操作。数据库根本看不到这个接口，SQL 引擎也不会调用 Java 方法。
常见误解是：“我给 User 实现了 Comparable，那 MyBatis 查询时就自动按注册时间排好了”——这完全错误。MyBatis 返回的数据顺序，只由 SQL 的 ORDER BY 子句决定，与实体类是否可比较无关。
真正起作用的字段映射方式
要让前端传来的排序参数安全生效，需通过以下机制完成“字段名 → 数据库列名”的映射：
立即学习“Java免费学习笔记（深入）”；
-
白名单校验 + 驼峰转下划线：接收前端字段如
createTime，先检查是否在预设白名单中（如["id", "createTime", "price", "status"]），再转换为create_time供 SQL 使用 -
枚举驱动映射：定义
SortFieldEnum，每个枚举项绑定真实列名和类型，例如CREATE_TIME("create_time", LocalDateTime.class)，避免字符串硬编码 -
MyBatis XML 中用 <choose> 分支匹配：根据传入的
field值，显式写出每个合法字段对应的真实列名，杜绝直接拼接不可信参数 -
禁止裸用 ${} 拼接任意字段：若未做白名单/枚举校验，直接
order by ${field} ${order}极易引发 SQL 注入，哪怕字段来自前端也必须严格过滤
Comparable 和 MyBatis 可以协同的场景
虽然 Comparable 不参与 SQL 构建，但在某些边缘环节能辅助增强体验：
-
分页后二次微调：数据库已按
create_time DESC排好主序，但同时间戳的记录需按用户名稳定排序，可在 Java 层用thenComparing(User::getUsername)补充 -
内存聚合结果排序：多表查询后数据合并成 Map 或自定义 VO 列表（如示例中的
CommoditiesRetailerVo），此时Comparable或Comparator是唯一可行的排序手段 -
Mock 测试或离线分析：单元测试中绕过数据库，用内存 List 模拟结果集，此时
Comparable能快速验证排序逻辑是否符合预期
记住一个原则：数据库排序交给 MyBatis 动态 SQL 安全拼接，Java 内存排序交给 Comparable/Comparator 精细控制。混用可以，错位映射不行。
