Python 的 zip 为什么会悄悄少处理一条数据

把姓名与成绩配对时，很多人会自然地写出 zip(names, scores)。如果姓名有三项、成绩只有两项，程序并不会报错，而是只产生两组结果。对于表格展示，这可能只是少一行；如果用于生成账单、导入记录或更新库存，遗漏就很难被察觉。

默认行为：以最短的输入为准

names = ["小林", "小周", "小陈"]
scores = [90, 85]
print(list(zip(names, scores)))
# [('小林', 90), ('小周', 85)]

这不是 Python 丢失了列表中的元素，而是 zip 的约定：当任意一个输入迭代器结束时，就停止配对。它不会主动检查其他输入是否还有剩余数据。这种设计适合“只处理共同部分”的场景，但不能直接代表“数据已经完整对应”。

数据必须一一对应时，使用 strict=True

Python 3.10 起，zip 支持 strict=True。如果输入长度不一致，在迭代到差异处时会抛出 ValueError。

try:
    pairs = list(zip(names, scores, strict=True))
except ValueError:
    print("姓名和成绩数量不一致，请检查导入文件")

它也支持生成器，不需要先用 len() 检查。不过要记住：zip 是惰性的。仅仅创建 zip(..., strict=True) 对象，不会立即发现错误；必须实际迭代到长度不一致的位置。提前 break 也可能让检查没有机会发生。

strict 不会撤销已经执行的操作

下面这种写法仍然有风险：

for name, score in zip(names, scores, strict=True):
    save_to_database(name, score)

前两条记录可能已经保存，第三次迭代才报错。strict=True 负责发现长度不一致，不负责回滚文件、网络请求或数据库写入。

对于规模有限的输入，可以先完整生成配对，再执行保存：

def validated_pairs(names, scores):
    # 完整消费 zip，让长度检查发生在任何保存操作之前。
    return list(zip(names, scores, strict=True))

pairs = validated_pairs(names, scores)
for name, score in pairs:
    save_to_database(name, score)

如果列表很大，全部展开会增加内存占用。这时可根据数据来源选择数据库事务、带回滚的批量导入，或在可重复读取的数据源上先做完整校验。不要为了数一遍长度，先消费一个随后还要使用的单次生成器。

允许缺项时，要明确填充值

如果业务本来允许某一列缺项，可以使用标准库 itertools.zip_longest，以最长输入为准，并明确补位规则：

from itertools import zip_longest

missing = object()
for name, score in zip_longest(names, scores, fillvalue=missing):
    if name is missing or score is missing:
        print("存在缺项，需要人工检查")
    else:
        print(name, score)

使用独立哨兵对象，能区分“缺少这一项”和“原始数据本身就是 None”。

选择配对方式前，先写清数据约束：只需要共同部分，用普通 zip；必须完整对应，用 strict=True 并考虑副作用的边界；允许缺项，用 zip_longest 明确处理。一个参数无法替代业务校验，但能让原本安静发生的数据遗漏尽早变成可处理的错误。