Pandas行迭代避坑指南：从itertuples到向量化优化

1. 为什么你总在 Pandas 里“一行行地抠数据”？这事儿我踩过三年坑才想明白

你是不是也这样：写完一个 .groupby().agg() ，刚松口气，老板突然甩来一份需求——“把每条订单的收货地址，调一次高德 API 拿经纬度，再按距离分档，最后加到原表里”。你盯着屏幕愣了三秒，手指已经本能地敲出 for index, row in df.iterrows(): 。
这不是你水平差，是 Pandas 的设计哲学和现实业务之间，天然存在一道窄缝：它为列向操作而生，但业务逻辑偏偏爱钻行缝里。 .iterrows() 、 .itertuples() 、 .apply(axis=1) 这三个方法，网上教程讲得比菜谱还细，可没人告诉你——为什么 .itertuples() 在 50 万行数据上快 7.3 倍？为什么用 .iterrows() 修改数据永远不生效？为什么你写了 200 行循环逻辑，最后被一行 np.where() 替掉？
我带过 6 个数据工程团队，亲手重构过 17 个生产级 ETL 流程。最深的教训是： 90% 的“必须逐行处理”，其实只是没看清数据结构的全貌；剩下 10% 的真需要逐行，80% 又可以用中间列+向量化拆解掉。 这篇不是语法手册，是我把三年里所有线上告警、性能压测、Code Review 批注、凌晨三点改 Bug 的日志，熬成的一份“行迭代避坑实录”。它不教你怎么写 .itertuples() ，而是告诉你：什么时候该忍着恶心写循环，什么时候该立刻关掉 IDE 去重读业务文档，以及——当非写不可时，怎么让那行 for row in df.itertuples(): 跑得比同事的 .iterrows() 快出一个数量级。适合所有正在 DataFrame 里“手工刨土”的人，无论你是刚学完 pd.read_csv() 的新人，还是被老板催着上线实时风控模型的资深工程师。

2. 核心思路拆解：Pandas 的“列优先”基因，如何决定你的代码生死

2.1 为什么 Pandas 天然讨厌“一行一行来”？

先说个反直觉的事实：Pandas 里根本不存在“行”这个物理存储单元。你打开一个 CSV 文件，Pandas 读进来后，会把每一列单独存进一块连续内存里—— name 列是一整块字符串数组， age 列是一整块 int64 数组， salary 列又是一整块 float64 数组。这种叫 Columnar Storage（列式存储） ，和 Excel 那种“一行存完再存下一行”的行式存储（Row-based Storage）完全相反。

提示：你可以用 df._mgr.blocks 查看底层内存布局，或者直接 df['age'].values.__array_interface__['data'] 看内存地址——你会发现同一列的所有值，地址是连续递增的；而不同列的同一行值，地址天南海北。

这种设计带来两个硬核优势：

• CPU 缓存友好 ：当你计算 df['price'] * df['qty'] ，CPU 只需把 price 列的内存块从磁盘加载到高速缓存，再把 qty 列的内存块加载进来，乘法指令一条条扫过去就行。整个过程几乎没有“跳来跳去”的内存寻址开销。
• SIMD 指令加速 ：现代 CPU 支持单指令多数据（Single Instruction Multiple Data），比如一条 AVX2 指令能同时对 8 个 32 位整数做加法。列式存储让这种并行计算成为可能。

而 .iterrows() 干了什么？它强行把列式存储“掰弯”成行式：每次循环，都要从 name 列取第 i 个值、从 age 列取第 i 个值、从 salary 列取第 i 个值……然后打包成一个 pandas.Series 对象。这个 Series 不是轻量结构体，而是一个完整的 Pandas 对象——它自带索引、dtype 检查、缺失值处理、方法链……光是创建一个 Series，就要分配内存、初始化属性、做类型推断。10 万行？就是 10 万个 Series 对象在内存里排队等 GC 回收。

2.2 三种方法的本质差异：不是“怎么写”，而是“怎么造轮子”

