pandas动态时间窗口实现多周期销量统计-尧图手机网站定制

1. 项目概述：为什么“近X天销量统计”是业务分析的起点而非终点

在某电商公司做数据支持的那两年，我每天早上八点准时打开BI看板，第一眼不是看总GMV，而是盯着“近7天销量趋势”那个小卡片——它像血压计一样，能快速判断业务是否在正常节律里跳动。后来带团队时发现，新人常把“近7天、近15天、近30天销量统计”当成一个简单的数据汇总任务，用三行pandas代码跑完就交差。但实际落地中，这个看似基础的操作，恰恰是业务方最常质疑、最易出错、也最能体现数据工程师专业深度的环节。比如运营同事问：“为什么我昨天改了主图，今天近7天销量没涨？”——这时候你不能只回一句“数据没错”，而要能立刻拆解：近7天统计口径是否包含昨日？是否剔除了刷单订单？退款订单是按支付时间还是完成时间计入？这些细节，全藏在pandas的几行代码背后。本文聚焦的正是这个高频却高危的场景：用pandas构建可解释、可复用、可审计的多周期销量统计逻辑。它不涉及机器学习模型，也不依赖大数据平台，纯粹靠pandas的数据处理能力，解决真实业务中“时间窗口动态计算”“数据质量兜底”“业务口径对齐”三大痛点。适合刚转行的数据分析师、需要快速交付报表的后端开发者，以及想夯实pandas底层逻辑的中级工程师。核心关键词——pandas时间窗口、销量统计、滚动周期、业务口径对齐、数据质量校验——每一个都会在后续章节中被掰开揉碎，告诉你为什么这样写，而不是那样写。

2. 整体设计思路：从“写死日期”到“动态时间窗口”的范式升级

2.1 传统做法的致命缺陷：硬编码日期的“纸糊城墙”

很多初学者会这样写：

import pandas as pd df = pd.read_csv("sales.csv") # 硬编码日期范围 last_7_days = df[(df['order_date'] >= '2024-05-01') & (df['order_date'] <= '2024-05-07')] last_15_days = df[(df['order_date'] >= '2024-04-25') & (df['order_date'] <= '2024-05-09')]

这种写法在测试环境能跑通，但上线后就是定时炸弹。问题有三：
第一，时效性归零：每次运行都要手动改日期，错过一天就得重跑，业务方凌晨三点发消息问“今天数据呢？”，你得爬起来改代码；
第二，逻辑不可复用：不同报表要复制粘贴三套日期逻辑，A报表用>=，B报表用>，C报表忘了加时区转换，结果三个看板数字对不上；
第三，无法应对业务变更：某天运营突然说“近7天要从下单时间改成发货时间”，你得翻遍所有脚本，逐行替换字段名，漏掉一行就引发客诉。

我见过最惨的一次，是某次大促前夜，运维同事临时把服务器时区从UTC+8改成UTC，所有硬编码的'2024-05-01'瞬间变成前一天的数据，导致当天的实时大屏显示销量暴跌40%，技术负责人被叫到现场紧急排查两小时，最后发现根源竟是这行字符串。

2.2 正确范式：以“当前时间”为锚点的动态窗口系统

真正的解决方案，是把时间窗口抽象成一个可配置、可计算、可验证的系统。核心思想就一句话：所有周期统计，都基于pd.Timestamp.now()动态推算起止时间，而非固定字符串。但这不是简单调用today - pd.Timedelta(days=7)就完事——pandas的时间运算有陷阱，必须结合业务规则做二次校准。

举个真实案例：某生鲜平台要求“近7天销量”指“从今天0点往前推7×24小时，即包含今天和过去6天”。但pd.Timestamp.now() - pd.Timedelta(days=7)得到的是“此刻往前推7天”，比如现在是5月10日14:30，结果就是5月3日14:30，这会导致当天下午的订单被漏掉。正确做法是先截断到当日0点，再减去天数：

# ✅ 正确：获取“今天0点”作为基准 today_start = pd.Timestamp.now().normalize() # 返回 2024-05-10 00:00:00 last_7_start = today_start - pd.Timedelta(days=7) # 2024-05-03 00:00:00 last_7_end = today_start - pd.Timedelta(seconds=1) # 2024-05-09 23:59:59

