for循环中直接remove()必然漏删，因迭代器按索引推进而remove导致元素左移，使下一索引指向原位置后元素；反向遍历或while pop才是安全的原地删除方式。
直接在 for x in lst 循环中调用 lst.remove(x) 一定会漏删，这不是偶发 bug，而是迭代器机制与列表可变性冲突的必然结果。
for 循环底层是按索引推进，不是“看当前值”
Python 的 for x in lst 实际等价于用 iter(lst) 创建一个迭代器，后者内部维护一个整数索引（从 0 开始），每次调用 next() 就取 lst[i] 并把 i 加 1。它不扫描列表、不重新查找、不感知变化。
当你执行 lst.remove(x) 时：
- 列表长度减 1，所有索引 ≥ 删除位置的元素左移一位
- 但迭代器仍按原计划走到下一个索引（比如从 i=2 → i=3）
- 原来在 i=3 的那个元素，现在到了 i=2，而迭代器已经跳过了它
例如 nums = [2, 2, 2]：
第一次循环取 nums[0] == 2，remove(2) 后变成 [2, 2]；
迭代器接着取 nums[1]（原 nums[2]），跳过了新移到 nums[0] 的那个 2。
立即学习“Python免费学习笔记（深入）”；
remove 和 del 在循环里都危险，但报错方式不同
remove() 按值删第一个匹配项，del lst[i] 按索引删——两者都会导致后续元素前移，从而破坏迭代器预期的索引序列。
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
区别在于错误表现：
-
lst.remove(x)找不到目标值时抛ValueError: list.remove(x): x not in list -
del lst[i]对无效索引（比如删完后还继续用原长度遍历）抛IndexError: list index out of range - 哪怕没报错，只要列表在变，就一定存在漏删风险
为什么 nums[:] 看似安全，但有隐藏代价
for x in nums[:]: nums.remove(x) 能“绕过”问题，因为 nums[:] 是浅拷贝，迭代器在副本上走，原列表怎么删都不影响索引推进。
但它不是真正安全的原地方案：
- 内存开销：对千万级列表，
nums[:]可能触发 OOM - 语义偏差：你本意可能是“边处理边清理”，但实际是“先全量复制再删原列表”，逻辑和资源模型已不同
- 如果删除逻辑依赖其他变量或状态（比如需根据上一个删掉的值决定下一个删谁），副本遍历会丢失这种时序耦合
真正可控的原地删除只有反向遍历或 while pop
要避免副本、不浪费内存、且行为可预测，只能放弃正向索引推进的惯性思维：
- 反向遍历：
for i in range(len(nums)-1, -1, -1): if nums[i] == val: del nums[i]—— 删后面不影响前面索引 - while + pop：
while nums: x = nums.pop(); if x != val: ...或while val in nums: nums.remove(val)—— 前者适合需逐个消费场景，后者适合小列表（in和remove都是 O(n)，总复杂度 O(n²)） - 绝对不要混用：
for i, x in enumerate(nums): if x == val: del nums[i]——enumerate的索引也基于当前列表状态，删完它照常递增，照样跳项
最常被忽略的一点：这个陷阱不依赖数据内容，只依赖“遍历时修改”这一动作本身。哪怕你测试时碰巧删干净了，换一组相邻重复值或不同长度，立刻暴露。别依赖侥幸。
