当前位置：首页 > news >正文

Pandas多维聚合实战：从风控到看板的生产级分析模式

news 2026/7/14 1:22:17

1. 项目概述：为什么多维聚合不是“高级技巧”，而是日常分析的呼吸本身

你有没有过这种经历：凌晨两点，报表系统告警，风控模型突然飘红，业务方在群里@你问“上个月南区高净值客户交易额同比跌了12%，到底哪个环节出问题了？”——你手忙脚乱打开Jupyter，先groupby('region')，再groupby('customer_tier')，又groupby('product_category')，最后拼接merge，跑完发现结果对不上，再查时间范围、再验数据清洗逻辑……一小时过去，咖啡凉透，问题还没定位。

这不是你的能力问题。这是你还在用“单维度呼吸”应对“多维空气”的典型症状。

我做银行数据分析和建模落地整整11年，从最早用SQL写嵌套子查询硬扛多层分组，到后来在Spark里调优窗口函数内存溢出，再到如今带团队设计实时特征管道——我踩过的最深的坑，90%都源于对pandas多维聚合的理解停留在“会用agg()”这个层面，而没把它当成一套可组合、可复用、可审计的分析语言来掌握。

这篇内容讲的不是“Part 20”这个编号，而是你每天真实面对的7类核心业务场景：

风控团队要算“每个商户类别下，近30天交易金额的标准差 / 均值”，识别异常波动；
运营团队要对比“新客首单 vs 老客复购”的平均客单价、中位数、订单频次，且必须按城市+渠道交叉切片；
财务系统要生成月度损益表，其中“手续费收入”需按产品线滚动计算7日均值，“坏账准备金”则需按客户等级做累计求和；
管理层看板要呈现“各区域主力产品销售额矩阵”，但原始数据是长表（region, product, date, revenue），而老板只认Excel里的行列交叉表。

这些需求，用基础groupby()写三遍代码、merge两次、再reset_index()，不仅慢，而且极易出错——比如忘记处理NaN导致sum()结果失真，或rolling()后索引错位让时间序列对不齐。而真正的生产级做法，是把聚合本身当作“第一等公民”来设计：一次分组，多重计算；一次定义，全域复用；一次输出，直通下游。

关键词里提到的“Towards AI”，其实恰恰点出了本质：这不是教你怎么写代码，而是帮你建立一种面向业务问题的数据思维范式。它不依赖特定平台（你用Databricks还是本地Pandas，语法几乎一致），也不绑定某类数据（交易流水、IoT传感器、用户行为日志，逻辑完全相通）。接下来我会带你一层层拆解，不是照搬示例，而是告诉你每一步背后的“为什么必须这样”，以及我在银行真实上线的6个避坑细节——比如那个让整个风控模型延迟2小时的rolling窗口索引陷阱，至今我还记得运维同事拍桌子的声音。

2. 核心设计思路：为什么这五种模式构成生产环境的“聚合铁三角”

很多初学者看到“多维聚合”就想到“groupby多个字段”，这就像学开车只练挂挡，却不懂离合与油门的配合逻辑。真正的生产级聚合设计，核心在于三个不可分割的维度协同：维度结构（What to group by）、计算逻辑（How to aggregate）、结果形态（How to present）。下面这五种模式，正是这三者在不同业务压力下的最优解耦合。

2.1 多列多函数聚合：不是语法糖，而是性能与可维护性的生死线

先看一个血泪案例：某城商行的反洗钱系统，需要每日输出《重点客户交易特征日报》，包含37个指标：

客户维度：近7日交易笔数、最大单笔、最小单笔、中位数、标准差；
产品维度：各产品线交易金额占比、手续费率均值；
时间维度：当日vs上周同日环比、近30日滚动均值。

如果按新手写法，你会写37个独立的groupby语句，然后pd.concat()拼起来。实测结果：单日数据量200万行时，耗时48秒，且每次新增指标都要改三处代码（groupby、agg、列名映射）。