这里normalize()是关键，它把任意时刻归一化为当日0点，避免了时分秒带来的偏差。而- pd.Timedelta(seconds=1)是为了确保区间闭合——因为业务上“近7天”通常指7个完整自然日，不包含今天（否则就成了“近7天含今日”）。这个细节，我在给某快消品牌做数据治理时，光是和业务方对口径就花了三天：他们最初说的“近7天”其实是“最近7个自然日”，但系统里存的订单时间是精确到秒的，必须明确边界是左闭右闭、左闭右开，还是其他组合。

2.3 三层架构设计：分离计算逻辑、业务规则与数据源

为了解决复用性和可维护性，我把整个系统拆成三层：

数据层（Data Layer）：只负责从数据库或CSV读取原始订单数据，并做最基础的清洗（如去重、类型转换），不涉及任何时间计算；
规则层（Rule Layer）：定义所有业务口径，如“近7天=过去7个自然日”“近30天=过去30个自然日”“是否剔除退款订单”“销量按支付金额还是商品件数计算”；
计算层（Calculation Layer）：接收数据层输出和规则层配置，用pandas执行具体的时间窗口切片、聚合、校验。

这种分层让修改成本降到最低。比如业务方突然要求“近15天销量要排除试用订单”，你只需在规则层加一个exclude_trial_orders=True参数，计算层自动适配，完全不用碰数据读取逻辑。我在某SaaS公司的实践证明，这套架构让后续新增“近90天”“近半年”统计的开发时间，从原来的半天压缩到15分钟以内。

提示：规则层建议用Python字典或YAML文件配置，避免写死在代码里。例如：
time_windows: last_7_days: days: 7 include_today: false exclude_refunded: true exclude_trial: false

3. 核心细节解析：pandas时间处理的五个关键陷阱与避坑方案

3.1 陷阱一：`datetime`列类型未显式转换，导致布尔索引失效

这是新手踩得最多的坑。当你从CSV读取订单时间时，pandas默认可能把它当object类型处理：

df = pd.read_csv("sales.csv") print(df['order_date'].dtype) # 可能输出 object # 下面这行会报错或返回空结果！ mask = (df['order_date'] >= '2024-05-01')

原因在于：object类型的字符串比较是按字典序进行的，'2024-05-01' > '2024-04-30'成立，但'2024-05-01' > '2024-5-1'就不一定了（因为字符串长度不同）。更糟的是，某些CSV里时间格式混乱，有的写2024/05/01，有的写01-May-2024，直接比较会静默失败。

正确解法：强制转换并验证

# ✅ 第一步：用to_datetime强转，errors='coerce'将非法值转为NaT df['order_date'] = pd.to_datetime(df['order_date'], errors='coerce') # ✅ 第二步：检查转换结果，揪出脏数据 invalid_dates = df[df['order_date'].isna()]['order_date'].count() if invalid_dates > 0: print(f"警告：{invalid_dates}条记录时间格式异常，已设为NaT") # ✅ 第三步：布尔索引前，先drop NaT（否则结果包含空值） df_clean = df.dropna(subset=['order_date'])

我在某母婴电商项目中遇到过，因上游ERP导出时用了Excel的“自适应日期格式”，导致12%的订单时间被识别为字符串'44200'（Excel序列号），不加errors='coerce'直接报错，加了之后能定位问题，业务方才意识到要规范导出模板。

3.2 陷阱二：时区混淆引发跨日数据错位

国内大部分业务系统用东八区时间（UTC+8），但pandas默认创建的时间戳是本地时区（如果你服务器在海外，可能是UTC）。假设你的订单时间存的是2024-05-01 00:00:00（东八区），而pandas把它当成了UTC时间，那么在计算时就会偏差8小时：

# ❌ 危险：未指定时区，pandas按本地时区解析 ts = pd.to_datetime('2024-05-01 00:00:00') # 如果服务器在UTC，这其实是东八区的5月1日8点 # 结果：近7天窗口会少算8小时数据 # ✅ 安全：显式声明时区 ts = pd.to_datetime('2024-05-01 00:00:00').tz_localize('Asia/Shanghai') # 或者统一转换整列 df['order_date'] = pd.to_datetime(df['order_date']).dt.tz_localize('Asia/Shanghai')

更稳妥的做法，是在数据接入层就统一时区。我们团队的规范是：所有入库的时间字段，必须存储为带时区的datetime64[ns, Asia/Shanghai]类型。这样后续任何计算，都不用担心时区漂移。某次双十一大促，就是因为没做这步，导致凌晨1点的爆发订单被算进“昨日销量”，运营误判流量衰减，差点取消了原定的追加投放。

