多维聚合数据变形：从长表到宽表的底层原理与实战-拓冰建站

1. 这不是简单的“分组求和”——多维聚合中的数据变形到底在动什么骨头？

你打开一份销售报表，想看“华东地区、2023年Q3、手机品类、华为品牌”的销售额总和，系统秒出结果；但当你再加一列“同比上季度增长率”，或者想把“华东/华南/华北”三个大区横向并排、每个区再拆成“Q1-Q4”四列，最后按品牌堆叠显示——这时候界面卡顿、SQL报错、PivotTable崩溃、甚至Python的pivot_table()直接抛出ValueError: Index contains duplicate entries……别急着骂工具，问题不在代码，而在你还没真正摸清多维聚合中数据操纵（Data Manipulation）的底层契约。

这节标题里的“Part 20”不是随便编的序号，它意味着你已经走过了数据清洗、基础分组、单维度聚合、时间序列处理等至少19道关卡。现在站在多维聚合的悬崖边，你面对的不再是“对A列按B列分组后求C列平均值”这种线性操作，而是要同时驾驭至少三个正交维度（比如：地理维度×时间维度×产品维度），并在它们交叉形成的“立方体”（Cube）里，像外科医生一样精准切开、折叠、拉伸、旋转数据——而每一次变形，都在重写数据的拓扑结构与语义关系。

我带过6个从Excel转Python的数据分析团队，90%的人卡在这一步，不是因为不会写groupby(['region','quarter','category'])，而是根本没意识到：groupby只是聚合的触发器，真正决定结果形态的，是后续的.agg()、.pivot()、.stack()、.unstack()这一整套“空间操作符”。它们不处理数值，只处理“坐标轴”。就像你不能用锤子拧螺丝，也不能用pivot()去解决本该用melt()解开的宽表困局。本篇不讲语法手册，只带你亲手拆解一个真实电商后台的月度经营分析看板——从原始订单明细表出发，一步步推演如何把120万行、58列的扁平数据，变成管理层一眼能抓住“哪个区域在哪个季度被哪个竞品打穿了毛利”的三维热力矩阵。所有操作均基于pandas 2.2+与标准SQL逻辑，零外部依赖，可直接粘贴复现。

2. 多维聚合的本质：从“表格平面”跃迁到“数据立方体”的三重认知升级

2.1 维度不是字段，是坐标轴——为什么你写的GROUP BY永远少一层语义

新手常把“按地区、按月份、按品类分组”理解为SQL里GROUP BY region, month, category的简单罗列。这是致命误解。真正的多维聚合中，每个维度都是一个独立可索引、可切片、可钻取的坐标轴。我们以某快消品公司的真实数据结构为例：

order_id	region	city	quarter	month	category	brand	sales_amt	cost_amt
ORD-001	华东	上海	Q3	7	饮料	可口可乐	2450.00	1890.00
ORD-002	华南	深圳	Q3	7	饮料	百事可乐	1980.00	1520.00

表面看有6个分组字段，但region、quarter、category才是核心业务维度（Business Dimensions），而city和month是它们的下钻层级（Drill-down Levels）。city属于region的子集，month属于quarter的子集。这种层级关系构成维度的树状结构：

region ├── 华东 │ ├── 上海 │ ├── 杭州 │ └── 南京 ├── 华南 │ ├── 深圳 │ └── 广州 └── 华北 ├── 北京 └── 天津

提示：SQL中GROUP BY region, quarter, category生成的是“点”（Point），即每个唯一组合对应一个聚合值；而多维分析需要的是“超立方体”（Hypercube），它必须支持：① 沿任一维度切片（Slice，如固定region='华东'）；② 沿任一维度切块（Dice，如region in ('华东','华南') and quarter='Q3'）；③ 沿任一维度上卷（Roll-up，如把month上卷到quarter）；④ 沿任一维度下钻（Drill-down，如quarter='Q3'下钻到month in (7,8,9)）。这些操作无法靠单一GROUP BY完成，必须依赖专门的数据变形操作。

2.2 聚合函数不是终点，是新坐标的原点——agg()之后的数据形态革命

当你执行：

df.groupby(['region','quarter','category']).agg({ 'sales_amt': 'sum', 'cost_amt': 'sum', 'order_id': 'count' })

得到的结果是一个MultiIndex DataFrame，其索引是三层嵌套的：