而生产级写法，是把聚合逻辑本身变成“声明式配置”：

# 生产环境真实配置（已脱敏） AGG_CONFIG = { 'transaction_amount': ['count', 'min', 'max', 'median', 'std'], 'fee_amount': ['sum', lambda x: (x/x.sum()).mean() if len(x)>0 else 0], 'product_code': [lambda x: x.nunique(), lambda x: x.value_counts(normalize=True).iloc[0] if len(x)>0 else 0] } result = df.groupby(['customer_id', 'date']).agg(AGG_CONFIG)

为什么这能提速3倍？
pandas底层对字典形式的agg做了深度优化：它会一次性扫描原始数据，对每个分组同时计算所有函数，避免重复遍历。而37个独立groupby，等于让CPU扫37遍数据。更关键的是，当业务方说“再加个‘近3日交易金额变异系数’”，你只需在配置里加一行'transaction_amount': lambda x: x.std()/x.mean() if x.mean()!=0 else 0，无需动任何主逻辑。

提示：注意lambda函数里必须处理空值！我见过太多人因为没加if len(x)>0判断，在某个客户某天无交易时，整个agg报错中断。生产环境永远假设“数据有缺失”。

2.2 自定义聚合函数：业务逻辑的“可执行文档”

标准函数如mean()、sum()解决的是数学问题，而custom function解决的是商业契约问题。比如银行要求：“对公客户单笔超500万交易，手续费按阶梯计费：0-500万收0.05%，500-1000万收0.03%，超1000万收0.01%”。这根本没法用内置函数表达。

此时，named function不是“为了用而用”，而是把业务规则固化为可测试、可审计的代码资产：

def corporate_fee_calc(series): """ 【业务规则】对公客户手续费阶梯计算（依据2024版《中间业务收费管理办法》第3.2条） - 0~500万：0.05% - 500~1000万：0.03%（仅超出500万部分） - >1000万：0.01%（仅超出1000万部分） """ total = series.sum() if total <= 5_000_000: return total * 0.0005 elif total <= 10_000_000: return 5_000_000 * 0.0005 + (total - 5_000_000) * 0.0003 else: return (5_000_000 * 0.0005 + 5_000_000 * 0.0003 + (total - 10_000_000) * 0.0001) # 使用时直接传入函数名，无需括号 result = df.groupby('customer_id').agg({'transaction_amount': corporate_fee_calc})

实操心得：

函数名必须体现业务含义（corporate_fee_calc而非calc_fee），否则半年后连你自己都看不懂；
docstring里必须注明规则出处（如“第3.2条”），这是审计时的关键证据；
所有边界值（500万、1000万）必须用5_000_000这种带下划线的写法，避免5000000这种易读错的数字。

2.3 滚动窗口聚合：时间敏感型分析的“动态标尺”

滚动窗口（rolling）的本质，是把“静态快照”升级为“动态参照系”。比如风控场景：“单日交易金额超过近7日均值2个标准差，触发预警”。这里“近7日均值”不是固定值，而是随日期滑动的——今天看1-7日，明天看2-8日。

但新手常犯致命错误：直接对groupby后的结果做rolling()。看这个反例：

# ❌ 错误示范：先groupby再rolling，丢失时间顺序！ df_grouped = df.groupby(['customer_id', 'date'])['amount'].sum() df_grouped.rolling(7).mean() # 此时索引是(customer_id, date)，rolling会跨客户计算！

正确姿势必须是：先确保时间序列有序，再按业务键分组，最后在组内做rolling：

# ✅ 正确流程（银行生产环境标准写法） df_sorted = df.sort_values(['customer_id', 'date']).set_index('date') # 关键：用groupby().rolling()，不是rolling().groupby() result = df_sorted.groupby('customer_id')['amount'].rolling('7D').mean() # '7D'比window=7更鲁棒

为什么用'7D'而不是window=7？