3.3 陷阱三：`resample`vs`rolling`：选错方法导致性能雪崩

看到“近X天”，很多人第一反应是resample('7D')。但这是典型误用。resample是按固定频率重采样，比如把每小时数据聚合成每日，它生成的是等距的时间桶（0-24h, 24-48h...），而“近7天”是滚动窗口（今天-7天，今天-6天，今天-5天...），必须用rolling。

但rolling也有坑：直接对时间序列用df.rolling('7D')，要求索引必须是DatetimeIndex且严格递增。如果订单时间有重复（同一秒下多笔单）、或有乱序（后下的单时间戳比前单早），rolling会报错或结果错乱。

实测对比（10万行订单数据）：

方法	耗时	内存占用	是否支持非等距时间	是否需排序
`df.set_index('order_date').rolling('7D').sum()`	3.2s	高	✅	✅（必须）
`df.sort_values('order_date').rolling(window=7, on='order_date').sum()`	1.8s	中	❌（仅支持整数窗口）	✅
推荐：布尔索引 + groupby	0.6s	低	✅	❌

最终我们选择第三种：先用动态时间窗口生成布尔掩码，再groupby聚合。它不依赖索引顺序，性能最优，且逻辑最透明。代码骨架如下：

def calc_window_sales(df, window_days, date_col='order_date', exclude_refunded=False, sales_col='amount'): """ 计算指定天数窗口的销量总和 """ # 1. 获取动态时间边界 now = pd.Timestamp.now().normalize() start = now - pd.Timedelta(days=window_days) end = now - pd.Timedelta(seconds=1) # 2. 构建布尔掩码（自动处理NaT） mask = (df[date_col] >= start) & (df[date_col] <= end) if exclude_refunded: mask = mask & (df['status'] != 'refunded') # 3. 聚合计算 return df[mask][sales_col].sum()

3.4 陷阱四：`fillna(0)`的滥用掩盖数据质量问题

很多脚本在最后加一句result.fillna(0)，觉得“没数据就填0，看着整齐”。但这是饮鸩止渴。比如某天近7天销量为0，真实原因可能是：

数据同步延迟（ETL还没跑完）
某个SKU的库存为0，根本没产生订单
接口故障，订单没写入数据库

如果一律填0，监控告警就失效了。正确的做法是区分“业务事实为0”和“数据缺失”，后者应该抛出明确警告：

# ✅ 区分场景 total_sales = calc_window_sales(...) if pd.isna(total_sales): raise ValueError("近7天销量计算结果为空，请检查数据源和时间范围") elif total_sales == 0: # 业务上允许为0，但需记录日志供追溯 logger.warning(f"近7天销量为0，时间范围：{start} ~ {end}")

我们在某跨境项目中，就靠这个机制提前2小时发现了物流API的间歇性超时，避免了当天销量报表的集体失真。

3.5 陷阱五：未做数据质量校验，导致错误结论被放大

最危险的不是代码报错，而是代码跑通但结果错误。比如“近30天销量”本该是100万，因时间窗口算错变成90万，业务方据此砍掉了20%的推广预算。因此，必须加入三层校验：

数量级校验：近30天销量不应低于近7天的3倍（考虑周末效应，可设阈值为2.5倍）；
环比校验：与上周同窗口对比，波动不应超过±50%（大促除外，需标记）；
构成校验：各渠道销量之和应等于总销量，误差>0.1%则告警。

# 示例：构成校验 channel_sum = df[mask].groupby('channel')['amount'].sum().sum() total_sum = df[mask]['amount'].sum() if abs(channel_sum - total_sum) / total_sum > 0.001: logger.error("渠道销量合计与总销量偏差超限")

这套校验逻辑，是我们团队的“数据守门员”，上线后拦截了73%的潜在数据事故。

4. 实操过程详解：从原始订单表到三张标准销量报表的完整流水线

4.1 原始数据结构与清洗要点

假设我们拿到的原始订单表orders_raw.csv包含以下关键字段：

字段名	类型	说明	清洗要求
`order_id`	string	订单唯一ID	去重（防止同一订单导入多次）
`order_date`	string	下单时间	转`datetime64[ns, Asia/Shanghai]`，非法值标为NaT
`status`	string	订单状态	统一为小写，映射标准状态（'paid','shipped','refunded','cancelled'）
`amount`	float	支付金额	剔除负数（异常退款）和0值（测试单）
`sku_id`	string	商品编码	去除首尾空格，空值过滤
`channel`	string	销售渠道	归一化（'taobao'→'taobao', 'TB'→'taobao'）

