Java中set()修改List指定位置元素需确保index∈[0, list.size())，仅原地替换不扩容/不移动元素；越界抛IndexOutOfBoundsException是为防止逻辑错误，非静默失败。
Java中用set()修改List指定位置元素的正确姿势
直接调用list.set(index, element)即可，但前提是index必须在[0, list.size())范围内。它不扩容、不插入、不移动其他元素，就是原地替换——这是和add(int, E)最本质的区别。
常见错误现象：IndexOutOfBoundsException，尤其在循环里动态修改List又没同步更新索引时高频出现。
-
set()只适用于ArrayList、LinkedList等支持随机访问或已知节点位置的实现；CopyOnWriteArrayList也支持，但注意写操作会复制整个数组 - 对
LinkedList调用set()，时间复杂度是O(n)（需从头/尾遍历到目标位置），不是O(1) - 如果只是想“更新最后一个元素”，别硬算
list.size() - 1，先判空：if (!list.isEmpty()) list.set(list.size() - 1, newVal);
为什么set()会抛IndexOutOfBoundsException而不是静默失败
因为Java集合的设计契约明确要求：所有基于索引的操作都必须校验边界。这不是“防护过度”，而是防止掩盖逻辑错误——比如误把size()当成了最大合法索引（实际最大是size()-1）。
典型翻车场景：遍历List同时用set()改值，但循环变量i超出了当前List长度（比如List被其他线程截断，或你刚remove()过元素却忘了调整i）。
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
for (int i = 0; i → <code>i == list.size()时必崩 - 安全写法：
for (int i = 0; i - 更稳妥的惯用法：用增强for配合
list.indexOf()不推荐——indexOf()可能返回-1或找错对象；直接用传统for+下标最可控
替代set()的几种情况：什么时候不该用它
如果你发现总在set()前要反复检查索引是否存在、或者List长度频繁变动，大概率是设计偏了——set()不是万能更新接口。
- 想按条件更新某元素？用
list.indexOf(target)再判断是否≥0，但注意：仅适用于元素可准确equals()匹配且无重复；否则应遍历+标记下标 - 想更新“第N个满足条件的元素”？别硬套
set()，先用stream().filter().skip().findFirst()定位，再通过list.indexOf()或记录原始索引去设值 - 需要原子性更新（比如“如果旧值是A，才设成B”）？
set()做不到，考虑AtomicReferenceArray或自己加锁，或换用ConcurrentMap存索引→值映射
容易被忽略的兼容性细节：泛型擦除与null值
set()允许传入null（只要泛型声明允许），但擦除后实际调用的是Object引用赋值——这本身没问题，但后续取值时若没判空，NullPointerException可能出现在完全不同的地方，调试时容易误判。
- 例如：
List<string> list = new ArrayList(); list.add("a"); list.set(0, null); String s = list.get(0).trim();</string>→ 崩在trim()，不是set() - 如果List声明为
List extends Number>，则set()参数只能是null（通配符上限导致无法确定具体子类型） - Android低版本（API null处理不一致，建议在关键路径上显式防御：
if (newValue != null || list.get(index) != null) list.set(index, newValue);
边界检查永远发生在运行时，编译器不会帮你拦住越界调用；而null的语义是否合法，得靠你自己在业务层定义清楚——set()只管执行，不管意图。
