Python字典items()与直接遍历键的性能差异分析

在 Python 日常开发中，遍历字典是最基础的操作之一。当循环体内同时需要访问键与值时，开发者常常在两种写法之间抉择：是通过 for k, v in d.items(): 一次性解包获取，还是通过 for k in d: v = d[k] 先遍历键再二次寻值？核心结论非常明确：在同时需要键和值的场景下，dict.items() 相比直接遍历键再查值具有明显的性能优势，运行耗时通常低 15% 至 30%；但若循环内仅需使用键，直接遍历字典 for k in d 则是最高效的选择。本文将基于 CPython 底层内存组织与字节码实现，深入分析这一性能差异的来源与适用边界。

一、核心对比：两种遍历语法的执行路径

理解性能差异的第一步是观察两种写法在解释器层面的执行路径。表面上看，for k, v in d.items() 多了一次元组打包与解包的步骤，而 for k in d: v = d[k] 结构极为简单。然而，二者在底层产生的操作类型完全不同。

直接遍历键并在循环体内执行 d[k]，每次迭代都会触发一次字典下标操作（BINARY_SUBSCR）。在 CPython 中，字典属于哈希表，每次下标查值都必须经历：计算键的哈希值、查阅哈希索引数组、处理潜在冲突、验证键对象一致性，最终取出目标值指针。即使哈希表查找的平均时间复杂度为 O(1)，这类查表开销依然是一组相对厚重的 C 语言函数调用。

反之，d.items() 返回一个字典视图对象（dict_items）。其迭代器直接对底层紧凑存储的字典条目数组进行线性步进扫描，每到达一个有效槽位，就同时取出键和值的指针包装为二元组返回。这完全省去了循环内部所有基于哈希的键值二次寻址过程。

图 1：直接遍历键与 items() 遍历的底层执行步骤拆解

二、底层实现机制：CPython 紧凑字典与字节码差异

自 Python 3.6 起，CPython 引入了紧凑字典（Compact Dict，基于 PEP 468 的理念）。现代字典内部被划分为两个核心部分：一个是稀疏哈希索引表（indices），另一个是紧凑连续的实体数组（entries）。

每个 entry 是一个包含了三个指针的结构体：me_hash（缓存的哈希值）、me_key（键对象指针）以及 me_value（值对象指针）。当执行 items() 迭代时，dictiter_items 本质上就是在 entries 数组中按连续内存逐项自增索引偏移。由于当前槽位中 me_key 与 me_value 已经紧密相邻存放，解释器无需再做任何哈希运算，即可直接取得这两者的指针。

为了探究指令开销，我们通过 Python 内置的 dis 模块对比两种模式的字节码：

import dis

def loop_keys(d):
    for k in d:
        v = d[k]

def loop_items(d):
    for k, v in d.items():
        pass

使用 dis.dis(loop_keys) 查看直接键遍历的循环内部指令：

# loop_keys 循环体核心指令：
FOR_ITER            16 (to 24)
STORE_FAST           1 (k)
LOAD_FAST            0 (d)
LOAD_FAST            1 (k)
BINARY_SUBSCR               # 触发字典哈希查询与值加载
STORE_FAST           2 (v)

而 dis.dis(loop_items) 的内部指令结构如下：

# loop_items 循环体核心指令：
FOR_ITER            14 (to 20)
UNPACK_SEQUENCE      2      # 将迭代器产出的二元组快速拆解至栈顶
STORE_FAST           1 (k)
STORE_FAST           2 (v)

对比可以发现，loop_items 避免了 LOAD_FAST(d)、LOAD_FAST(k) 以及关键的 BINARY_SUBSCR。在 CPython 的微架构中，UNPACK_SEQUENCE 2 是直接从 C 数组拷贝两个指针至虚拟机调用栈，这一指令的处理速度远快于进入 BINARY_SUBSCR 后调用 dict_subscript 进而展开哈希搜索的成本。

图 2：CPython 紧凑字典内部结构与两种迭代方式的数据检索路径

三、实测基准验证与耗时对比

为了定量评估性能差距，我们使用 Python 标准库中的 timeit 模块在标准 CPython 环境下进行对照测试。测试构建了不同规模的字典（从 100 元素至 100,000 元素），并在一致的环境下分别衡量三种典型行为的单次遍历平均耗时：

1. 同时访问键和值：对比 d.items() 与 for k in d: _ = d[k]；
2. 仅访问键：对比直接 for k in d 与 for k, _ in d.items()；
3. 仅访问值：对比 d.values() 与 for k in d: _ = d[k]。

import timeit

setup_code = "d = {f'k_{i}': i for i in range(10000)}"

# 测试 1：同时使用键和值
t_items = timeit.timeit("for k, v in d.items(): pass", setup=setup_code, number=1000)
t_keys_lookup = timeit.timeit("for k in d: v = d[k]", setup=setup_code, number=1000)

# 测试 2：仅使用键
t_keys_only = timeit.timeit("for k in d: pass", setup=setup_code, number=1000)

# 测试 3：仅使用值
t_values_only = timeit.timeit("for v in d.values(): pass", setup=setup_code, number=1000)

print(f"items() 同时获取: {t_items:.4f}s")
print(f"直接遍历键并查值: {t_keys_lookup:.4f}s")
print(f"仅遍历键 keys:   {t_keys_only:.4f}s")
print(f"仅遍历值 values: {t_values_only:.4f}s")

在 10,000 键值对的典型测试中（循环 1,000 次），所得的相对耗时表现如下表所示：

图 3：三种典型业务场景下的遍历模式耗时比例对比

四、临时元组开销与垃圾回收影响

部分开发者曾有顾虑：d.items() 每次迭代都要产生一个二元组 (k, v)，如果在数百万规模的大字典上运行，是否会造成严重的内存开销与垃圾回收（GC）负担？

事实上，CPython 在底层做过高度专项优化。在 CPython 的对象管理机制中，对于长度较小的元组（特别是长度为 1 到 20 的元组），内部维护了一个专门的高速空闲链表（tuple_freelist）。当循环体完成 UNPACK_SEQUENCE 2 之后，该临时二元组的引用计数随即降为 0，解释器不会调用系统的 free() 归还内存，而是直接将其放回本地空闲槽位供下一次迭代复用。

相反，由于 d[k] 会多次经历哈希查找，如果键是复杂的字符串或自定义对象，其计算或比较还会间接造成 CPU 缓存命中率下降（Cache Miss）。从综合硬件利用效率来看，顺序访问密集数组的 items() 反而具备更高的硬件友好度。

五、工程实践与选型决策指南

在实际工程代码中，除了性能之外，代码的意图清晰度与可维护性同样关键。基于上述机理与实测结论，建议在编写 Python 字典循环时遵循以下决策准则：

图 4：按需匹配遍历写法的选型与排雷总结

总结

“直接遍历键再查值”看似简单，实质上是在每一轮迭代中引入了冗余的哈希计算与寻址开销。通过 for k, v in d.items(): 遍历不仅语法更加地道，更能在底层充分利用 CPython 紧凑条目表的连续内存特性与元组缓冲池，取得更低耗时与更高的执行稳定性。