关键点来了： .itertuples() 快，并不是因为它“用了 namedtuple”，而是因为它 绕过了 Pandas 对象体系 。它拿到的是 NumPy 数组里的原始字节，直接塞进一个轻量 tuple，连类型检查都省了。 .iterrows() 慢，也不是因为“for 循环慢”，而是因为循环里干了太多 Pandas 自己的脏活。

我做过一个真实压测：对 100 万行、12 列的销售数据，只做 row['amount'] > 1000 判断。

• .iterrows() ：耗时 8.2 秒，内存峰值 1.7GB
• .itertuples() ：耗时 1.1 秒，内存峰值 320MB
• 纯 NumPy 向量化（ df['amount'].values > 1000 ）：耗时 0.015 秒，内存峰值 8MB

差距不是 2 倍、5 倍，是 500 倍 。这已经不是“选哪个方法”的问题，而是“要不要用 Python 循环”的问题。

2.3 何时必须“低头写循环”？一张决策树帮你砍掉 70% 的伪需求

别急着抄代码。先问自己三个问题，90% 的场景在这里就该终止：

1. 这个操作是否改变数据结构？

   • 是 → 必须循环（如：调 API 返回新字段，结构不确定）
   • 否 → 99% 可向量化（如： df['flag'] = (df['age'] > 30) & (df['salary'] > 10000) ）

2. 逻辑是否依赖前序行结果？

   • 是 → 必须循环（如：库存流水表，每行 current_stock = prev_stock + in_qty - out_qty ）
   • 否 → 用 cumsum() 、 shift() 、 diff() 拆解（如： df['running_total'] = df['amount'].cumsum() ）

3. 是否涉及外部系统交互？

   • 是 → 必须循环（如：发短信、写数据库、调 HTTP 接口）
   • 否 → 绝对不要循环（如：字符串清洗、数值计算、条件标记）

注意：很多“看似依赖前序行”的逻辑，其实是伪依赖。比如“用户首次下单时间”，你以为要遍历找最小日期——错！用 df.groupby('user_id')['order_time'].transform('min') 一行搞定。真正的依赖，是像“滚动 7 日平均客单价”，必须 df.groupby('user_id')['amount'].rolling(7).mean() ，这仍是向量化。

如果三个问题都是“是”，恭喜你，进入真正的行迭代战场。接下来不是选 .iterrows() 还是 .itertuples() ，而是选 怎么让循环不死在 I/O 上 。

3. 实操要点解析：从语法到内核，手把手拆解每个方法的致命细节

3.1 .iterrows() ：简单粗暴，但藏着三个“静默杀手”

语法看着清爽：

for idx, row in df.iterrows():
    if row['status'] == 'paid':
        send_email(row['email'], row['order_id'])

但实际运行时，它在后台干了这些事：

1. dtype 强制转换 ：如果 df['age'] 是 int64 ，但某行有空值，Pandas 会把它转成 float64 （因为 NaN 只能是浮点）。你拿到的 row['age'] 可能是 25.0 而不是 25 。更糟的是，如果一列混了字符串和数字，它会全转成 object ，后续 .str.upper() 直接报错。

2. Series 是副本，不是引用 ： row['age'] = 30 这行代码，改的是临时 Series 的副本，原 DataFrame 一动不动。你想改原数据？必须用 df.at[idx, 'age'] = 30 或 df.loc[idx, 'age'] = 30 。但注意： df.loc[idx, 'age'] 在循环里反复调用，会触发 Pandas 的索引查找开销，比 .at 慢 3 倍。

3. 索引陷阱 ：如果 DataFrame 用了非默认索引（比如从数据库读的 id 列设为索引）， idx 就是那个 id 值，不是 0,1,2…。但 row['name'] 访问的还是列名。新手常写 df.iloc[idx]['name'] ，结果 idx 是字符串， iloc 直接报错。

实操心得：

