SDK基础实体应慎用Comparable，优先提供标准Comparator工具类；内部服务模块可有限启用Comparable；多维动态排序一律使用Comparator。
在大型 Java 系统或通用 SDK 设计中，Comparable 和 Comparator 不是“选哪个更好”，而是“谁该承担什么职责”。核心原则是：让领域模型保持稳定，把排序逻辑交给可插拔的策略。硬编码自然顺序会锁死扩展性，而滥用外部比较器又会让基础契约模糊——平衡点就在接口职责边界上。
SDK 基础实体：慎用 Comparable，优先留白
对外发布的 SDK（如支付订单 Order、用户 Profile、设备 Device）应避免直接实现 Comparable。原因很实际：
- 不同业务方对“自然顺序”理解完全不同：电商平台要按创建时间，IoT 平台要按最后上报时间，风控系统却要按风险分降序——没有唯一真理
- 一旦 SDK 中的类实现了 Comparable，下游无法覆盖或绕过，等于强制约定，违背开闭原则
- 版本升级时若修改 compareTo 逻辑，可能引发下游排序行为突变，属于不兼容变更
正确做法是：只提供必要 getter，不实现 Comparable；配套提供一组标准 Comparator 工具类（如 OrderByCreateTime、OrderByAmountDesc），用静态工厂方法封装，便于复用和文档化。
内部服务模块：按域建模，有限启用 Comparable
在单体服务或 bounded context 内部，若某类的排序规则高度稳定且具业务共识，可谨慎启用 Comparable：
- 例如金融系统的 Money 类，其“数值大小”就是天然、不可争议的自然顺序，实现 Comparable 合理且安全
- 日志事件 LogEvent 若约定“时间戳升序即自然顺序”，且全系统统一使用该语义，也可实现
- 必须确保 compareTo 与 equals 一致（x.compareTo(y) == 0 ⇔ x.equals(y)），否则 TreeMap/TreeSet 行为异常
关键约束：一个类只定义一种自然顺序，且该顺序必须是领域内无歧义、长期不变的核心语义。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
多维动态排序：一律使用 Comparator，拥抱组合与复用
真实业务中，排序几乎总是条件化的：后台管理页支持按 5 列任意切换、API 接口接收 sort=price,asc&sort=name,desc 参数、报表导出需先按部门再按绩效——这些场景必须用 Comparator：
- 用 Lambda 或方法引用快速构建临时规则，不污染模型
- 利用 Comparator.thenComparing() 链式组合，清晰表达优先级（如 .thenComparing(User::getDept).thenComparing(User::getScore, Comparator.reverseOrder())）
- 配合泛型工具方法封装：public static
List sort(List list, Comparator comp)，提升跨模块复用性
特别注意 null 安全：使用 Comparator.nullsFirst()/nullsLast() 显式声明空值位置，比在 compareTo 里手写 null 判断更健壮、更易读。
性能与稳定性：别让 compareTo 成为瓶颈
在高吞吐系统中，compareTo 被频繁调用（如 TimSort 每次比较都执行），需规避两类隐患：
- 数值溢出：禁止 this.score - other.score，改用 Integer.compare(this.score, other.score) 或 Long.compare()
- 副作用与耗时操作：compareTo 内严禁远程调用、数据库查询、文件读取；也不应触发复杂计算或对象构造
- 若排序字段需从关联对象获取（如 order.getCustomer().getName()），建议预加载或投影为扁平字段，避免 N+1 问题
Comparator 同样适用上述约束，但它更容易被隔离测试和单独优化——这是它在架构层面的关键优势。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