window=7是按行数滚动，若某客户某天无交易，7行可能跨越10天，导致参照系失真；
'7D'是按时间跨度滚动，自动处理缺失日期，结果更符合业务直觉（“最近7天”而非“最近7笔”）；
我们在某股份制银行上线时，因用window=7导致节假日后首日预警率飙升300%，根源就是跨度过大。

2.4 扩展窗口聚合：累积计算的“确定性保障”

扩展窗口（expanding）常被误解为“只是cumsum()的别名”，但它真正的价值在于提供可复现的累积状态。比如监管报送要求：“截至报告日，客户本年度累计交易金额”。这个“本年度”必须严格按自然年，不能因数据加载顺序不同而变化。

错误写法：

# ❌ 危险！依赖原始数据顺序，结果不可复现 df['cumsum'] = df.groupby('customer_id')['amount'].cumsum()

正确写法（强制按时间排序）：

# ✅ 生产环境黄金法则：expanding前必sort df_sorted = df.sort_values(['customer_id', 'date']) result = df_sorted.groupby('customer_id')['amount'].expanding().sum() # 若需自然年累计，加条件：.expanding(min_periods=1).apply(lambda x: x[x.index.year==x.index[0].year].sum())

经验注入：

expanding()默认从第一个非空值开始，但监管场景常要求“从年初第一天起算”，此时要用min_periods=1并配合时间过滤；
所有expanding结果必须.reset_index()，否则下游系统（如Tableau）无法识别索引。

2.5 多级分组+unstack：让业务方一眼看懂的“翻译器”

技术人常抱怨“业务方看不懂代码”，其实问题不在他们，而在我们没把结果翻译成他们的语言。unstack()就是这个翻译器——它把程序员眼中的“MultiIndex Series”（如('North','Widget') -> 15500.0），转成业务方脑中的“表格”（行=North，列=Widget，值=15500.0）。

但直接unstack()有陷阱。看这个真实案例：某零售银行做“区域×产品×季度”分析，代码如下：

# ❌ 导致列名混乱的写法 result = df.groupby(['region','product','quarter'])['revenue'].sum().unstack() # 输出列名变成：('Widget', 'Q1'), ('Widget', 'Q2')... 业务方拒绝接收

生产级解决方案：

# ✅ 三步法：先聚合，再unstack指定层级，最后重命名列 result = (df.groupby(['region','product','quarter'])['revenue'] .sum() .unstack(level='quarter') # 明确指定把quarter层转为列 .rename(columns={1:'Q1', 2:'Q2', 3:'Q3', 4:'Q4'})) # 业务友好列名

注意：unstack(level=...)中的level参数必须是字符串（列名）或整数（层级序号），不能是变量。我曾因写unstack(level=quarter)导致线上脚本崩溃，因为quarter是Series而非字符串。

3. 实操全流程：从原始交易流水到高管决策看板的7步炼金术

现在，我们把前面所有原理，放进一个真实的银行信用卡分析场景里，走一遍端到端流程。这不是玩具数据，而是我2023年为某全国性银行重构的《客户价值分层模型》生产代码精简版。所有步骤均可直接复制运行（需安装pandas>=1.5）。

3.1 数据准备：模拟真实复杂度的交易流水

真实银行数据绝不是干净CSV。它有：

时间戳精度到毫秒（需截断到日）；
交易金额含手续费（需分离）；
客户ID存在空值（需标记）；
商户类别有层级（如“Dining”下分“FastFood”、“FineDining”）。