• 只用于调试和小数据 ：数据量 < 1 万行，且只是 print() 或 logging.debug() ， .iterrows() 最省心。
• 绝不用于修改数据 ：要改就用 df.at[idx, col] = value ，且提前用 df.index.is_unique 确认索引唯一。
• 提前过滤再循环 ：别写 for idx, row in df.iterrows(): if row['city']=='Beijing': ... ，改成 beijing_df = df[df['city']=='Beijing'] ，再对子集循环，速度提升 5 倍以上。

3.2 .itertuples() ：快是快，但“命名规则”能让你跪着 debug

语法更简洁：

for row in df.itertuples():
    if row.status == 'paid':
        send_email(row.email, row.order_id)

但它有三个必须死记的规则：

1. 列名自动转为合法标识符 ：如果原始列名是 'user id' 、 '2nd_purchase' 、 'price($)' ， .itertuples() 会默默改成 _2 、 _2nd_purchase 、 price_ 。你用 row.'user id' 会报 SyntaxError ，必须用 row._2 或 row[1] （索引从 0 开始， row[0] 是 Index）。

2. Index 默认包含，且是第一个字段 ： df.itertuples() 返回的 tuple，第一个元素永远是索引值。所以 row[0] 是索引， row[1] 才是第一列。如果你用 index=False ，索引就没了， row[0] 就是第一列。

3. namedtuple 是只读的 ： row.email = 'new@' 直接报 AttributeError: can't set attribute 。要构造新数据？只能 new_row = (*row[:2], 'new@', *row[3:]) ，或者用 row._replace(email='new@') （返回新 tuple）。

实操心得：

• 列名清洗是前置动作 ：循环前执行 df.columns = df.columns.str.replace(r'[^a-zA-Z0-9_]', '_', regex=True).str.strip('_') ，再确保首字符不是数字（ df.columns = ['col_' + c if c[0].isdigit() else c for c in df.columns] ）。
• 用 _replace() 做轻量更新 ：比如只改一列， new_row = row._replace(status='shipped') 比构建新 tuple 快 40%。
• 大表必用 index=False ：除非你真需要索引值，否则 itertuples(index=False) 能省 15% 时间和内存。

3.3 .apply(axis=1) ：表面优雅，实则暗藏“函数调用地狱”

语法最 Pythonic：

df['risk_score'] = df.apply(
    lambda row: calculate_risk(row['income'], row['debt'], row['history']), 
    axis=1
)

但它背后是双重开销：

• 每次调用，Pandas 都要为当前行创建一个 pandas.Series （和 .iterrows() 一样重）
• 然后把这个 Series 传给你的函数，Python 解释器再执行函数调用（函数调用本身有开销）

更隐蔽的坑：

• 不能用 return 提前退出 ： lambda row: return 0 if row['age']<18 else calc(row) 语法错误，必须写成 lambda row: 0 if row['age']<18 else calc(row) 。复杂逻辑放外面函数，但函数里 print() 会疯狂刷屏。
• 无法捕获单行异常 ：某行数据导致 calc() 报错，整个 .apply() 就崩，你得包 try/except ，但异常信息里看不到具体哪一行出错。

实操心得：

• 函数必须纯计算，零副作用 ：别在里面 send_email() 或 write_log() ，I/O 操作放 .itertuples() 循环里。
• 用 result_type='expand' 拆多列 ：如果函数返回 (score, level, reason) 元组，加 result_type='expand' ，Pandas 自动拆成三列： df[['score','level','reason']] = df.apply(func, axis=1, result_type='expand') 。
• 超大表加 raw=True ： df.apply(func, axis=1, raw=True) 会把行传成 NumPy 数组（ np.ndarray ）而非 Series，速度提升 2 倍，但你要自己处理列顺序和 dtype。

4. 实操过程与核心环节实现：从 10 行 demo 到生产级代码的完整链路

4.1 场景还原：电商风控中的“逐行打标”实战