清洗代码实录（含注释）：

def clean_orders(df): """订单数据清洗主函数""" # 1. 去重：按order_id去重，保留第一次出现的记录 df = df.drop_duplicates(subset=['order_id'], keep='first') # 2. 时间列清洗 df['order_date'] = pd.to_datetime( df['order_date'], errors='coerce', infer_datetime_format=True ).dt.tz_localize('Asia/Shanghai') # 3. 状态标准化 status_map = { '已支付': 'paid', 'paid': 'paid', 'PAYED': 'paid', '已发货': 'shipped', 'shipped': 'shipped', '已退款': 'refunded', 'refunded': 'refunded', '已取消': 'cancelled', 'cancelled': 'cancelled' } df['status'] = df['status'].str.strip().map(status_map).fillna('unknown') # 4. 金额清洗：剔除异常值 df = df[(df['amount'] > 0) & (df['amount'] < 100000)] # 剔除测试单和刷单 # 5. SKU和渠道清洗 df['sku_id'] = df['sku_id'].str.strip().replace('', pd.NA) df['channel'] = df['channel'].str.strip().str.lower() df['channel'] = df['channel'].replace({ 'tb': 'taobao', 'tao bao': 'taobao', 'jd': 'jingdong', 'jing dong': 'jingdong' }) # 6. 最终过滤：只保留有效订单 df = df.dropna(subset=['order_date', 'sku_id', 'amount']) return df # 执行清洗 df_orders = pd.read_csv("orders_raw.csv") df_clean = clean_orders(df_orders) print(f"清洗后数据量：{len(df_clean)}，时间范围：{df_clean['order_date'].min()} ~ {df_clean['order_date'].max()}")

实测某次清洗，127万行原始数据，清洗后剩118万行，剔除了9万行问题数据，其中62%是时间格式错误，28%是金额异常，10%是状态映射失败。没有这步，后续所有统计都是空中楼阁。

4.2 构建动态时间窗口工厂函数

为避免重复写三套时间计算逻辑，我们封装一个TimeWindowFactory类：

class TimeWindowFactory: def __init__(self, reference_time=None): self.ref_time = reference_time or pd.Timestamp.now().normalize() def get_window(self, days, include_today=False): """ 获取指定天数的时间窗口 :param days: 天数，如7、15、30 :param include_today: 是否包含今天（True=今天0点到此刻，False=过去N个自然日） :return: (start_timestamp, end_timestamp) """ if include_today: # 包含今天：从今天0点开始，到此刻为止 start = self.ref_time end = pd.Timestamp.now() else: # 不包含今天：过去N个自然日，即今天0点往前推N天，到昨天23:59:59 start = self.ref_time - pd.Timedelta(days=days) end = self.ref_time - pd.Timedelta(seconds=1) return start, end # 使用示例 tw = TimeWindowFactory() last_7_start, last_7_end = tw.get_window(7, include_today=False) print(f"近7天：{last_7_start} ~ {last_7_end}") # 输出：近7天：2024-05-03 00:00:00 ~ 2024-05-09 23:59:59

这个工厂函数的好处是：所有时间计算都基于同一个ref_time，保证了多窗口之间的逻辑一致性。比如计算近7天和近15天时，它们的结束时间都是2024-05-09 23:59:59，不会出现一个截止到0点、一个截止到23:59的混乱。

4.3 三张核心报表的生成与输出

4.3.1 近7天销量日报表（最细粒度）

这是运营每天盯盘的核心看板，要求包含渠道、品类、TOP10商品维度：

def generate_last_7_report(df, tw_factory): start, end = tw_factory.get_window(7, include_today=False) mask = (df['order_date'] >= start) & (df['order_date'] <= end) df_7 = df[mask].copy() # 渠道销量 channel_sales = df_7.groupby('channel')['amount'].agg(['sum', 'count']).round(2) channel_sales.columns = ['销售额', '订单数'] # 品类销量（假设有个category字段） category_sales = df_7.groupby('category')['amount'].sum().sort_values(ascending=False).head(10) # TOP10商品 top10_sku = df_7.groupby('sku_id')['amount'].sum().sort_values(ascending=False).head(10) # 汇总 report = { 'report_date': tw_factory.ref_time.strftime('%Y-%m-%d'), 'time_window': f"{start.date()} ~ {end.date()}", 'total_sales': df_7['amount'].sum(), 'total_orders': len(df_7), 'channel_breakdown': channel_sales, 'top_category': category_sales, 'top_sku': top10_sku } return report # 生成报表 report_7 = generate_last_7_report(df_clean, tw) print(f"近7天总销量：¥{report_7['total_sales']:,.2f}") print(report_7['channel_breakdown'])

