简介这份Python实例源码面向具备一定编程基础、希望入门数据分析与自动化处理的开发者围绕客流高峰提示这一具体场景演示如何从原始数据中识别日间与星期维度的流量峰值为商业决策或模拟类项目提供参考。压缩包共3个文件包含2个py脚本与1份doc说明文档整体约90KB其中脚本分别对应电信营业厅周业务分析与工商银行日间客流高峰提示牌两个实现案例文档则用于说明源程序的使用方式。内容涉及Pandas数据清洗与聚合、NumPy数值计算、时间序列处理、Matplotlib或Seaborn可视化以及基于条件逻辑的高峰触发提示并延伸至文件读写、自动化脚本与网络爬虫等常见技术点。已有140人学习适合作为数据分析入门练手素材帮助读者理解从数据读取到高峰判断的完整链路并迁移到其他统计类任务中。1. 从一份客流提示源码说起日间与星期高峰到底怎么算工作日中午十二点门店 POS 流水突然翻倍周六下午三点同一家店又冲出一个更高的峰。这两个峰长得像成因却完全不同——一个是「日间时段高峰」一个是「星期维度高峰」。很多刚接触 Python 数据分析的朋友拿到一份客流数据第一反应是画条折线看趋势结果两条曲线叠在一起根本分不清哪个是午市、哪个是周末效应。这份「核心基础-实现日间、星期客流高峰提示-Python实例源码」要解决的就是把这两种高峰拆开、量化并在数据超过阈值时给出提示。它适合三类人正在做零售/餐饮/门店运营数据分析的从业者想找一个完整 Python 实例练手的入门者以及需要把高峰识别嵌进自己系统里的开发者。核心逻辑不复杂——按小时聚合算日间分布按星期聚合算周分布再用统计阈值判定「高峰」。但真正落地时阈值怎么定、数据怎么清洗、提示怎么触发每一步都有讲究。下面顺着源码思路把这件事从头做一遍。2. 拆解高峰提示的底层逻辑小时分布与星期分布怎么分开算2.1 为什么不能只用一条折线看客流客流数据本质是带时间戳的离散事件流每条记录代表一次进店或一笔交易。如果直接按时间顺序画折线你看到的是「时间序列」它同时混入了三种成分日内节律早中晚的起伏、周节律工作日与周末的差异、以及随机波动天气、促销、突发事件。这三种成分叠在一起折线会非常毛糙肉眼很难判断某个尖峰到底是「每天中午都这样」还是「只有周六这样」。正确的做法是做两次独立聚合。第一次按「小时」聚合把所有日期的同一小时数据加总或求均值得到 24 个小时的日间分布曲线第二次按「星期几」聚合得到 7 个点的周分布曲线。两条曲线各自回答一个问题一天里哪个时段最忙一周里哪天最忙只有分开算才能分别设定阈值、分别触发提示。这里有个容易翻车的点聚合时用「总和」还是「均值」结果差别很大。如果各天营业时长不一致用总和会让营业时间长的星期几虚高。常见做法是先按「日期小时」求当小时客流再对同一小时跨日期求均值这样每个小时的值代表「平均而言这个小时有多少客流」量纲统一后续阈值才好定。2.2 用 pandas 做两次 groupby 的最小代码下面这段代码假设你有一份 CSV字段是timestamp时间戳和count客流数。先读入、解析时间、派生小时和星期字段再做两次聚合。import pandas as pd # 读入客流数据parse_dates 直接把 timestamp 列解析成 datetime df pd.read_csv(traffic.csv, parse_dates[timestamp]) # 派生两个关键维度小时0-23和星期0周一6周日 df[hour] df[timestamp].dt.hour df[weekday] df[timestamp].dt.weekday # 第一次聚合按小时求平均客流得到日间分布 hour_profile df.groupby(hour)[count].mean().reindex(range(24), fill_value0) # 第二次聚合按星期求平均客流得到周分布 week_profile df.groupby(weekday)[count].mean().reindex(range(7), fill_value0) print(hour_profile) print(week_profile)逻辑说明dt.hour和dt.weekday是 pandas 从 datetime 列直接提取的不需要手写循环。reindex(range(24))的作用是补齐缺失的小时——如果某个小时从来没有数据groupby 会直接跳过它导致索引不连续后面画图和取阈值都会错位。fill_value0把缺失小时填成 0保证输出永远是 24 个值。参数说明groupby(hour)[count].mean()里的mean可以换成sum但如前所述除非每天营业时长完全一致否则建议用mean。如果你的数据是「每 15 分钟一条」需要先把时间戳向下取整到小时再聚合否则小时维度会碎掉。2.3 高峰判定的三种阈值策略算出分布曲线后下一步是判定「哪里算高峰」。源码里通常不会只用一个固定数字而是给几种策略让使用者选策略判定规则适用场景注意点均值倍数法客流 全局均值 × k数据平稳、无明显趋势k 一般取 1.52.0k 太小会频繁误报分位数法客流 75% 或 90% 分位数数据偏态、有长尾分位数不受极端值影响更稳健均值标准差客流 均值 n×标准差近似正态分布n 取 1 或 2数据波动大时慎用我一般会先用分位数法跑一遍因为客流数据几乎都是右偏的——大部分时段客流低少数时段极高均值和标准差会被极端值拉偏。用 75% 分位数做「高峰线」90% 分位数做「严重高峰线」两级提示运营侧更容易接受。# 用分位数法标记日间高峰 q75 hour_profile.quantile(0.75) q90 hour_profile.quantile(0.90) hour_peak hour_profile[hour_profile q75] hour_severe hour_profile[hour_profile q90] print(日间高峰时段:, list(hour_peak.index)) print(严重高峰时段:, list(hour_severe.index))这段代码输出的是小时索引列表比如[11, 12, 17, 18]直接对应上午 11 点到 12 点、下午 5 点到 6 点两个高峰段。拿到这个列表就可以在业务系统里做提示了。3. 把源码跑起来环境配置、数据准备与提示触发3.1 从零配好 Python 环境并装齐依赖如果你还没装 Python去官网下载安装包时记得勾选「Add Python to PATH」否则命令行里敲python会提示找不到命令。装完后验证python --version pip --version如果用的是 VS Code装好 Python 扩展后按CtrlShiftP输入「Python: Select Interpreter」选中你刚装的解释器。PyCharm 用户则在 Settings 里配置 Project Interpreter。这一步不做后面 import pandas 会直接报 ModuleNotFoundError。依赖只有三个一条命令搞定pip install pandas matplotlibpandas 负责数据处理matplotlib 负责把分布曲线画出来。如果你还想做可视化界面可以额外装 streamlit但核心逻辑不需要它。3.2 数据格式要求与清洗脚本源码对输入数据有隐含要求必须有一列时间戳、一列数值。常见的数据来源是 POS 导出、闸机计数、Wi-Fi 探针统计。不管来源是什么先统一成两列 CSV。import pandas as pd # 假设原始数据有三列日期、时间、进店人数 raw pd.read_csv(raw_traffic.csv) # 合并日期和时间成单个 timestamp raw[timestamp] pd.to_datetime(raw[日期].astype(str) raw[时间].astype(str)) # 只保留需要的两列重命名 df raw[[timestamp, 进店人数]].rename(columns{进店人数: count}) # 去掉 count 为空或负数的脏数据 df df.dropna(subset[count]) df df[df[count] 0] df.to_csv(traffic.csv, indexFalse)逻辑说明pd.to_datetime把字符串拼成标准时间格式这是后续dt.hour能工作的前提。dropna和 0过滤是血泪经验——真实数据里经常有设备离线导致的空值或者退店计数产生的负数不清掉会让均值失真。参数说明如果你的时间列已经是标准格式跳过拼接那一步。如果数据量很大百万行以上pd.to_datetime会慢可以加format%Y-%m-%d %H:%M:%S指定格式速度能快好几倍。3.3 生成提示信息的完整流程把前面的聚合和判定串起来再加一个「提示生成」函数就是一份可用的最小系统。def generate_peak_alert(df, q0.75): df[hour] df[timestamp].dt.hour df[weekday] df[timestamp].dt.weekday hour_profile df.groupby(hour)[count].mean().reindex(range(24), fill_value0) week_profile df.groupby(weekday)[count].mean().reindex(range(7), fill_value0) hour_threshold hour_profile.quantile(q) week_threshold week_profile.quantile(q) hour_peaks list(hour_profile[hour_profile hour_threshold].index) week_peaks list(week_profile[week_profile week_threshold].index) weekday_names [周一, 周二, 周三, 周四, 周五, 周六, 周日] week_peak_names [weekday_names[i] for i in week_peaks] return { 日间高峰时段: [f{h}:00 for h in hour_peaks], 星期高峰日: week_peak_names } alert generate_peak_alert(df) print(alert)逻辑说明函数返回一个字典包含两个列表。日间高峰用小时表示星期高峰用中文星期名表示方便直接展示给运营人员。q参数控制分位数默认 0.75想更敏感就调到 0.7想更保守就调到 0.8。参数说明weekday_names的索引顺序必须和dt.weekday一致——pandas 里 0 是周一6 是周日别搞反。如果业务上习惯把周日当第一天需要手动做映射偏移。4. 避坑与排查客流高峰提示最常见的 5 个翻车点4.1 现象高峰时段算出来是凌晨 3 点原因时间戳时区不对。很多 POS 系统导出的是 UTC 时间直接解析后dt.hour拿到的是 UTC 小时比北京时间晚 8 小时。凌晨 3 点其实是上午 11 点。解决解析后统一加 8 小时或者用pd.to_datetime(..., utcTrue).dt.tz_convert(Asia/Shanghai)。先确认数据源时区再决定怎么转。4.2 现象星期分布里周六周日特别高但实际门店周末不营业原因数据里混入了非营业日记录或者某些日期的数据被重复导入。groupby 求均值时如果周末只有一两天数据且恰好是促销日均值会被拉高。解决先按日期统计每天的总客流画出日历热力图肉眼排查异常日期。对明显异常的日子做剔除或者在聚合前加一个「有效营业日」过滤条件。4.3 现象阈值调来调去提示要么不触发要么一直触发原因用了固定阈值但客流有季节性。旺季整体客流高固定阈值一直触发淡季整体低永远不触发。解决改用相对阈值也就是分位数法或均值倍数法。分位数法天然自适应——不管整体客流高低它总是取前 25% 作为高峰。这也是我推荐分位数法的核心原因。4.4 现象代码在本地跑得好好的换台机器就报 KeyError原因列名不一致。源码里写死了count但你的 CSV 里叫客流或visitors。pandas 不会自动匹配。解决在读入后立刻做列名标准化或者把列名作为参数传进函数。别在代码里硬编码中文列名跨平台容易出编码问题。4.5 现象数据量大了之后 groupby 特别慢原因每次调用都重新解析时间戳、重新派生字段。如果数据是流式追加的重复计算浪费严重。解决把时间解析和字段派生做成预处理步骤结果存成 parquet 格式。后续聚合直接读 parquet速度能快一个数量级。另外groupby之前先df df[[hour, weekday, count]]只保留需要的列减少内存占用。5. 进阶把高峰提示做成可复用的分析模块5.1 用配置文件管理阈值和提示规则硬编码阈值是后期维护的噩梦。把策略抽成配置改参数不用动代码import json config { threshold_method: quantile, quantile: 0.75, severe_quantile: 0.90, weekday_names: [周一, 周二, 周三, 周四, 周五, 周六, 周日] } with open(peak_config.json, w, encodingutf-8) as f: json.dump(config, f, ensure_asciiFalse, indent2)然后在主函数里读这个 JSON根据threshold_method分支走不同判定逻辑。这样运营侧想调敏感度改 JSON 就行不需要开发介入。5.2 验证高峰判定是否合理回测与人工核对算出高峰时段后别直接上线。拿过去一个月的真实数据做回测把每天实际客流曲线和判定出的高峰时段叠在一起画图人工看几个典型日子。如果某个明显的高峰没被识别出来说明阈值偏高如果平峰时段被误标说明阈值偏低。import matplotlib.pyplot as plt fig, axes plt.subplots(1, 2, figsize(12, 4)) axes[0].bar(hour_profile.index, hour_profile.values) axes[0].axhline(hour_profile.quantile(0.75), colorr, linestyle--, label高峰线) axes[0].set_title(日间分布) axes[0].legend() axes[1].bar(week_profile.index, week_profile.values) axes[1].axhline(week_profile.quantile(0.75), colorr, linestyle--, label高峰线) axes[1].set_title(星期分布) axes[1].legend() plt.tight_layout() plt.savefig(peak_check.png, dpi150)这张图是给业务方看的比任何文字说明都直观。红色虚线就是阈值线超过它的柱子就是高峰。如果业务方说「这个不对」直接对着图调分位数一轮就能对齐预期。5.3 一个我踩过的坑别忽略「零客流」时段早期做这个模块时我把没有数据的小时直接丢掉了结果reindex补 0 之后那些本该是零客流的凌晨时段被算进了均值把整体均值拉低导致高峰线偏低、误报增多。后来改成先确认门店营业时间只对营业时段做聚合和判定非营业时段直接排除。这个改动让误报率降了一半以上。做数据分析清洗和边界处理永远比算法本身花时间。这份源码给的是一个骨架真正让它在你自己的数据上跑出可信结果靠的是对业务节奏的理解和对脏数据的耐心。希望帮到你。本文还有配套的精品资源点击获取 Python数据分析：日间与星期客流高峰识别与提示源码实战
简介这份Python实例源码面向具备一定编程基础、希望入门数据分析与自动化处理的开发者围绕客流高峰提示这一具体场景演示如何从原始数据中识别日间与星期维度的流量峰值为商业决策或模拟类项目提供参考。压缩包共3个文件包含2个py脚本与1份doc说明文档整体约90KB其中脚本分别对应电信营业厅周业务分析与工商银行日间客流高峰提示牌两个实现案例文档则用于说明源程序的使用方式。内容涉及Pandas数据清洗与聚合、NumPy数值计算、时间序列处理、Matplotlib或Seaborn可视化以及基于条件逻辑的高峰触发提示并延伸至文件读写、自动化脚本与网络爬虫等常见技术点。已有140人学习适合作为数据分析入门练手素材帮助读者理解从数据读取到高峰判断的完整链路并迁移到其他统计类任务中。1. 从一份客流提示源码说起日间与星期高峰到底怎么算工作日中午十二点门店 POS 流水突然翻倍周六下午三点同一家店又冲出一个更高的峰。这两个峰长得像成因却完全不同——一个是「日间时段高峰」一个是「星期维度高峰」。很多刚接触 Python 数据分析的朋友拿到一份客流数据第一反应是画条折线看趋势结果两条曲线叠在一起根本分不清哪个是午市、哪个是周末效应。这份「核心基础-实现日间、星期客流高峰提示-Python实例源码」要解决的就是把这两种高峰拆开、量化并在数据超过阈值时给出提示。它适合三类人正在做零售/餐饮/门店运营数据分析的从业者想找一个完整 Python 实例练手的入门者以及需要把高峰识别嵌进自己系统里的开发者。核心逻辑不复杂——按小时聚合算日间分布按星期聚合算周分布再用统计阈值判定「高峰」。但真正落地时阈值怎么定、数据怎么清洗、提示怎么触发每一步都有讲究。下面顺着源码思路把这件事从头做一遍。2. 拆解高峰提示的底层逻辑小时分布与星期分布怎么分开算2.1 为什么不能只用一条折线看客流客流数据本质是带时间戳的离散事件流每条记录代表一次进店或一笔交易。如果直接按时间顺序画折线你看到的是「时间序列」它同时混入了三种成分日内节律早中晚的起伏、周节律工作日与周末的差异、以及随机波动天气、促销、突发事件。这三种成分叠在一起折线会非常毛糙肉眼很难判断某个尖峰到底是「每天中午都这样」还是「只有周六这样」。正确的做法是做两次独立聚合。第一次按「小时」聚合把所有日期的同一小时数据加总或求均值得到 24 个小时的日间分布曲线第二次按「星期几」聚合得到 7 个点的周分布曲线。两条曲线各自回答一个问题一天里哪个时段最忙一周里哪天最忙只有分开算才能分别设定阈值、分别触发提示。这里有个容易翻车的点聚合时用「总和」还是「均值」结果差别很大。如果各天营业时长不一致用总和会让营业时间长的星期几虚高。常见做法是先按「日期小时」求当小时客流再对同一小时跨日期求均值这样每个小时的值代表「平均而言这个小时有多少客流」量纲统一后续阈值才好定。2.2 用 pandas 做两次 groupby 的最小代码下面这段代码假设你有一份 CSV字段是timestamp时间戳和count客流数。先读入、解析时间、派生小时和星期字段再做两次聚合。import pandas as pd # 读入客流数据parse_dates 直接把 timestamp 列解析成 datetime df pd.read_csv(traffic.csv, parse_dates[timestamp]) # 派生两个关键维度小时0-23和星期0周一6周日 df[hour] df[timestamp].dt.hour df[weekday] df[timestamp].dt.weekday # 第一次聚合按小时求平均客流得到日间分布 hour_profile df.groupby(hour)[count].mean().reindex(range(24), fill_value0) # 第二次聚合按星期求平均客流得到周分布 week_profile df.groupby(weekday)[count].mean().reindex(range(7), fill_value0) print(hour_profile) print(week_profile)逻辑说明dt.hour和dt.weekday是 pandas 从 datetime 列直接提取的不需要手写循环。reindex(range(24))的作用是补齐缺失的小时——如果某个小时从来没有数据groupby 会直接跳过它导致索引不连续后面画图和取阈值都会错位。fill_value0把缺失小时填成 0保证输出永远是 24 个值。参数说明groupby(hour)[count].mean()里的mean可以换成sum但如前所述除非每天营业时长完全一致否则建议用mean。如果你的数据是「每 15 分钟一条」需要先把时间戳向下取整到小时再聚合否则小时维度会碎掉。2.3 高峰判定的三种阈值策略算出分布曲线后下一步是判定「哪里算高峰」。源码里通常不会只用一个固定数字而是给几种策略让使用者选策略判定规则适用场景注意点均值倍数法客流 全局均值 × k数据平稳、无明显趋势k 一般取 1.52.0k 太小会频繁误报分位数法客流 75% 或 90% 分位数数据偏态、有长尾分位数不受极端值影响更稳健均值标准差客流 均值 n×标准差近似正态分布n 取 1 或 2数据波动大时慎用我一般会先用分位数法跑一遍因为客流数据几乎都是右偏的——大部分时段客流低少数时段极高均值和标准差会被极端值拉偏。用 75% 分位数做「高峰线」90% 分位数做「严重高峰线」两级提示运营侧更容易接受。# 用分位数法标记日间高峰 q75 hour_profile.quantile(0.75) q90 hour_profile.quantile(0.90) hour_peak hour_profile[hour_profile q75] hour_severe hour_profile[hour_profile q90] print(日间高峰时段:, list(hour_peak.index)) print(严重高峰时段:, list(hour_severe.index))这段代码输出的是小时索引列表比如[11, 12, 17, 18]直接对应上午 11 点到 12 点、下午 5 点到 6 点两个高峰段。拿到这个列表就可以在业务系统里做提示了。3. 把源码跑起来环境配置、数据准备与提示触发3.1 从零配好 Python 环境并装齐依赖如果你还没装 Python去官网下载安装包时记得勾选「Add Python to PATH」否则命令行里敲python会提示找不到命令。装完后验证python --version pip --version如果用的是 VS Code装好 Python 扩展后按CtrlShiftP输入「Python: Select Interpreter」选中你刚装的解释器。PyCharm 用户则在 Settings 里配置 Project Interpreter。这一步不做后面 import pandas 会直接报 ModuleNotFoundError。依赖只有三个一条命令搞定pip install pandas matplotlibpandas 负责数据处理matplotlib 负责把分布曲线画出来。如果你还想做可视化界面可以额外装 streamlit但核心逻辑不需要它。3.2 数据格式要求与清洗脚本源码对输入数据有隐含要求必须有一列时间戳、一列数值。常见的数据来源是 POS 导出、闸机计数、Wi-Fi 探针统计。不管来源是什么先统一成两列 CSV。import pandas as pd # 假设原始数据有三列日期、时间、进店人数 raw pd.read_csv(raw_traffic.csv) # 合并日期和时间成单个 timestamp raw[timestamp] pd.to_datetime(raw[日期].astype(str) raw[时间].astype(str)) # 只保留需要的两列重命名 df raw[[timestamp, 进店人数]].rename(columns{进店人数: count}) # 去掉 count 为空或负数的脏数据 df df.dropna(subset[count]) df df[df[count] 0] df.to_csv(traffic.csv, indexFalse)逻辑说明pd.to_datetime把字符串拼成标准时间格式这是后续dt.hour能工作的前提。dropna和 0过滤是血泪经验——真实数据里经常有设备离线导致的空值或者退店计数产生的负数不清掉会让均值失真。参数说明如果你的时间列已经是标准格式跳过拼接那一步。如果数据量很大百万行以上pd.to_datetime会慢可以加format%Y-%m-%d %H:%M:%S指定格式速度能快好几倍。3.3 生成提示信息的完整流程把前面的聚合和判定串起来再加一个「提示生成」函数就是一份可用的最小系统。def generate_peak_alert(df, q0.75): df[hour] df[timestamp].dt.hour df[weekday] df[timestamp].dt.weekday hour_profile df.groupby(hour)[count].mean().reindex(range(24), fill_value0) week_profile df.groupby(weekday)[count].mean().reindex(range(7), fill_value0) hour_threshold hour_profile.quantile(q) week_threshold week_profile.quantile(q) hour_peaks list(hour_profile[hour_profile hour_threshold].index) week_peaks list(week_profile[week_profile week_threshold].index) weekday_names [周一, 周二, 周三, 周四, 周五, 周六, 周日] week_peak_names [weekday_names[i] for i in week_peaks] return { 日间高峰时段: [f{h}:00 for h in hour_peaks], 星期高峰日: week_peak_names } alert generate_peak_alert(df) print(alert)逻辑说明函数返回一个字典包含两个列表。日间高峰用小时表示星期高峰用中文星期名表示方便直接展示给运营人员。q参数控制分位数默认 0.75想更敏感就调到 0.7想更保守就调到 0.8。参数说明weekday_names的索引顺序必须和dt.weekday一致——pandas 里 0 是周一6 是周日别搞反。如果业务上习惯把周日当第一天需要手动做映射偏移。4. 避坑与排查客流高峰提示最常见的 5 个翻车点4.1 现象高峰时段算出来是凌晨 3 点原因时间戳时区不对。很多 POS 系统导出的是 UTC 时间直接解析后dt.hour拿到的是 UTC 小时比北京时间晚 8 小时。凌晨 3 点其实是上午 11 点。解决解析后统一加 8 小时或者用pd.to_datetime(..., utcTrue).dt.tz_convert(Asia/Shanghai)。先确认数据源时区再决定怎么转。4.2 现象星期分布里周六周日特别高但实际门店周末不营业原因数据里混入了非营业日记录或者某些日期的数据被重复导入。groupby 求均值时如果周末只有一两天数据且恰好是促销日均值会被拉高。解决先按日期统计每天的总客流画出日历热力图肉眼排查异常日期。对明显异常的日子做剔除或者在聚合前加一个「有效营业日」过滤条件。4.3 现象阈值调来调去提示要么不触发要么一直触发原因用了固定阈值但客流有季节性。旺季整体客流高固定阈值一直触发淡季整体低永远不触发。解决改用相对阈值也就是分位数法或均值倍数法。分位数法天然自适应——不管整体客流高低它总是取前 25% 作为高峰。这也是我推荐分位数法的核心原因。4.4 现象代码在本地跑得好好的换台机器就报 KeyError原因列名不一致。源码里写死了count但你的 CSV 里叫客流或visitors。pandas 不会自动匹配。解决在读入后立刻做列名标准化或者把列名作为参数传进函数。别在代码里硬编码中文列名跨平台容易出编码问题。4.5 现象数据量大了之后 groupby 特别慢原因每次调用都重新解析时间戳、重新派生字段。如果数据是流式追加的重复计算浪费严重。解决把时间解析和字段派生做成预处理步骤结果存成 parquet 格式。后续聚合直接读 parquet速度能快一个数量级。另外groupby之前先df df[[hour, weekday, count]]只保留需要的列减少内存占用。5. 进阶把高峰提示做成可复用的分析模块5.1 用配置文件管理阈值和提示规则硬编码阈值是后期维护的噩梦。把策略抽成配置改参数不用动代码import json config { threshold_method: quantile, quantile: 0.75, severe_quantile: 0.90, weekday_names: [周一, 周二, 周三, 周四, 周五, 周六, 周日] } with open(peak_config.json, w, encodingutf-8) as f: json.dump(config, f, ensure_asciiFalse, indent2)然后在主函数里读这个 JSON根据threshold_method分支走不同判定逻辑。这样运营侧想调敏感度改 JSON 就行不需要开发介入。5.2 验证高峰判定是否合理回测与人工核对算出高峰时段后别直接上线。拿过去一个月的真实数据做回测把每天实际客流曲线和判定出的高峰时段叠在一起画图人工看几个典型日子。如果某个明显的高峰没被识别出来说明阈值偏高如果平峰时段被误标说明阈值偏低。import matplotlib.pyplot as plt fig, axes plt.subplots(1, 2, figsize(12, 4)) axes[0].bar(hour_profile.index, hour_profile.values) axes[0].axhline(hour_profile.quantile(0.75), colorr, linestyle--, label高峰线) axes[0].set_title(日间分布) axes[0].legend() axes[1].bar(week_profile.index, week_profile.values) axes[1].axhline(week_profile.quantile(0.75), colorr, linestyle--, label高峰线) axes[1].set_title(星期分布) axes[1].legend() plt.tight_layout() plt.savefig(peak_check.png, dpi150)这张图是给业务方看的比任何文字说明都直观。红色虚线就是阈值线超过它的柱子就是高峰。如果业务方说「这个不对」直接对着图调分位数一轮就能对齐预期。5.3 一个我踩过的坑别忽略「零客流」时段早期做这个模块时我把没有数据的小时直接丢掉了结果reindex补 0 之后那些本该是零客流的凌晨时段被算进了均值把整体均值拉低导致高峰线偏低、误报增多。后来改成先确认门店营业时间只对营业时段做聚合和判定非营业时段直接排除。这个改动让误报率降了一半以上。做数据分析清洗和边界处理永远比算法本身花时间。这份源码给的是一个骨架真正让它在你自己的数据上跑出可信结果靠的是对业务节奏的理解和对脏数据的耐心。希望帮到你。本文还有配套的精品资源点击获取