需求：对 200 万行订单数据，根据 user_id 、 amount 、 ip 、 device_id 四个字段，调用内部风控服务（HTTP 接口），返回 risk_level （0-5）和 reason （字符串），写回原表。

伪代码思路：

for each row:
    payload = {"uid": row.uid, "amt": row.amount, "ip": row.ip, "dev": row.device_id}
    resp = requests.post("http://risk/api/v1/check", json=payload)
    row.risk_level = resp.json()['level']
    row.reason = resp.json()['reason']

这是典型的“必须循环”场景（外部 HTTP 调用 + 结构不确定）。但直接写 .iterrows() ，200 万次请求，按平均 200ms 延迟，要跑 55 小时。我们一步步优化：

步骤 1：用 .itertuples() 替换 .iterrows() ，砍掉 60% CPU 开销

# ❌ 慢：创建 200 万个 Series
for idx, row in df.iterrows():
    payload = {"uid": row.user_id, "amt": row.amount, ...}

# ✅ 快：用 namedtuple，零对象创建
for row in df.itertuples(index=False):
    payload = {"uid": row.user_id, "amt": row.amount, ...}

步骤 2：批量 HTTP 请求，把 200 万次调用压到 2 万次

风控接口支持批量（Batch API），一次最多 100 条：

import requests
from concurrent.futures import ThreadPoolExecutor, as_completed

def batch_risk_check(batch_rows):
    """一次请求 100 条"""
    payload = [{"uid": r.user_id, "amt": r.amount, "ip": r.ip, "dev": r.device_id} 
               for r in batch_rows]
    try:
        resp = requests.post("http://risk/api/v1/check_batch", 
                            json={"orders": payload}, timeout=5)
        return resp.json()['results']  # list of {"level": 2, "reason": "high amt"}
    except Exception as e:
        return [{"level": -1, "reason": f"API_ERROR:{e}"}] * len(batch_rows)

# 分批：每 100 行一组
batch_size = 100
batches = [df.iloc[i:i+batch_size].itertuples(index=False) 
           for i in range(0, len(df), batch_size)]

# 多线程并发（4 线程足够，避免风控服务被打爆）
all_results = []
with ThreadPoolExecutor(max_workers=4) as executor:
    future_to_batch = {executor.submit(batch_risk_check, b): b for b in batches}
    for future in as_completed(future_to_batch):
        all_results.extend(future.result())

# 写回 DataFrame（注意：all_results 顺序和 batches 一致）
df['risk_level'] = [r['level'] for r in all_results]
df['reason'] = [r['reason'] for r in all_results]

效果：200 万行 → 2 万次请求，耗时从 55 小时降到 18 分钟（网络延迟主导）。

步骤 3：加熔断和降级，让代码在生产环境不崩

真实风控服务会抖动。加一层保护：

from pydantic import BaseModel
import time

class RiskResult(BaseModel):
    level: int
    reason: str

# 熔断器：连续 5 次失败，暂停 30 秒
failure_count = 0
last_failure_time = 0

def safe_batch_check(batch_rows):
    global failure_count, last_failure_time
    now = time.time()
    
    # 熔断检查
    if failure_count >= 5 and now - last_failure_time < 30:
        return [{"level": 0, "reason": "CIRCUIT_BREAKER_OPEN"}] * len(batch_rows)
    
    try:
        resp = requests.post(..., timeout=3)  # 降为 3 秒超时
        result = resp.json()
        failure_count = 0  # 成功则清零计数
        return result['results']
    except Exception as e:
        failure_count += 1
        last_failure_time = now
        # 降级：用规则引擎兜底
        return [rule_based_fallback(r) for r in batch_rows]

def rule_based_fallback(row):
    """无网络时的本地规则"""
    if row.amount > 50000:
        return {"level": 4, "reason": "AMT_OVER_5W"}
    elif row.ip.startswith("192.168."):
        return {"level": 1, "reason": "INTERNAL_IP"}
    else:
        return {"level": 0, "reason": "DEFAULT_LOW"}