4.3.2 近15天趋势对比表（关注变化）

此表用于周会汇报，重点展示环比变化：

def generate_last_15_trend(df, tw_factory): # 当前15天窗口 curr_start, curr_end = tw_factory.get_window(15, include_today=False) # 上一周期（往前推15天） prev_start = curr_start - pd.Timedelta(days=15) prev_end = curr_start - pd.Timedelta(seconds=1) curr_mask = (df['order_date'] >= curr_start) & (df['order_date'] <= curr_end) prev_mask = (df['order_date'] >= prev_start) & (df['order_date'] <= prev_end) curr_sales = df[curr_mask]['amount'].sum() prev_sales = df[prev_mask]['amount'].sum() change_pct = ((curr_sales - prev_sales) / prev_sales * 100) if prev_sales != 0 else 0 return { 'current_period': f"{curr_start.date()}~{curr_end.date()}", 'previous_period': f"{prev_start.date()}~{prev_end.date()}", 'current_sales': curr_sales, 'previous_sales': prev_sales, 'change_percentage': round(change_pct, 2) } report_15 = generate_last_15_trend(df_clean, tw) print(f"近15天销量：¥{report_15['current_sales']:,.2f} " f"（环比{report_15['change_percentage']}%）")

4.3.3 近30天综合分析表（支持决策）

这是给管理层看的摘要，需包含数据质量评估：

def generate_last_30_summary(df, tw_factory): start, end = tw_factory.get_window(30, include_today=False) mask = (df['order_date'] >= start) & (df['order_date'] <= end) df_30 = df[mask] # 基础指标 total_sales = df_30['amount'].sum() avg_daily = total_sales / 30 # 数据质量检查 date_range = df_30['order_date'].dt.date expected_days = 30 actual_days = date_range.nunique() coverage_rate = actual_days / expected_days * 100 # 异常检测 outlier_count = df_30[df_30['amount'] > 50000].shape[0] # 单笔超5万视为异常 return { 'time_window': f"{start.date()} ~ {end.date()}", 'total_sales': total_sales, 'avg_daily_sales': round(avg_daily, 2), 'data_coverage': f"{coverage_rate:.1f}%", 'outlier_orders': outlier_count, 'quality_score': '✅' if coverage_rate > 95 and outlier_count < 5 else '⚠️' } report_30 = generate_last_30_summary(df_clean, tw) print(f"近30天总销量：¥{report_30['total_sales']:,.2f}") print(f"数据覆盖率：{report_30['data_coverage']}，质量评分：{report_30['quality_score']}")

4.4 输出与交付：生成Excel报告的实战技巧

业务方最终要的是Excel，不是DataFrame。用pandas.ExcelWriter可以优雅地生成多Sheet报表：

def export_to_excel(reports, filename): with pd.ExcelWriter(filename, engine='openpyxl') as writer: # Sheet1：近7天详情 reports['last_7']['channel_breakdown'].to_excel( writer, sheet_name='近7天渠道', index=True ) # Sheet2：近15天趋势 trend_df = pd.DataFrame([reports['last_15']]) trend_df.to_excel(writer, sheet_name='近15天趋势', index=False) # Sheet3：近30天摘要 summary_df = pd.DataFrame([reports['last_30']]) summary_df.to_excel(writer, sheet_name='近30天摘要', index=False) # Sheet4：原始数据（供审计） # 只导出当前窗口数据，避免文件过大 start, end = reports['last_7']['time_window'].split(' ~ ') mask = (df_clean['order_date'] >= start) & (df_clean['order_date'] <= end) df_clean[mask].to_excel(writer, sheet_name='原始数据', index=False) # 执行导出 all_reports = { 'last_7': report_7, 'last_15': report_15, 'last_30': report_30 } export_to_excel(all_reports, "销量统计_20240510.xlsx")

关键技巧：

用openpyxl引擎支持样式设置（如标题加粗、数字格式）；
“原始数据”Sheet只导出当前窗口数据，10万行以内，避免Excel打不开；
文件名带日期，方便版本管理；
导出前校验磁盘空间，防止写满。

5. 常见问题与排查技巧实录：来自生产环境的12个真实故障

5.1 问题速查表：症状、原因、解决方案