import pandas as pd import numpy as np from datetime import datetime, timedelta # 设置随机种子保证可重现 np.random.seed(42) # 构建高仿真数据（10万行，覆盖3个月） dates = pd.date_range('2024-01-01', '2024-03-31', freq='D') customers = [f'C{str(i).zfill(3)}' for i in range(1, 501)] categories = ['Groceries', 'Dining', 'Travel', 'Retail', 'Utilities', 'Healthcare'] # 模拟交易量分布（周末+月末高峰） base_volume = np.ones(len(dates)) base_volume[dates.weekday >= 5] *= 1.8 # 周末提升80% base_volume[dates.day >= 25] *= 1.5 # 月末提升50% data = [] for date in dates: # 每日交易笔数 = 基础量 × 随机波动 daily_count = int(base_volume[dates.get_loc(date)] * np.random.poisson(500)) for _ in range(daily_count): customer = np.random.choice(customers) category = np.random.choice(categories, p=[0.25, 0.2, 0.15, 0.2, 0.1, 0.1]) # 金额按类别设定均值（Dining更高） mean_amt = {'Groceries': 80, 'Dining': 120, 'Travel': 450, 'Retail': 200, 'Utilities': 50, 'Healthcare': 180}[category] amount = max(10, np.random.normal(mean_amt, mean_amt*0.3)) # 加入合理波动 fee = round(amount * 0.025, 2) # 固定费率2.5% data.append({ 'transaction_id': f'TX{datetime.now().strftime("%Y%m%d%H%M%S")}{np.random.randint(1000,9999)}', 'customer_id': customer, 'category': category, 'amount': round(amount, 2), 'fee': fee, 'timestamp': date + pd.Timedelta(minutes=np.random.randint(0, 1440)), 'merchant_id': f'M{np.random.randint(10000,99999)}' }) df_raw = pd.DataFrame(data) print(f"原始数据量：{len(df_raw):,} 行") print("数据质量初检：") print(f"- 客户ID空值率：{df_raw['customer_id'].isnull().mean():.2%}") print(f"- 交易金额负值：{len(df_raw[df_raw['amount']<0])} 行") print(f"- 时间范围：{df_raw['timestamp'].min()} 至 {df_raw['timestamp'].max()}")

关键细节说明：

pd.Timedelta(minutes=...)模拟一天内随机交易时间，避免所有交易集中在00:00；
max(10, ...)确保金额不低于10元，符合真实业务约束；
transaction_id用时间戳+随机数，避免重复——这是生产环境必备意识。

3.2 清洗与特征工程：为聚合铺平道路

聚合不是万能胶，它放大会放大数据质量问题。这一步耗时占整个分析的40%，但决定结果可信度。

# 步骤1：时间处理（银行核心要求：所有时间按交易日，非系统日） df = df_raw.copy() df['date'] = df['timestamp'].dt.date # 截断到日 df['month'] = df['timestamp'].dt.to_period('M') # 用于后续月度聚合 # 步骤2：客户ID空值处理（真实场景：约0.3%交易无客户ID） df['customer_id_clean'] = df['customer_id'].fillna('UNKNOWN') # 步骤3：金额校验（剔除明显异常值） # 使用IQR法：Q1-1.5*IQR ~ Q3+1.5*IQR 为合理区间 q1 = df['amount'].quantile(0.25) q3 = df['amount'].quantile(0.75) iqr = q3 - q1 lower_bound = q1 - 1.5 * iqr upper_bound = q3 + 1.5 * iqr df = df[(df['amount'] >= lower_bound) & (df['amount'] <= upper_bound)] print(f"清洗后数据量：{len(df):,} 行（剔除{len(df_raw)-len(df):,}行异常）") # 步骤4：构造衍生特征（业务强相关） df['is_weekend'] = df['timestamp'].dt.weekday >= 5 df['is_month_end'] = df['timestamp'].dt.day >= 25 df['amount_tier'] = pd.cut(df['amount'], bins=[0, 100, 500, 1000, float('inf')], labels=['Small', 'Medium', 'Large', 'XLarge'])

实操心得：

dt.to_period('M')比dt.strftime('%Y-%m')更高效，且支持PeriodIndex运算；
IQR法比固定阈值（如>10000）更鲁棒，能自适应不同商户类别的金额分布；
pd.cut()生成的category类型，比字符串比较快3倍以上，适合高频分组。

3.3 分析1：多维统计聚合（客户×商户类别×月份）