region quarter category 华东 Q3 饮料 2450.00 零食 3120.50 华南 Q3 饮料 1980.00 ...

这个结构的关键在于：索引（Index）承载了维度信息，列（Columns）承载了度量（Measures）。此时你获得的不是一个“表格”，而是一个以维度为键、以度量为值的字典式立方体。它的形态天然支持OLAP操作——比如要查华东Q3所有品类的销售额，直接result.loc[('华东','Q3'), 'sales_amt']即可，无需再次过滤。

但问题来了：如果管理层要对比华东vs华南的Q3销售额趋势，你需要把region从索引“升维”到列，让两个地区并排显示。这就触发了第一个关键变形：unstack()。

unstack()的本质是：将指定层级的索引（Index Level）转换为列（Column）的层级。执行：

result.unstack('region')

输出变成：

sales_amt cost_amt order_id region 华东 华南 华东 华南 华东 华南 quarter category Q3 饮料 2450.00 1980.00 1890.00 1520.00 127 98 零食 3120.50 2845.30 2420.10 2190.70 156 142

注意观察列的变化：原来的单层列sales_amt变成了双层列sales_amt → 华东/华南。这就是列层级（Column Level）的创建，它让“地区”这个维度从“行方向”切换到了“列方向”，实现了跨区域的横向对比。而unstack()之所以能成功，前提是索引中必须存在该层级——这解释了为什么groupby后的MultiIndex是多维聚合不可跳过的前置步骤。

2.3 宽表与长表：不是格式偏好，是计算范式的分水岭

当你的分析需求从“静态报表”转向“动态指标计算”，宽表（Wide Format）和长表（Long Format）的选择就上升为架构级决策。我们以计算“各区域各季度毛利率”为例：

宽表方案：先unstack('region')得到华东/华南并列的宽表，再对每列sales_amt和cost_amt分别计算：
```
# 假设已unstack得到wide_df wide_df[('gross_margin', '华东')] = ( wide_df[('sales_amt', '华东')] - wide_df[('cost_amt', '华东')] ) / wide_df[('sales_amt', '华东')]
```
问题：代码冗余（每个区域重复一遍）、难以扩展（新增华北需改三处）、列名嵌套过深易出错。
长表方案：保持MultiIndex索引，用assign()或eval()进行向量化计算：
```
result = result.assign( gross_margin = lambda x: (x['sales_amt'] - x['cost_amt']) / x['sales_amt'] )
```
优势：一行代码搞定所有组合，新增维度自动兼容，内存占用更低（无重复列）。

实操心得：我在某零售SaaS项目中做过压测——100万行原始数据经groupby().agg()生成约12万行聚合结果。若强行unstack('region').unstack('quarter')生成宽表，内存峰值飙升至4.2GB；而保持长表形态，仅用2.1GB，且后续计算速度提升37%。结论：长表是计算的黄金形态，宽表仅用于最终呈现。记住这个铁律：agg()→long table→compute→unstack()for display。

3. 四大核心变形操作详解：从原理到避坑的全链路实操

3.1 unstack()：把维度“立起来”，但立错位置会断腿

unstack()是多维聚合中最常用也最易误用的操作。它的核心参数只有两个：level（指定要升维的索引层级）和fill_value（缺失值填充）。但实际使用中，90%的报错都源于对level的误判。

我们继续用前述数据。假设你执行：

# 错误示范：试图unstack不存在的层级 result.unstack('brand') # 报错！因为brand不在索引中，而在原始数据里

正确做法是：先确保目标维度在索引中。如果brand是分析维度，必须在groupby时包含它：

# 正确：brand进入索引 result_brand = df.groupby(['region','quarter','category','brand']).agg({ 'sales_amt': 'sum', 'cost_amt': 'sum' }) # 然后才能unstack result_by_brand = result_brand.unstack('brand')

更隐蔽的陷阱是level参数的数字索引。result.index.names返回['region','quarter','category']，那么：

unstack('region')等价于unstack(0)
unstack('quarter')等价于unstack(1)
unstack('category')等价于unstack(2)

但如果你后续又unstack('region')，索引变成['quarter','category']，此时unstack(0)就指向quarter而非region了。所以强烈建议永远用字符串名称而非数字索引，避免因中间操作改变索引顺序导致逻辑错乱。

