Collections.sort()配合自定义Comparator是最直接方式；需处理空值、越界及类型转换，如数值排序须将String转Integer/Double，升序用a.compareTo(b)，降序用b.compareTo(a)或reverseOrder()。
用 Collections.sort() 配合自定义 Comparator 是最直接的方式
Java 本身不支持对 List<list>></list> 直接按子列表某索引位置排序，必须显式写比较逻辑。核心是传一个能取到子列表指定下标元素、并处理空/越界/类型转换的 Comparator。
常见错误现象：IndexOutOfBoundsException（子列表长度不一）、NullPointerException（某子列表为 null）、ClassCastException（想按数字排但元素是 String）。
- 先确保所有子列表非
null，且目标索引存在 —— 否则在compare()里加判空和长度检查 - 如果按数值排序，注意
String类型的数字需转成Integer或Double再比，别直接用String.compareTo() - 升序用
a.compareTo(b)，降序反过来写b.compareTo(a)，或调用Comparator.reverseOrder()
示例：按每个子列表第 1 个元素（Integer）升序排：
Collections.sort(list2d, (a, b) -> {
if (a == null || b == null || a.size() <= 1 || b.size() <= 1) return 0;
return Integer.compare(a.get(1), b.get(1));
});
子列表元素类型不确定时，优先用 Comparable 接口而非强转
硬写 (Integer) a.get(0) 很危险 —— 一旦有 String 就抛异常。更稳的做法是依赖元素自身是否实现 Comparable，并统一用 compareTo()。
立即学习“Java免费学习笔记（深入）”；
使用场景：数据来源不可控（比如从 CSV 解析、JSON 转换而来），子列表混合了 String、Integer、Double。
- 用
instanceof分支判断类型再比，但代码膨胀；更简洁的是先统一转成String比（适合纯展示排序） - 如果必须数值语义，建议前置清洗：把所有可转数字的字符串转成
Double，其余设为Double.NaN，再用Double.compare() - 注意
Double.NaN和任何数比较都返回0，要单独处理（比如排最后）
Java 8+ 推荐用 Comparator.comparing() 链式写法，但要注意 null 安全
comparing() 看起来简洁，但默认不处理 null 或索引越界。直接写 comparing(l -> l.get(0)) 在运行时大概率崩。
性能影响：链式调用本身无额外开销，但每次 get(0) 都是方法调用，和手写 lambda 差异不大；真正影响性能的是反复取值 + 类型转换。
- 用
comparing()必须配合thenComparing()或nullsLast()等修饰器 - 安全写法示例（按第 0 位升序，
null或越界排最后）：
Collections.sort(list2d, Comparator
.comparing((List<?> l) -> l.size() > 0 ? l.get(0) : null,
Comparator.nullsLast(Comparator.naturalOrder())));
二维 List 排序后原地修改，别误以为返回新列表
Collections.sort() 是 in-place 操作，不返回新列表 —— 这点和 Python 的 sorted() 或 JavaScript 的 slice().sort() 完全不同。直接赋值会得到 void，编译报错。
容易踩的坑：写成 list2d = Collections.sort(...)（语法错），或以为排序后原列表没变而漏掉调试输出。
- 如果需要保留原顺序，排序前先
new ArrayList(original)浅拷贝 - 子列表本身是引用，排序只改变外层顺序，子列表内部元素不会被复制或修改
- 多线程环境下，排序期间不能并发修改该二维 List，否则可能抛
ConcurrentModificationException
复杂点在于：子列表长度不一致是常态，不是 bug；类型混杂是现实，不是设计缺陷；而 Java 的泛型擦除会让这些隐患拖到运行时才暴露。动手前先看一眼数据样本，比猛写 Comparator 更省时间。
