将DataFrame转为字典后迭代：存在哪些弊端与风险？

有观点称将DataFrame转换为字典后再迭代，速度比直接用iterrows()快约20倍，但这种操作存在诸多需要规避的问题，以下是详细分析：

性能对比测试代码（修正原代码笔误后） #

import time
import numpy as np
import pandas as pd

df = pd.DataFrame(np.random.randint(0,100,size=(100000, 2)), columns=list('AB'))


st = time.time()
x=0
for i, row in df.iterrows():
   x+=(row.A)*(row.B)
print('Result', x, 'via df Iterrows,         Execution time:', time.time() - st, 'seconds')


st = time.time()
x=0
dico=df.to_dict('records')
for i in range(len(dico)):
   row_A, row_B = [dico[i][k] for k in ['A', 'B']]
   x+=(row_A)*(row_B)
print('Result', x, 'via browsing dict,      Execution time:', time.time() - st, 'seconds')

一、核心弊端与风险 #

1. 内存占用暴增 #

DataFrame基于numpy数组实现高效的连续内存存储，转成records格式的字典后，每一行都会变成独立的字典对象，每个字典额外携带哈希表结构开销。对于十万行以上的数据集，内存占用可能达到原DataFrame的3-5倍，直接触发内存不足报错。

2. 丢失Pandas原生功能特性 #

• 索引与便捷访问：iterrows()返回的行是带索引的Series对象，支持通过索引、列名快速访问，还能直接调用Series的向量运算方法（如row.sum()、row.mean()）；转成字典后只能通过键名取值，丢失了索引关联与Pandas内置方法支持。
• 数据类型一致性：DataFrame会严格维护列的统一数据类型（如int64、float64），转字典后数值类型会被转换为Python原生类型（如int、float），涉及高精度计算或类型敏感操作时，容易出现精度损失或类型错误。
• 前置操作效率低下：如果迭代前需要对数据做切片、过滤（如df[df['A']>50]），直接操作DataFrame的效率远高于先转字典再遍历过滤。

3. 代码可读性与可维护性下降 #

iterrows()是Pandas的惯用写法，熟悉框架的开发者能快速理解逻辑；转字典迭代需要手动处理键名、索引，代码冗余度高，后续修改列名时需同步修改字典键名，极易引发错误。

4. 隐藏的性能陷阱 #

测试场景仅为简单数值计算，若涉及行关联、动态数据修改等复杂操作，字典的哈希表访问开销会抵消迭代速度优势，甚至比iterrows()更慢。另外，to_dict('records')本身需要遍历全量DataFrame生成字典列表，小数据集下这一步的时间占比极高，会直接抹平迭代的速度收益。

5. 调试难度提升 #

iterrows()的行对象可直接打印完整的行数据、索引与类型信息；转成字典后，只能看到零散的键值对，定位问题时需要额外拼接上下文，调试效率大幅降低。

二、最优替代方案 #

Pandas的核心优势是向量运算，完全无需迭代即可完成高效计算。比如测试代码中的求和逻辑，可一行实现：

x = (df['A'] * df['B']).sum()

这种方法的速度是迭代方法的几十到上百倍，同时保留DataFrame的所有特性，内存占用最低。

内容的提问来源于stack exchange，提问作者Vincent