本文详解链表遍历中“边删边遍历”导致漏删的根本原因，提供逆向遍历与单次正向遍历两种解决方案，并分析时间复杂度差异，帮助开发者写出健壮、高效的链表过滤逻辑。
本文详解链表遍历中“边删边遍历”导致漏删的根本原因，提供逆向遍历与单次正向遍历两种解决方案，并分析时间复杂度差异，帮助开发者写出健壮、高效的链表过滤逻辑。
在使用 LinkedList（尤其是基于索引操作的实现）进行条件删除时，一个经典陷阱是：正向遍历时直接调用 remove(i) 会改变后续元素的索引位置，而循环变量 i 却照常递增，从而跳过紧邻的下一个元素。这正是你代码中仍残留 34 的根本原因。
以输入 [23, 45, 12, 34, 34, 66, 25, 13, 12, 24, 33] 为例：
- 当 i = 1 时，list.get(1) == 45 > 25 → 删除索引 1（值 45），列表变为 [23, 12, 34, 34, 66, 25, 13, 12, 24, 33]；
- 循环继续，i 变为 2，此时 list.get(2) 是 原第四个元素 34（而非被删掉的 45 后面那个 34），于是第二个 34（原索引 3）被跳过；
- 同理，连续多个大于 25 的值会成对漏删。
✅ 方案一：逆向遍历（简单修正，推荐用于快速验证）
从末尾向前遍历，删除操作不影响尚未访问的前面元素的索引：
for (int i = list.size() - 1; i >= 0; i--) {
if ((int) list.get(i) > 25) {
list.remove(i);
}
}✅ 优点：改动最小，逻辑直观，能正确删除所有目标节点。
⚠️ 注意：get(i) 在 LinkedList 中是 O(n) 操作（需从头遍历），外层循环 O(n)，总时间复杂度为 O(n²) —— 对大数据量不友好。
✅ 方案二：单次正向遍历 + 迭代器式逻辑（高效生产方案）
若 LinkedList 提供了 Iterator 或可获取内部节点（如自定义链表），应优先采用一次遍历。但即使仅用 List 接口，也可通过“手动维护当前索引+条件性不递增”模拟：
int i = 0;
while (i < list.size()) {
if ((int) list.get(i) > 25) {
list.remove(i); // 删除后，原 i+1 元素落到 i 位置，故不增加 i
} else {
i++; // 仅当未删除时才移动索引
}
}✅ 优势：避免重复 get() 开销，逻辑清晰，时间复杂度优化至 O(n)（虽仍有 remove(i) 的链表移位成本，但已是最小必要开销）。
? 进阶提示：若使用 Java 原生 java.util.LinkedList，更推荐其 Iterator.remove() 方法（支持安全并发修改）：
Iterator<Integer> it = list.iterator();
while (it.hasNext()) {
if (it.next() > 25) {
it.remove(); // 安全删除，无索引偏移问题
}
}? 总结与最佳实践
- ❌ 避免在正向 for 循环中调用 remove(i) 并无条件 i++；
- ✅ 优先选择逆向遍历（简单场景）或 Iterator.remove()（标准库推荐）；
- ? 若需极致性能且链表较大，考虑改用 ArrayList（随机访问快，但删除仍需移动）或构建新链表（空间换时间）；
- ? 测试务必覆盖边界：空链表、全满足/全不满足、连续满足值、首尾满足等用例。
正确删除不是“多删几次”，而是理解数据结构动态变化的本质——每一次 remove 都在重写后续地图，而你的指针必须随之校准。