另一个高频问题是缺失组合导致的NaN。比如华东Q3没有“百事可乐”销售记录，unstack('brand')后该单元格就是NaN。此时fill_value=0看似合理，但会掩盖真实业务问题——是数据没传过来？还是真的没卖？我的经验是：绝不盲目填0，先用result_brand.index.value_counts()检查各维度组合的覆盖度。在某母婴电商项目中，我们发现unstack('brand')后23%的单元格为NaN，深入排查发现是ERP系统未同步新品编码，及时推动IT修复，避免了用错误数据做决策。

3.2 stack()：把宽表“压回去”，但压太狠会丢失灵魂

如果说unstack()是“升维”，stack()就是“降维”。它把列层级（Column Level）压回索引，将宽表变回长表。典型场景：你用unstack()做了区域对比报表，现在要基于此计算“各区域毛利率环比”，就必须先stack()还原为长表，否则无法按region和quarter做时间差分。

执行：

# 假设wide_result是unstack('region')后的宽表 long_again = wide_result.stack('region').reset_index() # 得到：quarter, category, region, sales_amt, cost_amt...

注意stack()默认会把所有列层级都压入索引，但你可以指定level参数只压特定层级。比如宽表有两层列：('sales_amt','华东')、('sales_amt','华南')，执行stack(0)会把第一层'sales_amt'压入索引，得到('sales_amt','华东')作为新索引；而stack(1)则把第二层'华东'压入索引。

最大坑点：stack()后索引顺序混乱。原始unstack('region')后索引是[quarter, category]，stack('region')后变成[quarter, category, region]。但如果你之前还unstack('category')，索引顺序可能是[quarter, region, category]，stack()后顺序就更难预测。解决方案：stack后立即用sort_index()标准化，或用reset_index().set_index(['quarter','region','category'])显式重建索引。

我在某金融风控项目中踩过这个坑：stack()后未排序，导致groupby('region').diff()计算出的环比值全部错位。调试3小时才发现是索引顺序问题。从此我的stack()后必加一行：

long_data = wide_result.stack('region').sort_index()

3.3 pivot_table()：比groupby+unstack更智能的“一键建模”

pivot_table()常被当作groupby().unstack()的语法糖，但它其实是更高级的OLAP建模工具。它的核心优势在于内置了缺失值处理、多重聚合、边际汇总（Margins）三大能力。

看这个真实需求：“统计各区域各季度各品类销售额，并自动计算每行小计（区域内各季度合计）、每列小计（各区域Q3合计）、以及总计”。

用groupby+unstack要写：

base = df.groupby(['region','quarter','category'])['sales_amt'].sum() wide = base.unstack(['quarter','category'], fill_value=0) # 然后手动加sum(axis=1)和sum(axis=0)...

而pivot_table()一行搞定：