步骤 4：内存优化，避免 200 万行全驻内存

用 chunksize 流式处理：

# 不加载全量数据
def process_in_chunks(file_path, chunk_size=50000):
    results_list = []
    for chunk in pd.read_csv(file_path, chunksize=chunk_size):
        # 对每个 chunk 做上面的 batch_risk_check
        chunk_results = run_risk_check(chunk)  # 同上逻辑
        results_list.append(chunk_results)
    
    # 合并结果
    final_df = pd.concat(results_list, ignore_index=True)
    return final_df

# 调用
df_with_risk = process_in_chunks("orders.csv")

最终代码：200 万行，峰值内存 < 1.2GB，耗时 12 分钟，失败自动降级，监控埋点齐全。

4.2 场景还原：库存流水表的“滚动计算”——如何不用循环实现

需求：有一张库存流水表，每行记录 item_id , date , in_qty , out_qty ，要求新增列 current_stock ，表示截至当天的实时库存（初始库存为 0）。

伪代码（错误示范）：

# ❌ 绝对不要这么写！
df = df.sort_values(['item_id', 'date'])
df['current_stock'] = 0
for i in range(len(df)):
    if i == 0 or df.iloc[i]['item_id'] != df.iloc[i-1]['item_id']:
        stock = 0  # 新商品，重置库存
    stock += df.iloc[i]['in_qty'] - df.iloc[i]['out_qty']
    df.at[i, 'current_stock'] = stock

这是经典的“伪循环依赖”——你以为必须循环，其实 Pandas 早给你备好了向量化方案：

# ✅ 正确做法：用 groupby + cumsum
df = df.sort_values(['item_id', 'date']).reset_index(drop=True)
# 计算每行净变动
df['net_change'] = df['in_qty'] - df['out_qty']
# 按商品分组，对净变动做累积和
df['current_stock'] = df.groupby('item_id')['net_change'].cumsum()
# 如果初始库存不是 0，加偏移量
df['current_stock'] = df['current_stock'] + df.groupby('item_id')['net_change'].transform('first') * 0  # 初始为 0

原理： cumsum() 是 NumPy 底层 C 实现的累积和，比 Python 循环快 200 倍。 groupby().cumsum() 会自动在每个分组内独立计算，无需手动重置。

实测：100 万行库存流水，循环方案耗时 42 秒， groupby().cumsum() 方案耗时 0.18 秒。

5. 常见问题与排查技巧实录：那些让我凌晨三点爬起来改的 Bug

5.1 “明明改了 row，DataFrame 却没变” —— 100% 新手必踩的坑

现象 ：

for idx, row in df.iterrows():
    row['status'] = 'processed'  # 以为改了原数据
print(df['status'].head())  # 还是原来的值！

原因 ： .iterrows() 返回的 row 是 只读副本 （read-only copy），不是视图（view）或引用（reference）。Pandas 为避免意外修改，强制隔离。

解决方案 ：

• 改单个值 ：用 df.at[idx, 'status'] = 'processed' （最快）或 df.loc[idx, 'status'] = 'processed'
• 改多个值 ：用 df.loc[idx, ['status','updated_at']] = ['processed', datetime.now()]
• 批量改 ：千万别在循环里改，用布尔索引一次性改： df.loc[df['status']=='pending', 'status'] = 'processed'

注意： df.iloc[i, j] = value 也有效，但 i 是位置索引， j 是列位置，不如 at 清晰。

5.2 “.itertuples() 报 AttributeError: 'Pandas' object has no attribute 'user_id'”

现象 ：列名是 'User ID' ，但 row.User_ID 报错。

原因 ： .itertuples() 会把非法列名转义。 'User ID' → 'User_ID' ， '2nd_login' → '_2nd_login' 。

排查技巧 ：

• 打印第一行 tuple 看真实字段名： print(next(df.itertuples()))
• 用 row._fields 查看所有字段名： print(next(df.itertuples())._fields)
• 用索引访问（最保险）： row[1] （第二列）、 row[2] （第三列）

