sortedset.add() 排序异常的根本原因是缺少有效比较逻辑：未实现comparable或未传comparator；常见错误包括修改比较字段、compareto()不满足自反对称传递性、compare()误返回布尔值而非负/零/正值。
SortedSet.add() 不按预期排序，对象直接乱序
根本原因通常是 SortedSet（比如 TreeSet）没拿到有效的比较逻辑。它不会自动调用对象的 toString() 或字段名排序，也不看 equals() —— 它只依赖 Comparable 实现或外部传入的 Comparator。
常见错误现象：TreeSet 添加后遍历顺序和插入顺序一样，或者完全不符合你写的字段逻辑；调试时发现 compareTo() 根本没被调用。
- 确认构造
TreeSet时是否显式传了Comparator：没传且元素类没实现Comparable→ 运行时报ClassCastException - 如果用了
Comparator，检查是否在add()后又修改了参与比较的字段（比如name、score）→ 排序结构已损坏，后续行为不可预测 - 实现
Comparable时，确保compareTo()满足自反性、对称性、传递性；返回0必须对应equals()也返回true（否则TreeSet可能“去重”掉本该保留的不同对象）
Comparator.compare() 返回值写错导致重复/丢失
Java 要求 compare(a, b) 返回负数、零、正数分别表示 a b。写成布尔返回（如 return a.id > b.id）是典型坑——结果永远是 1 或 0，TreeSet 误判所有对象“相等”，只留一个。
使用场景：需要按多个字段排序（如先按 status 再按 createdAt），或字段类型不支持自然序（如 LocalDateTime 在 Java 7 下）。
立即学习“Java免费学习笔记（深入）”；
- 别手写三元运算模拟返回值：
return a.id → 易溢出且啰嗦 - 优先用
Integer.compare(a.id, b.id)、Objects.compare(a.name, b.name, String::compareTo)等工具方法 - Java 8+ 可链式构造：
Comparator.comparing(User::getStatus).thenComparing(User::getCreatedAt)，清晰且安全
TreeSet 中修改对象字段后集合行为异常
TreeSet 是基于红黑树实现的，插入时根据比较结果决定节点位置。一旦对象在集合中，再改影响排序的字段（如把 score = 85 改成 score = 95），树结构不会自动调整 —— 它既不会重新插入，也不会报错，只是让你的遍历、contains()、remove() 全部失准。
性能影响：看似只是改个字段，实际让整个集合进入“未定义状态”，后续任何操作都可能返回错误结果或抛 NullPointerException。
- 绝对不要在
TreeSet里放可变对象，尤其当字段参与排序时 - 必须修改？先
remove()，改完再add()—— 注意remove()依赖旧比较值，得确保改之前能准确定位 - 更稳妥的做法：用不可变对象（
record或 final 字段类），从源头杜绝字段变更
泛型擦除导致 Comparator 类型不匹配的隐性失败
当你写 new TreeSet(new MyComparator())，而 MyComparator 声明为 class MyComparator implements Comparator<object></object>，编译通过，但运行时比较两个 User 对象会触发 ClassCastException —— 因为泛型在运行时不存在，TreeSet 把你传的 Comparator 当成能处理任意类型，实际调用时却强转失败。
容易被忽略的地方：IDE 可能不报黄线，单元测试若只用同类型数据也测不出问题，上线后混入其他类型才崩。
- 声明
Comparator时务必指定具体类型：Comparator<user></user>，不是Comparator或Comparator<object></object> - 用 Lambda 写比较器时，类型由上下文推导，一般安全；但若泛型参数模糊（比如方法返回
SortedSet但没写明类型），推导可能出错 - 检查
TreeSet的泛型参数和Comparator的泛型是否严格一致，差一个? super User都可能导致运行时异常
真正麻烦的不是写不对 compareTo()，而是写对了但对象中途被改、或者泛型糊弄过去编译了——这两种情况都不会立刻报错，而是让集合悄悄失效，查起来要翻半天日志和集合快照。