序号	症状	可能原因	快速排查命令	解决方案
1	近7天销量为0，但订单表有数据	`order_date`列未成功转为datetime，全为NaT	`df['order_date'].head(); df['order_date'].dtype`	检查`to_datetime`的`errors`参数，加`infer_datetime_format=True`
2	近15天销量比近7天还小	时间窗口计算错误，`end`时间早于`start`	`print(tw.get_window(15))`	检查`reference_time`是否被意外修改，确认`normalize()`调用
3	Excel导出后数字显示为科学计数法	Excel自动格式化长数字（如订单ID）	`df['order_id'] = df['order_id'].astype(str)`	导出前将ID列转字符串，或用`openpyxl`设置单元格格式
4	多次运行结果不一致	`pd.Timestamp.now()`在函数内多次调用，时间点漂移	将`now = pd.Timestamp.now()`提至函数外	所有时间计算基于同一个时间戳实例
5	某渠道销量突增10倍	该渠道状态映射错误，把'cancelled'映射成'paid'	`df[df['channel']=='xxx']['status'].value_counts()`	重构状态映射字典，增加`unknown`兜底
6	报表生成耗时超2分钟	未做数据清洗，100万行原始数据直接计算	`len(df); df.memory_usage(deep=True).sum()`	先`clean_orders()`，再计算；对大表用`query()`替代布尔索引
7	近30天销量与BI看板差5%	BI看板剔除了测试订单，脚本没剔除	`df[df['sku_id'].str.contains('TEST', na=False)]`	在清洗阶段增加测试订单过滤规则
8	`rolling`报错"index must be monotonic"	订单时间有乱序（后下单时间戳更早）	`df['order_date'].is_monotonic_increasing`	加`df = df.sort_values('order_date')`，但注意性能影响
9	导出Excel内存溢出	试图导出全部原始数据（500万行）	`df.shape`	严格限制“原始数据”Sheet只导出当前窗口数据
10	时区警告"Non-timezone-aware datetime"	`to_datetime`未指定`utc=True`或`tz_localize`	`df['order_date'].dt.tz`	统一用`tz_localize('Asia/Shanghai')`
11	某天销量数据缺失	ETL任务失败，当天数据未同步	`df['order_date'].dt.date.value_counts().sort_index()`	加入数据覆盖检查，覆盖率<95%时告警
12	TOP10商品排名与业务方手工统计不一致	业务方按“支付成功时间”统计，脚本按“下单时间”	对比两套时间字段的分布	明确业务口径，在清洗阶段统一时间基准

5.2 一个经典故障的完整复盘：双休日销量“消失”事件

现象：连续两个周六，近7天销量报表中“周六销量”一栏为空，但订单库确认有数据。

排查过程：

第一步，检查时间窗口：tw.get_window(7)返回2024-04-28 00:00:00 ~ 2024-05-04 23:59:59，覆盖了4月28日（周六）；
第二步，检查数据：df_clean[df_clean['order_date'].dt.date == pd.Timestamp('2024-04-28').date()]返回空；
第三步，深挖时间列：df_clean['order_date'].head()显示时间戳为2024-04-28 00:00:00+00:00，时区是UTC！
根本原因：上游数据源（某第三方API）返回的是UTC时间，但清洗时只做了to_datetime，没做tz_localize，导致2024-04-28 00:00:00+00:00被当成东八区的2024-04-28 08:00:00，超出了窗口。

解决方案：

立即修复清洗函数：df['order_date'] = pd.to_datetime(...).dt.tz_localize('UTC').dt.tz_convert('Asia/Shanghai')；
补跑历史数据；
在数据接入层增加时区校验告警。

这个故障教会我：永远不要假设上游数据的时区，每个时间字段都必须显式声明和转换。

5.3 生产环境必备的监控与告警清单

为避免救火式运维，我们建立了以下轻量级监控：

每日自动校验：脚本运行后，自动发送邮件给数据负责人，包含：
- 各窗口销量数值
- 数据覆盖率（实际天数/应有天数）
- 异常订单数（金额>5万、状态为unknown）
- 与昨日同比变化率（>±30%触发预警）
关键指标看板：用Grafana搭一个极简看板，只监控：
- sales_last7_days（数值）
- data_coverage_last30（百分比）
- error_rate（清洗阶段错误率）
日志分级：
- INFO：正常运行，销量数值；
- WARNING：覆盖率<95%、同比变化>±20%；
- ERROR：时间窗口异常、数据为空、金额为NaN。