这是风控日报的核心。要求：每个客户在每个商户类别、每个月的交易笔数、金额均值、中位数、手续费率。

# 定义聚合配置（生产环境直接读取JSON配置文件） agg_config = { 'transaction_id': 'count', # 笔数 'amount': ['mean', 'median', 'sum'], # 金额统计 'fee': lambda x: (x.sum() / x.sum().sum()) * 100 if x.sum().sum() > 0 else 0, # 手续费率 'is_weekend': 'mean' # 周末交易占比 } # 关键：按业务键分组，注意month是Period类型，需转为字符串便于下游使用 result_1 = (df.groupby(['customer_id_clean', 'category', 'month']) .agg(agg_config) .round(2)) # 重命名列以明确业务含义 result_1.columns = ['transaction_count', 'amount_mean', 'amount_median', 'amount_sum', 'fee_rate_pct', 'weekend_ratio'] result_1 = result_1.reset_index() print("分析1结果预览（前5行）：") print(result_1.head())

为什么不用agg({'amount': ['mean','median']})？
因为['mean','median']会生成MultiIndex列（amount → mean），而下游BI工具常不支持。显式命名列名，是生产环境的黄金准则。

3.4 分析2：自定义风险指标（交易波动率）

风控核心指标：transaction_volatility = std(amount) / mean(amount)。但需处理分母为0。

def calc_volatility(series): """计算交易金额波动率（标准差/均值），规避除零错误""" if len(series) < 2: return 0.0 mean_val = series.mean() if abs(mean_val) < 1e-6: # 防止浮点精度导致的除零 return 0.0 return series.std() / mean_val # 应用自定义函数（注意：必须用apply，不能用agg，因agg不支持返回标量外的类型） result_2 = (df.groupby(['customer_id_clean', 'category']) .apply(lambda x: pd.Series({ 'volatility': calc_volatility(x['amount']), 'high_value_ratio': (x['amount'] > 500).mean(), 'avg_fee_per_txn': x['fee'].sum() / x['transaction_id'].count() if x['transaction_id'].count() > 0 else 0 })) .round(4)) print("\n分析2：客户-商户类别波动率（前5行）：") print(result_2.head())

避坑技巧：

apply()返回pd.Series，比字典更稳定；
abs(mean_val) < 1e-6比mean_val == 0更安全，因浮点计算存在精度误差。

3.5 分析3：滚动窗口分析（客户级7日消费趋势）

这是运营活动效果评估的关键。要求：每个客户每日的7日滚动平均交易额。

# 步骤1：确保时间顺序（绝对必要！） df_sorted = df.sort_values(['customer_id_clean', 'date']).set_index('date') # 步骤2：按客户分组，对金额做7日滚动均值 # 使用'7D'而非7，确保跨日历日（非交易日） rolling_result = (df_sorted.groupby('customer_id_clean')['amount'] .rolling('7D', min_periods=1) # min_periods=1：首日即计算，不返回NaN .mean() .reset_index(name='rolling_7d_avg')) # 步骤3：合并回原始数据，便于关联其他特征 df_with_rolling = df_sorted.reset_index().merge( rolling_result, on=['customer_id_clean', 'date'], how='left' ) print("\n分析3：滚动7日均值（前10行）：") print(df_with_rolling[['customer_id_clean', 'date', 'amount', 'rolling_7d_avg']].head(10))

为什么min_periods=1是风控生命线？
某次上线后，因默认min_periods=7，导致新客户前6天所有指标为NaN，风控模型误判为“零交易客户”，批量冻结了200+账户。紧急修复后，我们强制所有rolling操作显式声明min_periods。

3.6 分析4：扩展窗口分析（客户生命周期价值）

财务部门需要“截至当前日期，客户历史累计交易额”，用于LTV预测。

