Collections.sort() 是最直接的学生成绩排序方法，需 Student 实现 Comparable 或传 Comparator；注意成绩相等时显式处理顺序、避免 float 精度问题、预处理空值，并区分排序与名次计算。
用 Collections.sort() 对学生成绩列表排序
Java 里最直接的成绩排名实现，就是把 Student 对象放进 List，再调用 Collections.sort()。前提是 Student 要实现 Comparable 接口，或传入自定义 Comparator。
常见错误是只重写 toString() 或没处理成绩相等时的顺序——这会导致排名并列但索引错位。比如两个 95 分学生，按默认 compareTo() 可能返回 0，sort() 会认为它们“相等”，实际排序结果不稳定（尤其在 Java 7+ 的 TimSort 下）。
- 推荐显式比较：先比成绩降序，成绩相同时按姓名升序（避免随机顺序）
- 成绩字段建议用
double或BigDecimal，别用float（精度问题可能导致 89.9999999 和 90.0 被判为不同） - 如果原始数据来自数据库或 CSV，确保解析后已 trim 空格、过滤空值，否则
NullPointerException会在sort()时爆发
用 Stream.sorted() 实现链式成绩排名
Java 8+ 更函数式的做法是走 Stream：读取 List 后调用 sorted()，再用 collect() 拿回新列表。它不修改原集合，适合需要保留原始顺序的场景（比如同时展示“原始录入顺序”和“排名后顺序”）。
注意 sorted() 返回的是 Stream，不是 List；漏掉 collect(Collectors.toList()) 会导致编译失败或空指针（如果后续直接调用 get(0)）。
立即学习“Java免费学习笔记（深入）”；
- 降序写法：
sorted(Comparator.comparingDouble(Student::getScore).reversed()) - 多级排序：用
thenComparing()补充第二优先级，比如.thenComparing(Student::getName) - 性能提醒：
Stream.sorted()底层仍是数组排序，大数据量（>10 万条）时比原地Collections.sort()略慢，因涉及装箱/拆箱和中间对象创建
处理并列排名（同分同名次）的逻辑补丁
业务上“成绩相同，名次相同”（如 95、95、90 → 名次为 1、1、3）不是排序能自动解决的，得手动打标。排序只是第一步，真正排名号得遍历已排好序的列表来算。
最容易踩的坑是循环里用 i + 1 当名次——这给出的是“位置序号”，不是“排名序号”。必须检测当前成绩是否等于前一名，相等就沿用前一名次，否则名次 = 前一名次 + 1。
- 初始化
rank = 1，首元素名次必为 1 - 从下标 1 开始遍历，判断
list.get(i).getScore() == list.get(i-1).getScore() - 别在
Comparator里硬塞排名逻辑——那会污染排序语义，且无法处理“跳名次”（如 1、1、3）
用 TreeSet 自动去重+排序？小心数据丢失
有人想省事，直接把 Student 往 TreeSet 里塞，靠自然排序自动排好又去重。但这是危险操作：只要两个学生分数相同、compareTo() 返回 0，TreeSet 就认为它们是同一个元素，后者会覆盖前者。
哪怕你加了姓名比较，只要 compareTo() 逻辑里没把所有区分字段都纳入（比如漏了学号），依然可能误删。真实业务中，“同分不同人”是常态，TreeSet 不适合当成绩排名容器。
- 真要唯一标识，请用
TreeMap（key 为学号），再用values().stream().sorted(...) -
LinkedHashSet也不能替代排序——它只保插入序，不提供任何排序能力 - 如果必须用 Set 体系，选
TreeSet前务必确认：你的compareTo()是否严格满足“等价于 equals()”的合同（《Effective Java》第 12 条）
排序本身不难，难的是理清“排序”“去重”“名次计算”三件事的边界。多数线上 bug 出在把这三者混在一起做，比如在 Comparator 里偷偷改字段、或用 HashSet 接收排序结果——这些地方不报错，但结果会悄悄偏移。