pd.pivot_table( df, values='sales_amt', index='region', columns=['quarter','category'], aggfunc='sum', fill_value=0, margins=True, # 自动加All行/列 margins_name='总计' )

输出直接包含：

行末总计列：每个区域所有季度品类的销售额总和
列末总计行：所有区域在Q3各品类的销售额总和
右下角总计：全局销售额

更强大的是aggfunc支持字典，可对不同列用不同聚合函数：

pd.pivot_table( df, values=['sales_amt','order_id'], index='region', columns='quarter', aggfunc={'sales_amt':'sum', 'order_id':'count'}, fill_value=0 )

但pivot_table()的硬伤是性能。当数据量超50万行，它比groupby().unstack()慢3-5倍。我的优化策略是：小数据（<10万行）用pivot_table()快速验证逻辑；大数据先groupby().agg()生成长表，再unstack()，最后用pd.concat()手动添加边际行。

3.4 melt()：专治“列名即维度”的顽疾，但熔错了会血崩

当你的数据是这种格式（典型的BI导出宽表）：

region	Q1_sales	Q1_cost	Q2_sales	Q2_cost	Q3_sales	Q3_cost
华东	2450.00	1890.00	2680.50	2050.20	2920.30	2230.80

你想分析“各季度毛利率”，就必须把Q1_sales、Q2_sales等列名中的Q1、Q2提取为新列quarter，把_sales、_cost提取为metric。这就是melt()的主场。

正确写法：

# 先确定id_vars（不变的标识列） id_vars = ['region'] # 确定value_vars（要融化的列） value_vars = [col for col in df.columns if col != 'region'] # 执行melt melted = df.melt( id_vars=id_vars, value_vars=value_vars, var_name='quarter_metric', # 熔化后列名存这里 value_name='amount' # 熔化后数值存这里 ) # 输出：region, quarter_metric, amount # 华东, Q1_sales, 2450.00 # 华东, Q1_cost, 1890.00

然后用str.extract()拆解quarter_metric：

melted[['quarter','metric']] = melted['quarter_metric'].str.extract(r'(Q\d+)_(\w+)') # 最终得到：region, quarter, metric, amount

致命错误：melt()时漏掉id_vars。比如忘记写id_vars=['region']，melt()会把所有列都融化，region值也会丢失。我在某政府数据平台项目中见过因此导致整个财政分析报表金额翻倍的事故——因为region列被当成value融化，每个region值重复了N次。

注意：melt()是不可逆操作。一旦执行，原始列结构永久丢失。我的习惯是：melt()前必加df_copy = df.copy()，并在Jupyter中用df_copy.head()确认原始结构。

4. 实战全流程：从120万行订单明细到CEO驾驶舱的7步炼金术

我们以某跨境电商公司的真实月度分析需求为蓝本，完整走一遍多维聚合的数据变形链。原始数据orders.csv含120万行、58列，核心字段：

order_id,order_date,ship_country,ship_region（北美/欧洲/亚太）
product_category,brand,product_line
sales_usd,cost_usd,shipping_fee_usd
is_returned（布尔值）

目标：生成CEO驾驶舱看板，包含：

各大区（北美/欧洲/亚太）各季度（Q1-Q4）各品类（Electronics/Apparel/Home）的GMV热力图
各大区各季度退货率（is_returned==True的订单占比）
各大区各季度各品牌毛利率（(sales-cost)/sales）排名TOP5

4.1 第一步：数据预处理与维度对齐（耗时23秒）

原始数据中ship_region有空值，order_date是字符串，is_returned是字符串'Y'/'N'。必须先清洗：

# 读取并基础清洗 df = pd.read_csv('orders.csv', parse_dates=['order_date']) # 对齐维度：空ship_region按ship_country映射（维护一张国家-大区映射表） region_map = {'US':'北美','CA':'北美','UK':'欧洲','DE':'欧洲','JP':'亚太','CN':'亚太'} df['ship_region'] = df['ship_country'].map(region_map).fillna('其他') # 标准化is_returned df['is_returned'] = df['is_returned'].map({'Y':True,'N':False}).fillna(False) # 提取季度 df['quarter'] = df['order_date'].dt.to_period('Q').astype(str) # '2023Q1'

关键细节：dt.to_period('Q')比dt.quarter更可靠，因为它能处理跨年季度（如2023-12-01是2023Q4，而非2023Q1）。我曾因用dt.quarter导致Q4数据全归到Q1，延误了圣诞季复盘。

4.2 第二步：构建基础聚合长表（耗时8.2秒）

按三大核心维度ship_region、quarter、product_category聚合：

base_agg = df.groupby(['ship_region','quarter','product_category']).agg( gmv_usd=('sales_usd', 'sum'), cost_usd=('cost_usd', 'sum'), shipping_fee_usd=('shipping_fee_usd', 'sum'), total_orders=('order_id', 'count'), returned_orders=('is_returned', 'sum') # True会被计为1 ).reset_index() # 此时base_agg是长表：327行（3大区×4季度×3品类=36，但实际有缺失，共327）

注意：returned_orders用'sum'而非'count'，因为is_returned是布尔值，sum()直接统计True个数，比count()后过滤更高效。

4.3 第三步：计算复合指标（耗时0.3秒）

在长表上直接计算：

base_agg = base_agg.assign( return_rate = lambda x: x['returned_orders'] / x['total_orders'], gross_margin = lambda x: (x['gmv_usd'] - x['cost_usd']) / x['gmv_usd'], net_margin = lambda x: (x['gmv_usd'] - x['cost_usd'] - x['shipping_fee_usd']) / x['gmv_usd'] )

实操心得：所有计算必须在长表阶段完成！若先unstack()再计算，return_rate公式要写三遍（北美/欧洲/亚太各一遍），且无法处理分母为0的情况。长表中np.where(base_agg['total_orders']>0, ..., 0)一行搞定。

4.4 第四步：生成GMV热力图宽表（耗时1.7秒）

为可视化，需ship_region为列，quarter为行，product_category为页（PivotTable的columns参数）：

gmv_pivot = pd.pivot_table( base_agg, values='gmv_usd', index='quarter', columns=['ship_region','product_category'], aggfunc='sum', fill_value=0 ) # 输出：index=quarter, columns=MultiIndex([('北美','Electronics'), ('北美','Apparel')...])

但gmv_pivot是二维表，要画热力图需quarter和ship_region为行列。于是：

# 先unstack product_category，让品类成为列层级 gmv_wide = base_agg.pivot_table( values='gmv_usd', index=['quarter','ship_region'], columns='product_category', aggfunc='sum', fill_value=0 ) # 再unstack ship_region，让大区成为列 gmv_final = gmv_wide.unstack('ship_region', fill_value=0) # 现在：index=quarter, columns=MultiIndex([product_category, ship_region])

此时gmv_final可直接喂给seaborn.heatmap()。

4.5 第五步：退货率对比表（耗时0.5秒）

退货率需ship_region为行，quarter为列，便于横向对比：

return_pivot = base_agg.pivot_table( values='return_rate', index='ship_region', columns='quarter', aggfunc='mean', # 各大区各季度平均退货率 fill_value=0 )

注意aggfunc='mean'：因为base_agg中每个单元格已是该组合的退货率，mean在此处是安全的（单值均值等于自身）。若用sum会错误放大。

4.6 第六步：品牌毛利率TOP5（耗时15.8秒，最耗时环节）

这是最复杂的变形：需按ship_region和quarter分组，对每个组内brand的gross_margin排序取TOP5。

# 先按region/quarter/brand聚合 brand_agg = df.groupby(['ship_region','quarter','brand']).agg( gmv_usd=('sales_usd','sum'), cost_usd=('cost_usd','sum') ).assign( gross_margin = lambda x: (x['gmv_usd'] - x['cost_usd']) / x['gmv_usd'] ).reset_index() # 对每个region/quarter组，取gross_margin降序前5 top5_brands = ( brand_agg.sort_values(['ship_region','quarter','gross_margin'], ascending=[True,True,False]) .groupby(['ship_region','quarter']) .head(5) .sort_values(['ship_region','quarter','gross_margin'], ascending=[True,True,False]) )

关键技巧：sort_values必须放在groupby().head()之前！否则head(5)取的是原始顺序的前5，而非排序后的前5。这个错误让我在某项目中交付了错误的TOP5名单，被客户当面指出。

4.7 第七步：合并输出与异常监控（耗时2.1秒）

将三张表合并为最终报告：

# 用ExcelWriter写入不同sheet with pd.ExcelWriter('ceo_dashboard.xlsx') as writer: gmv_final.to_excel(writer, sheet_name='GMV_Heatmap') return_pivot.to_excel(writer, sheet_name='Return_Rate') top5_brands.to_excel(writer, sheet_name='Top5_Margin_Brands') # 添加数据质量监控页 quality_report = pd.DataFrame({ 'metric': ['Total Orders', 'Missing Region', 'Q4 Data Coverage'], 'value': [ len(df), df['ship_region'].isnull().sum(), len(df[df['quarter']=='2023Q4']) / len(df) * 100 ] }) quality_report.to_excel(writer, sheet_name='Data_Quality', index=False)

最终文件ceo_dashboard.xlsx共4个sheet，总生成时间51.8秒，内存峰值1.8GB。

5. 高频故障排查手册：那些让你凌晨三点还在debug的“幽灵错误”

5.1 “Index contains duplicate entries”——多维聚合的头号杀手

现象：执行df.groupby(['A','B']).agg(...).unstack('C')时报错ValueError: Index contains duplicate entries。

根因：unstack('C')要求索引中A和B的每个组合，对应C的值必须唯一。但你的数据中存在A='华东', B='Q3'却有两条记录C='饮料'（比如一条是可口可乐，一条是百事可乐，但C字段没区分）。

诊断：

# 检查C维度在A-B组合下的唯一性 dup_check = df.groupby(['A','B'])['C'].nunique() print(dup_check[dup_check > 1]) # 显示哪些A-B组合有多个C值

解决：

若C本应唯一（如ID），说明数据脏，需清洗；
若C天然不唯一（如品牌），则unstack('C')不合理，应改用pivot_table(values='X', index=['A','B'], columns='C')，它会自动聚合重复项。

5.2 “Shape of passed values is X, indices imply Y”——列对齐的隐形战争

现象：unstack()后尝试assign(new_col = ...)报错，提示形状不匹配。

根因：unstack()后列是MultiIndex，而你的计算表达式返回的是普通Series，pandas无法自动对齐。

诊断：

print(wide_df.columns) # 查看是否为MultiIndex print(type(wide_df['sales_amt'])) # 若是Series，说明列名是'sales_amt'而非('sales_amt','华东')

解决：

方案1（推荐）：用元组指定列，如wide_df[('sales_amt','华东')]
方案2：wide_df.columns = wide_df.columns.map('_'.join)展平列名，但会丢失层级语义；
方案3：用wide_df.xs('华东', axis=1, level='region')提取子集再计算。

5.3 “Cannot convert column to bool”——布尔聚合的温柔陷阱

现象：df.groupby(['A']).agg({'flag_col': 'sum'})结果中flag_col是浮点数，而非整数。

根因：flag_col是布尔型，sum()返回int64，但若存在NaN，pandas会自动转为float64以容纳NaN。

诊断：

print(df['flag_col'].dtype) # bool print(df['flag_col'].isnull().sum()) # 若>0，则sum后为float

解决：

清洗：df['flag_col'] = df['flag_col'].fillna(False)
或强制类型：df.groupby(...).agg({'flag_col': lambda x: x.sum().astype(int)})

5.4 性能雪崩：当unstack()吃光16GB内存

现象：unstack()执行10分钟无响应，系统内存飙升。

根因：unstack()会创建稠密矩阵。若A有1000个值，B有1000个值，unstack('B')后将生成100万行×1000列的表，即使99%是NaN。

诊断：

print(f"Index levels: {len(result.index)}") # 看聚合后行数 print(f"Unique A: {result.index.get_level_values(0).nunique()}") print(f"Unique B: {result.index.get_level_values(1).nunique()}")

解决：

方案1（首选）：放弃宽表，用plotly.express.imshow()直接画MultiIndex长表的热力图；
方案2：用sparse=True参数（pandas 1.4+），result.unstack('B', sparse=True)；
方案3：分块处理，for region in regions: sub_df = result.xs(region, level='region'); sub_df.unstack(...)

5.5 时间维度错乱：Q4数据跑到Q1去了

现象：order_date.dt.quarter返回的Q1实际是12月数据。

根因：dt.quarter按日历季度（Jan-Mar为Q1），但业务季度可能按财年（Jul-Jun为Q1）。某公司财报季是7月1日开始。

诊断：

print(df['order_date'].min(), df['order_date'].max()) # 看日期范围 print(df['order_date'].dt.quarter.value_counts().sort_index()) # 看分布

解决：

用pd.offsets.QuarterEnd(startingMonth=7)定义财年：

df['fiscal_quarter'] = (df['order_date'] + pd.offsets.QuarterEnd(startingMonth=7)).dt.to_period('Q')

6. 经验沉淀：十年踩坑总结的7条军规

军规一：永远先groupby().agg()，再变形
我见过太多人试图用pivot_table()一步到位，结果在百万行数据上卡死。agg()生成长表是内存最优路径，所有变形都应在轻量级长表上进行。
军规二：unstack()前必查index.names，stack()后必sort_index()
索引层级是多维聚合的命脉，任何对索引的假设都必须用print()验证。sort_index()成本极低，却是避免逻辑错位的保险丝。
军规三：宽表只用于展示，长表才是计算的圣杯
计算毛利率、环比、占比等一切衍生指标，必须在MultiIndex长表上用assign()完成。宽表计算是自找麻烦。
军规四：pivot_table()是原型利器，非生产首选
它的便利性以性能为代价。上线脚本中，我一律用groupby+unstack组合，仅在探索性分析时用pivot_table()。
军规五：缺失值不是fill_value=0，是业务警报
unstack()产生的NaN必须溯源。是数据未上报？ETL失败？还是真实业务空白？把它记入Data_Quality页，比填0有价值一万倍。
军规六：时间维度必须用pd.Period，禁用dt.quarter
Period能精确表示季度区间（如'2023Q4'代表2023-10至2023-12），而dt.quarter只是数字标签，无法处理跨年、财年等复杂场景。
军规七：每次变形后，用df.info()和df.head()双重确认
我的Jupyter每个cell后都跟这两行。info()看内存和类型，head()看数据形态。这10秒节省了无数debug时间。