# 按客户+日期排序后，做扩展窗口求和 df_sorted = df.sort_values(['customer_id_clean', 'date']) expanding_result = (df_sorted.groupby('customer_id_clean')['amount'] .expanding(min_periods=1) # 同样，min_periods=1 .sum() .reset_index(name='cumulative_spend')) # 关键：expanding()返回的索引是两层（customer_id, group_key），需重置 expanding_result['date'] = expanding_result['level_1'] expanding_result = expanding_result.drop('level_1', axis=1) print("\n分析4：客户累计消费（前10行）：") print(expanding_result.head(10))

经验教训：

expanding()后必须reset_index()，否则level_1列名会让下游ETL脚本崩溃；
累计值必须保留原始日期，不能只存最终值——业务方常要查“某客户在3月15日的累计额”。

3.7 分析5：多级透视与高管看板生成

最后一步，把技术结果翻译成业务语言。要求：生成“区域×产品”矩阵，供CEO晨会使用。

# 假设我们有区域映射表（真实场景从CRM系统同步） region_map = { 'C001': 'North', 'C002': 'North', 'C003': 'South', 'C004': 'South', # ... 实际有500个客户 } df['region'] = df['customer_id_clean'].map(region_map).fillna('Other') # 构建透视表（这才是unstack的正确打开方式） pivot_data = (df.groupby(['region', 'category'])['amount'] .agg(['sum', 'count', 'mean']) .round(2)) # 展开为宽表，指定将category层转为列 pivot_wide = pivot_data.unstack(level='category') # 重命名列，使其业务友好 pivot_wide.columns = [f"{stat}_{cat}" for stat, cat in pivot_wide.columns] pivot_wide = pivot_wide.reset_index() # 添加计算列：各区域总交易额占比 total_all = pivot_wide['sum_Groceries'].sum() + pivot_wide['sum_Dining'].sum() + \ pivot_wide['sum_Travel'].sum() + pivot_wide['sum_Retail'].sum() pivot_wide['region_share_pct'] = ((pivot_wide['sum_Groceries'] + pivot_wide['sum_Dining'] + pivot_wide['sum_Travel'] + pivot_wide['sum_Retail']) / total_all * 100).round(1) print("\n分析5：高管看板数据（区域×产品矩阵）：") print(pivot_wide)

终极技巧：

unstack(level='category')比unstack()更安全，避免因MultiIndex层级变化导致崩溃；
列名用f"{stat}_{cat}"格式，确保BI工具能自动识别维度（如Tableau可据此生成分层筛选器）；
所有计算列（如region_share_pct）必须放在最后，且明确标注计算逻辑，方便审计。

4. 常见问题与排查技巧实录：那些让我彻夜难眠的12个坑

以下全是我在银行、保险、互金公司真实踩过的坑，按发生频率排序。每个问题都附带根因分析+一键修复命令+预防机制。

4.1 问题1：rolling()结果全为NaN，但数据明明有值

现象：df.groupby('id')['val'].rolling(7).mean()返回全NaN。
根因：数据未按时间排序！rolling()在groupby后，对每个分组内部按原始数据顺序滚动，而非时间顺序。
修复：

# ✅ 强制排序后再rolling df_sorted = df.sort_values(['id', 'date']) result = df_sorted.groupby('id')['val'].rolling('7D').mean()

预防：在代码头部加检查：

assert df.sort_values(['id','date']).equals(df), "数据未按时间排序！"

4.2 问题2：unstack()后列名变成元组，下游系统报错

现象：result.columns显示[('sum', 'Groceries'), ('sum', 'Dining')]，Excel导入失败。
根因：agg()生成了MultiIndex列，unstack()未指定level。
修复：

# ✅ 方法1：unstack时指定level result = df.groupby(['a','b'])['c'].sum().unstack(level=1) # ✅ 方法2：重命名列（推荐） result.columns = [f"{col[0]}_{col[1]}" for col in result.columns]

4.3 问题3：自定义函数在agg()中报错“cannot convert to Series”

现象：df.groupby('x').agg({'y': my_func})报错。
根因：my_func返回了list或numpy array，而agg()要求返回标量。
修复：

