subList返回原List的实时视图而非副本，其add/remove会直接修改原列表结构并引发索引位移，遍历时修改易抛ConcurrentModificationException或IndexOutOfBoundsException。
subList 返回的是原 List 的实时视图，不是副本
调用 subList 得到的子列表和原 List 共享底层数据，任何对子列表的结构性修改（如 add、remove、clear）都会直接反映在原列表上，反之亦然。这不是拷贝，是委托式代理。
- 常见错误现象：
ConcurrentModificationException—— 在遍历原列表时调用subList().clear()，或在遍历子列表时修改原列表 - 使用场景：批量更新某段索引范围的数据（如分页缓存刷新）、临时隔离操作区间、避免创建新集合开销
- 性能影响：零拷贝，O(1) 时间创建；但所有操作仍走原
List实现（如ArrayList的set是 O(1)，remove是 O(n)）
对 subList 的 add/remove 会改变原列表长度和索引偏移
subList 不是“独立切片”，它的 add 或 remove 会真实插入/删除原列表中对应位置的元素，导致后续元素索引整体位移。这意味着你不能假设子列表的 size 不变，也不能安全地基于原始索引做二次操作。
- 示例：
list = [a,b,c,d]，sub = list.subList(1,3)→[b,c]；执行sub.add("x")后，list变成[a,b,x,c,d]，sub变成[b,x,c] - 容易踩的坑：在循环中对
subList调用remove时，没考虑它会收缩原列表，导致IndexOutOfBoundsException或漏删 - 替代方案：若需真正隔离修改，应显式构造新列表，如
new ArrayList(subList)
subList 的边界索引必须合法，且不可越界访问
subList(fromIndex, toIndex) 要求 0 ≤ fromIndex ≤ toIndex ≤ list.size()。哪怕 fromIndex == toIndex（空子列表）也合法；但一旦 toIndex > list.size() 或 fromIndex ，立刻抛 IndexOutOfBoundsException。
- 常见错误现象：分页计算末尾
toIndex = fromIndex + pageSize时未取Math.min(toIndex, list.size())，导致越界 - 兼容性注意：该行为在所有 JDK 版本中一致，但不同
List实现（如CopyOnWriteArrayList）对subList的支持程度不同 ——CopyOnWriteArrayList.subList返回的是快照，不反映后续写操作 - 安全写法：
list.subList(Math.min(i, list.size()), Math.min(j, list.size()))
迭代 subList 时禁止通过原列表修改结构
对 subList 使用增强 for 循环或 Iterator 遍历时，若同时用原列表的 remove、add 等方法改变其结构，会触发 ConcurrentModificationException —— 因为子列表的迭代器与原列表共享 modCount。
- 正确做法：只通过子列表自身的
Iterator.remove()删除，或改用普通 for 循环配合subList.set(i, x)更新值（非结构性修改） - 陷阱示例：
for (String s : subList) { originalList.remove(s); }→ 必崩 - 调试提示：异常堆栈里若出现
SubList.checkForComodification，基本可断定是跨视图并发修改
视图的本质是轻量代理，它省掉复制成本，但也把所有约束和风险都暴露出来。最常被忽略的一点是：subList 的生命周期依赖于原列表 —— 原列表被 GC 后，子列表可能失效；更隐蔽的是，某些框架（如 MyBatis、Jackson）在序列化时可能意外触发子列表的 size() 或 get(0)，而此时原列表已被清空或重置。