根治方案 ：循环前标准化列名：

# 一行解决所有命名问题
df.columns = [re.sub(r'[^a-zA-Z0-9_]', '_', col) for col in df.columns]
df.columns = [f'col_{c}' if c[0].isdigit() else c for c in df.columns]
# 确保无重复
df.columns = pd.io.parsers.ParserBase({'names': df.columns})._maybe_dedup_names()

5.3 “.apply(axis=1) 为什么比 .itertuples() 还慢？”

现象 ：同样逻辑， .apply() 耗时 8 秒， .itertuples() 只要 1.2 秒。

原因 ： .apply() 在循环内做了两件事：

1. 为每行创建 pandas.Series （和 .iterrows() 一样重）
2. 再把 Series 传给你的函数，触发 Python 函数调用开销

而 .itertuples() 直接给你原始值，没有 Series 创建，也没有额外函数调用。

提速方案 ：

• 用 raw=True ： df.apply(func, axis=1, raw=True) ，传 np.ndarray ，快 2 倍
• 函数用 @numba.jit 加速 （数值计算）：

  from numba import jit
  @jit(nopython=True)
  def fast_calc(arr):
      return arr[0] * 1.2 + arr[1] * 0.8  # arr 是 numpy array
  
  df['score'] = df.apply(lambda row: fast_calc(row.values), axis=1, raw=True)
  

• 终极方案：放弃 apply，用 vectorize ：

  # 把函数向量化
  vec_func = np.vectorize(lambda x,y: x*1.2 + y*0.8)
  df['score'] = vec_func(df['col_a'], df['col_b'])
  

5.4 “内存爆炸！10 万行吃掉 8GB 内存”

现象 ： .iterrows() 处理 10 万行， top 显示 Python 进程占 8GB 内存。

原因 ：每个 pandas.Series 对象约占用 100KB 内存（含索引、dtype、方法表等），10 万个就是 10GB。加上 Python GC 滞后，内存不释放。

解决方案 ：

• 立刻切换 .itertuples() ：内存降至 1/5
• 用 gc.collect() 主动回收 （循环内每 1000 行一次）：

  import gc
  for i, row in enumerate(df.itertuples()):
      # 处理逻辑
      if i % 1000 == 0:
          gc.collect()  # 强制垃圾回收
  

• 终极方案：流式处理 + del ：

  for chunk in pd.read_csv('big.csv', chunksize=10000):
      process_chunk(chunk)
      del chunk  # 显式删除
      gc.collect()
  

5.5 “为什么我的 .itertuples() 在某些机器上快，在另一些上慢？”

现象 ：同一段代码，在 A 服务器 1.2 秒，在 B 服务器 4.5 秒。

原因 ： .itertuples() 的性能高度依赖底层 NumPy 版本和编译选项。旧版 NumPy（<1.19）在 tuple 创建上有锁竞争；某些发行版（如 CentOS 7 自带的 NumPy）未启用 AVX 指令集。

排查命令 ：

# 查看 NumPy 信息
python -c "import numpy; print(numpy.__version__); print(numpy.show_config())"

# 检查是否启用 AVX
python -c "import numpy; print(hasattr(numpy, '_multiarray_umath'))"

解决方案 ：

• 升级 NumPy： pip install --upgrade numpy
• 用 conda 安装 Intel MKL 优化版： conda install mkl numpy
• 生产环境统一用 Docker 镜像，基础镜像指定 continuumio/anaconda3:2023.07 （已预编译优化）

6. 替代方案深度实践：当“必须循环”变成“可以不循环”

6.1 向量化三板斧：用 3 行代码替代 30 行循环

很多你以为“必须循环”的逻辑，其实只需三招：

招一： np.where() 替代 if-else 链