def my_func(series): # ❌ 错误：return [series.mean(), series.std()] # ✅ 正确：返回标量，或用apply() return series.mean() # 或用apply()返回Series

4.4 问题4：expanding()结果索引混乱，无法merge

现象：df.groupby('id')['val'].expanding().sum()返回的索引是MultiIndex，merge时报错。
根因：expanding()保留了原始groupby的双层索引。
修复：

# ✅ 必须reset_index并指定drop=False result = (df.groupby('id')['val'] .expanding().sum() .reset_index(level=0, drop=False) # 保留id索引 .reset_index(drop=True)) # 重置行索引

4.5 问题5：多列agg时，部分列结果为空

现象：agg({'a':'sum', 'b':'mean'})中，'b'列全NaN。
根因：'b'列在某些分组中全为NaN，mean()返回NaN。
修复：

# ✅ 使用skipna=False强制计算，或预处理 df['b'] = df['b'].fillna(0) # 根据业务逻辑填充 # 或用agg时指定skipna result = df.groupby('x').agg({'b': lambda x: x.mean(skipna=True)})

4.6 问题6：内存爆炸，10GB数据OOM

现象：df.groupby(['a','b','c']).agg(...)吃光内存。
根因：分组键组合过多（如百万级客户+千级产品），生成中间结果过大。
修复：

# ✅ 分步聚合：先粗粒度，再细粒度 step1 = df.groupby(['a','b'])['val'].sum().reset_index() step2 = step1.groupby(['a'])['val'].mean() # 再聚合 # ✅ 或用chunking（适用于超大数据） for chunk in pd.read_csv('big_file.csv', chunksize=10000): process(chunk)

4.7 问题7：时间窗口计算结果与SQL不一致

现象：pandas rolling结果 vs Hive SQLover(order by date rows between 6 preceding and current row)不同。
根因：pandas默认按行数，SQL按时间。
修复：

# ✅ pandas用时间窗口，SQL用行窗口，保持一致 result = df.groupby('id').apply( lambda x: x.sort_values('date').assign( rolling_sum=x.sort_values('date')['val'].rolling('7D').sum() ) )

4.8 问题8：agg()后列顺序与预期不符

现象：agg({'a':'sum', 'b':'mean'})输出列顺序是b,a。
根因：Python字典在3.6+保持插入顺序，但agg()内部可能重排。
修复：

# ✅ 显式指定列顺序 result = result[['a_sum', 'b_mean']] # 重排列 # ✅ 或用OrderedDict（兼容老版本） from collections import OrderedDict agg_dict = OrderedDict([('a','sum'), ('b','mean')])

4.9 问题9：自定义函数中使用全局变量，结果不可复现

现象：df.groupby('x').agg({'y': lambda x: x.mean() + GLOBAL_OFFSET})，GLOBAL_OFFSET被意外修改。
根因：全局变量状态污染。
修复：

# ✅ 将参数封装进函数闭包 def make_offset_func(offset): return lambda x: x.mean() + offset result = df.groupby('x').agg({'y': make_offset_func(10)})

4.10 问题10：unstack()后出现重复列名

现象：unstack()报错ValueError: Index contains duplicate entries。
根因：分组键组合不唯一，如['a','b']中有重复(1,'X')。
修复：

# ✅ 先检查并去重 dupes = df.groupby(['a','b']).size() print("重复分组：", dupes[dupes>1]) # ✅ 或用agg强制聚合 result = df.groupby(['a','b'])['val'].first().unstack()

4.11 问题11：rolling()在groupby后计算跨组

现象：df.groupby('id')['val'].rolling(3).mean()中，id=1的最后1行和id=2的前2行被错误计算。
根因：未重置索引，rolling跨组连续计算。
修复：

# ✅ 关键：rolling前必须重置索引，确保每个组内索引连续 result = (df.groupby('id') .apply(lambda x: x.sort_values('date').reset_index(drop=True)) .groupby('id')['val'] .rolling(3).mean())