直接用shift()算同比会出错，因它默认按行序位移而不感知时间顺序和分组边界；需先按product、region、date排序并分组后调用shift()，且时间列须转为datetime64类型。
为什么直接用 shift() 算同比会出错？
因为 shift() 默认按整个 DataFrame 行序位移，不感知业务时间顺序和分组边界。比如你有多个产品、多个地区的时间序列数据，若没先按 groupby(['product', 'region']) 排序并分组，shift(12) 可能把“北京-手机”下个月的数据错拉成“上海-电脑”的上月值——位移跨了组，结果全乱。
正确做法是：先确保数据按时间列（如 'date'）升序排列，再用 groupby + apply 或 sort_values + groupby(..., group_keys=False) 配合 shift()。
- 必须显式排序：
df.sort_values(['product', 'region', 'date'], inplace=True) - 分组后位移才安全：
df.groupby(['product', 'region'])['sales'].shift(1) - 避免隐式索引干扰：别在未重置索引的 grouped 对象上直接链式调用
shift()，容易返回 NaN 占位异常
同环比计算中 shift() 的参数怎么选？
环比看上期（周/月/季），同比看去年同期，但“期”的单位得和你的数据粒度对齐。不是所有数据都适合 shift(12)——只有月度且无缺失月份时才成立；季度数据要用 shift(4)；周数据可能得用 shift(52)，但更稳妥的是基于日期差计算（见下一条）。
- 月度数据（完整连续）：
df['moy_qoq'] = df['value'] / df.groupby('product')['value'].shift(1) - 1 - 年度同比（强制 12 个月）：
df['yoy'] = df['value'] / df.groupby('product')['value'].shift(12) - 1 - 如果存在月份缺失（如 2023-02 缺失），
shift(12)会把 2024-02 拉到 2022-02，而非真正的 2023-02 → 此时应改用pd.merge_asof或时间偏移对齐
如何用 groupby 处理多维分区下的空值与边界？
分组后每个子组首行调用 shift() 必然为 NaN，这是正常行为，但容易被误判为计算失败。关键是要区分「合理缺失」和「逻辑错误」：比如某产品 2023-01 是首条记录，其环比为空合理；但如果同一产品在 2023-06 后突然出现空值，可能是分组键不一致（如 region 拼写不统一）或时间列类型非 datetime64 导致排序失效。
立即学习“Python免费学习笔记（深入）”；
- 检查分组完整性：
df.groupby(['product', 'region']).size()看各组长度是否符合预期 - 时间列必须是 datetime：
df['date'] = pd.to_datetime(df['date'])，否则sort_values会按字符串排（'2023-10' - 填充策略要谨慎：不要用
fillna(0)盖掉真实缺失，建议保留NaN，后续用np.where(pd.notna(...), ...)控制展示逻辑
性能陷阱：大表上别在 groupby().apply() 里写循环
有人习惯写 df.groupby('product').apply(lambda g: g.sort_values('date').assign(qoq=...))，这会导致每组都重新排序、重建索引，速度极慢。Pandas 的 groupby + shift 是向量化操作，原生支持高效位移，只要前置排序一次即可复用。
- 快的方式：
df.sort_values(['product', 'date'], inplace=True); df['qoq'] = df.groupby('product')['value'].diff() / df.groupby('product')['value'].shift(1) - 慢的方式：嵌套
apply+ 手动遍历 +iloc索引 → 百万行数据可能从 200ms 拖到 15s - 验证是否真用了向量化：
df.groupby('product')['value'].shift(1)返回的是 Series，长度同原 df，不是 list 或 dict
实际业务中，最常被忽略的是时间列的 dtype 和分组键的唯一性校验——这两点不出问题，shift 和 groupby 就不会“神隐”掉本该存在的值。