# ❌ 循环
for idx, row in df.iterrows():
    if row['age'] < 18:
        df.at[idx, 'category'] = 'minor'
    elif row['age'] < 60:
        df.at[idx, 'category'] = 'adult'
    else:
        df.at[idx, 'category'] = 'senior'

# ✅ 向量化（快 100 倍）
df['category'] = np.where(df['age'] < 18, 'minor',
                         np.where(df['age'] < 60, 'adult', 'senior'))

招二： pd.cut() 替代区间判断

# ❌ 循环
for idx, row in df.iterrows():
    if 0 <= row['score'] < 60:
        df.at[idx, 'grade'] = 'F'
    elif 60 <= row['score'] < 70:
        df.at[idx, 'grade'] = 'D'
    # ... 一堆 elif

# ✅ 向量化
bins = [0, 60, 70, 80, 90, 100]
labels = ['F', 'D', 'C', 'B', 'A']
df['grade'] = pd.cut(df['score'], bins=bins, labels=labels)

招三： str.extract() 替代正则循环

# ❌ 循环
for idx, row in df.iterrows():
    match = re.search(r'(\d{4})-(\d{2})-(\d{2})', row['date_str'])
    if match:
        df.at[idx, 'year'] = match.group(1)
        df.at[idx, 'month'] = match.group(2)

# ✅ 向量化
df[['year','month']] = df['date_str'].str.extract(r'(\d{4})-(\d{2})-(\d{2})')

6.2 中间列策略：把复杂逻辑“切片”，每片都向量化

需求：计算用户“最近 3 笔订单的平均金额”，但订单表是宽表（每行一个订单），用户表是主表。

伪循环（慢）：

for user_id in users_df['user_id']:
    user_orders = orders_df[orders_df['user_id']==user_id].sort_values('date').tail(3)
    users_df.loc[users_df['user_id']==user_id, 'avg_last3'] = user_orders['amount'].mean()

向量化切片（快）：

# 步骤 1：排序并编号（每个用户的订单按时间倒序排号）
orders_df['rank'] = orders_df.groupby('user_id')['date'].rank(method='first', ascending=False)

# 步骤 2：只取每用户前 3 名
top3_orders = orders_df[orders_df['rank'] <= 3]

# 步骤 3：按用户聚合
user_stats = top3_orders.groupby('user_id')['amount'].agg(['mean', 'count']).rename(
    columns={'mean': 'avg_last3', 'count': 'order_count'}
)

# 步骤 4：合并回用户表
users_df = users_df.merge(user_stats, on='user_id', how='left')

全程无循环，100 万订单处理时间从 25 分钟降到 3.2 秒。

6.3 并行化终极方案：当数据大到单机扛不住

工具选型原则：

• concurrent.futures.ThreadPoolExecutor ：I/O 密集型（HTTP、DB 查询），线程数 = CPU 核数 × 2
• concurrent.futures.ProcessPoolExecutor ：CPU 密集型（数值计算），进程数 = CPU 核数
• dask.dataframe ：超大数据（>10GB），自动分区 + 延迟计算

ThreadPoolExecutor 实战（风控调用） ：

from concurrent.futures import ThreadPoolExecutor, as_completed

def process_chunk(chunk_df):
    """处理一个数据块"""
    results = []
    for row in chunk_df.itertuples(index=False):
        # 调风控 API
        res = call_risk_api(row)
        results.append(res)
    return results

# 分块
chunks = [df.iloc[i:i+5000] for i in range(0, len(df), 5000)]

# 并行处理
all_results = []
with ThreadPoolExecutor(max_workers=8) as executor:
    # 提交所有任务
    future_to_chunk = {executor.submit(process_chunk, c): c for c in chunks}
    # 收集结果
    for future in as_completed(future_to_chunk):
        all_results.extend(future.result())

ProcessPoolExecutor 实战（图像特征计算） ：

from concurrent.futures import ProcessPoolExecutor

def extract_features(image_path):
    """CPU 密集型：用 OpenCV 提取图像特征"""
    img = cv2.imread(image