描述性统计实战指南：从df.describe()到业务诊断的完整链路

1. 这不是统计学课本，是数据科学现场的“望闻问切”手册

你刚拿到一份用户行为日志，237万行，字段名像密码：session_duration_ms、page_view_depth、cart_abandonment_flag。老板在 Slack 里敲出一句：“快看看用户到底怎么用我们 App 的？”——你盯着屏幕，手指悬在键盘上，心里清楚：此刻最不需要的，是一段df.describe()的默认输出，那堆 mean/std/min/25%/50%/75%/max 数字，像一排整齐却冰冷的墓碑，告诉你“有数据”，但没告诉你“发生了什么”。Descriptive Statistics（描述性统计），在数据科学的真实战场里，从来不是期末考试的填空题，而是你第一次走进客户会议室时，手里那支能画出故事轮廓的铅笔。它不预测明天会不会下雨，但它能告诉你过去三个月哪天的雨滴最密集、哪片云层最厚、哪条街道积水最深——所有决策的起点，都藏在这份“数据体检报告”里。我带过十几支数据团队，见过太多人把describe()当成终点：跑完就截图发邮件，标题写着“初步分析完成”。结果呢？业务方回一句“所以呢？”，工程师默默关掉 Jupyter Notebook。真正的描述性统计，是带着问题去解剖数据：这个分布是不是歪着长的？那个峰值背后有没有隐藏的用户分群？这个标准差大得离谱，是噪声，还是某个关键环节正在崩塌？它要求你左手握着pandas，右手拿着业务流程图，在数字和现实之间反复校准。这篇文章，就是我把十年里踩过的坑、调过的参、画过的 372 张直方图、被业务方追问到哑口无言又突然开窍的瞬间，全盘托出。没有抽象理论，只有你明天早上打开数据集就能用上的判断逻辑、可视化组合拳、以及那些教科书绝不会写的“当均值失效时，你该信谁”的实操心法。

2. 描述性统计不是“计算”，是“诊断”：从方案设计到核心逻辑拆解

2.1 为什么不能只用df.describe()？——一场关于“代表性”的信任危机

新手最容易犯的错，就是把pandas.DataFrame.describe()当成万能钥匙。它确实快，三秒输出八行数字。但问题在于：这八行数字，是在假设你的数据服从正态分布的前提下，为你挑选的“最体面”的代表。可现实中的数据，几乎从不守规矩。我去年帮一家电商公司分析“用户下单到收货的时长”，describe()显示中位数是 3.2 天，均值是 5.8 天。乍看之下，均值更大，说明整体偏慢。但当你画出分布图，真相是：75% 的订单在 4 天内送达（所以中位数 3.2 天很稳），而剩下的 25%，有一小撮订单卡在海关、物流中转站，最长拖了 67 天——这 67 天，像一颗巨石，把均值硬生生拉高了 2.6 天。此时，如果你向运营总监汇报“平均要 5.8 天”，他可能立刻拍板加急物流预算；但如果你说“四分之三的订单 4 天内到，但有 3% 的订单超 30 天，集中在北美清关环节”，他马上会调出清关流水线的 SOP，精准堵漏。均值在这里失效，不是因为它算错了，而是因为它被异常值绑架了。这就是描述性统计的第一重逻辑：永远先问分布形态，再选代表指标。正态分布？均值、标准差是黄金搭档。右偏分布（长尾在右，如收入、响应时间）？中位数、四分位距（IQR）才是你的锚点。左偏？同理。而describe()默认塞给你的均值和 std，恰恰在非正态场景下，最容易给出误导性结论。我现在的做法是：describe()只作为第一眼扫描，真正下结论前，必做三件事：画直方图+核密度估计（KDE）、算偏度（Skewness）和峰度（Kurtosis）、手动检查 IQR 和极值比例。这多花的 90 秒，能避免后续三天的返工。

2.2 核心指标的“军种分工”：何时用均值，何时信中位数，何时必须看分位数？

描述性统计的指标，不是并列的同事，而是各司其职的特种兵。理解它们的“作战半径”，比死记公式重要十倍。

• 均值（Mean）：它的本质是“数据重心”。想象一条均匀的木板，上面放着所有数据点，均值就是木板能水平平衡的那个支点。它的强项是对称、紧凑、无极端异常值的数据——比如某工厂同一台机器连续生产的 1000 个零件直径，误差在 ±0.02mm 内。此时均值最能代表“典型值”。但它的致命弱点是对异常值极度敏感。一个 100 万的订单混进 99 个 1 万的订单里，均值会从 1 万跳到接近 1.01 万，失真 1%；而中位数纹丝不动，还是 1 万。所以，均值的使用前提，必须是经过分布检验（如 Shapiro-Wilk 检验 p>0.05）或业务确认“异常值属于合理业务现象，且需被同等权重计入平均表现”。

• 中位数（Median）：它是数据排序后的“中间哨兵”。无论左边是 100 个 1，还是右边是 100 个 1000，只要中间那个数是 50，中位数就是 50。它的价值在于鲁棒性（Robustness）——对异常值免疫。在用户行为分析中，我几乎总是先看中位数。比如“单次会话页面浏览数”，均值可能是 8.3，但中位数是 4。这意味着超过一半的用户，一次只看 4 页或更少。这个数字，比均值更能指导产品优化：是首页信息架构太复杂？还是搜索功能不够好？让新用户快速找到目标，比服务那 10% 看 50 页的深度用户，ROI 高得多。

• 四分位距（IQR = Q3 - Q1）与分位数（Percentiles）：如果说均值和中位数是“点”，IQR 就是“区间”，分位数则是“刻度尺”。IQR 告诉你中间 50% 数据的“主战场”有多宽。Q1 是 25% 分位数，Q3 是 75% 分位数。一个经典案例：某 SaaS 公司的“月度活跃用户（MAU）增长率”。describe()显示 std=12.3%，看起来波动很大。但算出 IQR=3.5%（Q1=2.1%, Q3=5.6%），你立刻明白：绝大多数月份的增长率，其实稳定在 2%-6% 这个窄区间里；那几个 20%+ 的峰值，是来自大客户签约的偶然事件，不应纳入常规运营节奏。此时，用 IQR 判断稳定性，远比 std 有效。而分位数，尤其是 95%、99% 分位数，则是 SLA（服务等级协议）的命脉。比如“API 响应时间”，合同承诺 95% 的请求 < 200ms。你必须直接查df['response_time'].quantile(0.95)，而不是看均值。因为均值达标（比如 150ms），但 95% 分位数是 250ms，意味着每 20 个请求就有 1 个超时，客户投诉必然爆发。

2.3 方案设计的底层逻辑：从“计算什么”到“为什么这样计算”

一个合格的描述性统计方案，必须回答三个灵魂问题：What（计算什么）、Why（为什么是它）、How（怎么验证它没骗你）。我给自己团队定的铁律是：任何描述性统计报告，必须包含一张“指标选择依据表”，哪怕只是内部草稿。

这张表不是形式主义。去年我们分析“客服通话时长”，初始describe()显示均值 8.2 分钟，std 12.5 分钟，看起来波动巨大。按表查：Skewness=4.7（严重右偏），Kurtosis=28.3（极端重尾）。立刻转向中位数（4.1 分钟）和 IQR（2.8-6.5 分钟），并画出箱线图——果然，95% 的通话在 2-7 分钟，但有 2% 的通话超 30 分钟，全是处理复杂退款纠纷。于是，我们把“30 分钟以上通话”单独建模，最终提炼出一套自动识别高危退款风险的话术提示系统，客服一次解决率提升 37%。你看，指标选择，直接决定了你看到的是“噪音”，还是“信号”。

3. 核心细节解析与实操要点：从数据加载到洞察生成的完整链路

3.1 数据加载与预处理：别让脏数据毁掉整个诊断

描述性统计的基石，是干净、结构清晰的数据。我见过太多人跳过这一步，直接pd.read_csv()就开干，结果后面所有分析都是沙上筑塔。真实世界的数据，就像刚从菜市场买回来的青菜，带着泥、夹着黄叶、还可能混进一根葱。预处理不是可选项，是生死线。

第一步：识别并处理缺失值（Missing Values）
缺失值不是“空”，而是“未观测到的信息”。不同场景，处理逻辑天壤之别。

• 数值型字段（如age,income）：绝不能简单用 0 或均值填充！比如income缺失，填 0 意味着“零收入”，这会彻底扭曲收入分布，让中位数下移。我的标准动作是：

  1. 计算缺失率：df['income'].isnull().mean()；
  2. 若缺失率 < 5%，用中位数填充（因中位数对异常值鲁棒，且更符合“典型值”预期）；
  3. 若缺失率 5%-30%，创建新特征income_missing_flag = 1，并用多重插补（Multiple Imputation），如sklearn.experimental.enable_iterative_imputer；
  4. 若缺失率 > 30%，直接删除该字段，或深入业务溯源——为什么这么多人不填收入？是问卷设计缺陷？还是隐私顾虑？这本身就是一个关键业务洞察。

• 分类字段（如user_segment,device_type）：缺失值往往代表“未知”或“未定义”。此时，填充Unknown或Other是安全的，但必须在后续分析中，将Unknown单独列为一个类别进行统计，观察其占比和行为特征。曾有一个项目，user_segment缺失率 18%，我们将其设为Unknown后发现：Unknown用户的付费转化率是Premium用户的 2.3 倍——原来，这是销售团队未打标签的高潜力客户池！

第二步：识别并处理异常值（Outliers）
异常值不是“错误”，而是“需要解释的故事”。盲目删除，等于抹杀关键线索。我的流程是“三阶排查法”：

1. 技术异常：明显录入错误，如age = 200,order_amount = -500。用业务规则硬过滤：df = df[(df['age'] >= 0) & (df['age'] <= 120) & (df['order_amount'] > 0)]；
2. 统计异常：基于 IQR 或 Z-score 标识。我偏好 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; outliers = df[(df['amount'] < lower_bound) | (df['amount'] > upper_bound)]；
3. 业务异常：这才是重点！对第二步找出的outliers，必须人工抽样检查。比如order_amount > $10,000的订单，是企业采购？还是黑产刷单？或是 VIP 客户的年度囤货？我要求团队对每个异常值样本，记录三要素：业务背景、发生原因、是否应保留。去年一个金融项目，transaction_amount异常值中，83% 是跨境大额汇款，这直接推动了反洗钱模型的迭代。记住：描述性统计的终极目标，不是得到一组“干净”的数字，而是理解数据为何如此“不干净”。

3.2 可视化组合拳：让数字自己开口说话

数字是沉默的，图表是它的扩音器。但一张好图，不是炫技，而是精准传递一个信息。我坚持“一图一洞见”原则，拒绝信息过载的“大杂烩图”。

• 直方图（Histogram） + 核密度估计（KDE）：这是诊断分布形态的“听诊器”。直方图显示频次，KDE 显示平滑的概率密度曲线。关键参数：bins的数量。太少（如 5 个 bins），掩盖细节；太多（如 100 个 bins），全是噪点。我的经验公式：bins = int(np.sqrt(len(df)))，然后根据图形微调。例如，分析session_duration_sec，len(df)=1e6，则bins ≈ 1000，但实际用 50-80 更清晰。代码：

import matplotlib.pyplot as plt import seaborn as sns plt.figure(figsize=(10, 6)) sns.histplot(df['session_duration_sec'], bins=60, kde=True, stat="density", alpha=0.6) plt.axvline(df['session_duration_sec'].median(), color='red', linestyle='--', label=f'Median: {df["session_duration_sec"].median():.0f}s') plt.axvline(df['session_duration_sec'].mean(), color='blue', linestyle='-.', label=f'Mean: {df["session_duration_sec"].mean():.0f}s') plt.xlabel('Session Duration (seconds)') plt.ylabel('Density') plt.title('Distribution of User Session Duration') plt.legend() plt.show()

这张图，一眼就能看出：中位数（红虚线）远左于均值（蓝点划线），分布严重右偏；KDE 曲线在右侧拖出长长的尾巴，证实了“少数用户超长会话”的猜想。

• 箱线图（Boxplot）：这是展示 IQR 和异常值的“X光片”。它把 Q1、中位数、Q3、IQR、箱须、离群点全部压缩在一条线上。特别适合多组对比。比如比较 iOS 和 Android 用户的app_crash_rate：

sns.boxplot(data=df, x='os', y='crash_rate', order=['iOS', 'Android']) plt.ylabel('Crash Rate (%)') plt.title('Crash Rate Distribution by OS') plt.show()

如果 iOS 的箱子（IQR）明显高于 Android，且中位数也更高，说明 iOS 用户整体崩溃体验更差，需优先排查 iOS 版本兼容性。注意：箱线图对样本量敏感，若某组数据少于 20 条，其 IQR 可能失真，此时改用小提琴图（Violin Plot）。

• 小提琴图（Violin Plot）：箱线图的升级版，它不仅显示 IQR，还显示整个分布的密度。sns.violinplot()的inner="quart"参数，会在小提琴内部画出箱线图的元素，一举两得。当你要比较多个组的分布形状（比如不同渠道用户的LTV），小提琴图是首选。

• 散点图矩阵（Pairplot）：当你要探索两个以上变量的关系时，sns.pairplot(df[['revenue', 'page_views', 'time_on_site']], kind="reg")能一次性生成所有两两组合的散点图，并叠加回归线。如果revenue和page_views的散点图呈现明显的正相关（点向上倾斜），而revenue和time_on_site却是分散的云状，那就暗示：用户看更多页面，比单纯停留更久，更能带来收入。这直接指导产品团队：优化页面导航，比增加停留时长的诱导弹窗，ROI 更高。

3.3 关键指标的计算与解读：超越describe()的深度挖掘

describe()只给你基础七项，但真实业务需要更锋利的刀。

• 计算偏度（Skewness）与峰度（Kurtosis）：

from scipy.stats import skew, kurtosis print(f"Skewness: {skew(df['order_amount']):.3f}") # >1 右偏，<-1 左偏 print(f"Kurtosis: {kurtosis(df['order_amount']):.3f}") # >3 尖峰（重尾），<3 平峰

解读：Skewness=3.2不是“有点偏”，而是“严重右偏”，意味着均值被右侧长尾大幅拉高，此时中位数是唯一可信的集中趋势指标。Kurtosis=12.5表明存在极端重尾，必须检查尾部数据是否构成独立业务场景（如企业批发 vs 个人零售）。

• 分位数的业务化应用：
  不要只算 25%/50%/75%。业务语言是“Top 5%”、“Bottom 10%”。

# 计算 Top 5% 用户的平均消费 top_5pct_threshold = df['total_spend'].quantile(0.95) top_5pct_users = df[df['total_spend'] >= top_5pct_threshold] print(f"Top 5% users (spend >= ${top_5pct_threshold:.0f}) average spend: ${top_5pct_users['total_spend'].mean():.0f}") # 计算 Bottom 10% 用户的流失率 bottom_10pct_threshold = df['engagement_score'].quantile(0.10) bottom_10pct_users = df[df['engagement_score'] <= bottom_10pct_threshold] churn_rate_bottom_10pct = bottom_10pct_users['churned'].mean() print(f"Churn rate for bottom 10% engaged users: {churn_rate_bottom_10pct:.1%}")

这比笼统地说“高价值用户”或“低活跃用户”精准百倍。Top 5% 的平均消费，是制定 VIP 服务策略的基准；Bottom 10% 的流失率，是预警模型的关键阈值。

• 交叉描述性统计：维度穿透
  单一指标是平面，交叉分析才是立体。用pd.crosstab()和groupby().agg()打破维度壁垒。

# 用户分群（新/老）与设备（iOS/Android）的留存率交叉分析 retention_crosstab = pd.crosstab( df['user_type'], df['device'], values=df['retained_7d'], aggfunc='mean' ) print("7-Day Retention Rate by User Type and Device:") print(retention_crosstab.round(3)) # 计算各渠道（channel）的订单金额中位数和 IQR channel_stats = df.groupby('channel').agg({ 'order_amount': ['median', lambda x: x.quantile(0.75) - x.quantile(0.25)] }).round(2) channel_stats.columns = ['Median_Order_Amount', 'IQR_Order_Amount'] print("\nChannel Performance Summary:") print(channel_stats)

结果可能显示：New Users在Android上的 7 日留存率（0.28）远低于iOS（0.42），但Old Users却相反。这强烈暗示：Android 新用户获取渠道存在质量或引导问题，而 iOS 老用户可能更依赖 App 功能。这种交叉洞察，是单维度统计永远无法触及的。

4. 实操过程与核心环节实现：一个完整的电商用户行为分析实战

4.1 场景设定与数据概览：从混沌到结构

我们接手一个真实的电商数据集ecommerce_user_behavior.csv，包含 120 万行记录，核心字段：user_id,session_id,event_type（'view', 'add_to_cart', 'purchase'）,product_category,timestamp,device,country。业务问题：“如何提升整体购买转化率？哪个环节流失最严重？”

第一步：快速探查（Quick Peek）

import pandas as pd import numpy as np df = pd.read_csv('ecommerce_user_behavior.csv') print("Data Shape:", df.shape) print("\nFirst 5 rows:") print(df.head()) print("\nData Info:") print(df.info()) print("\nBasic Stats (describe):") print(df.describe(include='all'))

输出显示：event_type有 3 个唯一值，device有 2 个（'mobile', 'desktop'），country有 47 个，但country缺失率高达 22%。timestamp是 object 类型，需转换：df['timestamp'] = pd.to_datetime(df['timestamp'])。这一步，5 分钟内，我们已知道数据的“健康状况”和主要战场。

4.2 构建核心会话指标：从事件流到用户旅程

原始数据是离散事件，我们需要聚合成有意义的会话（Session）指标。这是描述性统计的“炼金术”。

• 定义会话（Session）：行业通用规则是：同一用户，两次事件间隔 > 30 分钟，视为新会话。

# 按 user_id 排序，计算相邻事件时间差 df = df.sort_values(['user_id', 'timestamp']) df['time_diff_min'] = df.groupby('user_id')['timestamp'].diff().dt.total_seconds() / 60 df['new_session_flag'] = (df['time_diff_min'] > 30) | (df['time_diff_min'].isna()) df['session_id_new'] = df.groupby('user_id')['new_session_flag'].cumsum() # 为每个会话计算关键指标 session_metrics = df.groupby('session_id_new').agg({ 'event_type': lambda x: (x == 'purchase').sum(), # purchase_count 'timestamp': ['min', 'max'], # session_start, session_end 'product_category': lambda x: x.nunique(), # unique_categories_viewed 'device': 'first', # device_used 'country': 'first' # country (using first non-null if possible) }).round(2) session_metrics.columns = ['purchase_count', 'session_start', 'session_end', 'unique_categories_viewed', 'device_used', 'country'] session_metrics['session_duration_min'] = (session_metrics['session_end'] - session_metrics['session_start']).dt.total_seconds() / 60 session_metrics = session_metrics.reset_index()

现在，我们有了 83 万条会话记录，每条代表一个用户的一次“购物之旅”。

4.3 核心描述性统计分析：层层剥茧，定位瓶颈

环节一：全局转化漏斗（Funnel Analysis）

# 计算各环节用户数 total_sessions = len(session_metrics) view_sessions = len(df[df['event_type'] == 'view']['session_id_new'].unique()) cart_sessions = len(df[df['event_type'] == 'add_to_cart']['session_id_new'].unique()) purchase_sessions = len(df[df['event_type'] == 'purchase']['session_id_new'].unique()) funnel_df = pd.DataFrame({ 'Stage': ['All Sessions', 'Viewed Product', 'Added to Cart', 'Purchased'], 'Count': [total_sessions, view_sessions, cart_sessions, purchase_sessions], 'Conversion_Rate': [1.0, view_sessions/total_sessions, cart_sessions/view_sessions, purchase_sessions/cart_sessions] }) print("Global Conversion Funnel:") print(funnel_df.round(3))

结果：All Sessions: 830,000→Viewed Product: 620,000 (74.7%)→Added to Cart: 155,000 (25.0%)→Purchased: 77,500 (50.0%)。
洞察：最大流失发生在“浏览到加购”环节（75% → 25%，流失 75%），而非“加购到购买”（25% → 50%，转化 50%）。优化重心应是提升加购率，而非支付成功率。

环节二：加购环节的深度诊断（Why 75% don't add to cart?）
聚焦view_sessions（62 万条），计算描述性统计：

# 对浏览会话，计算关键指标 view_sessions_df = session_metrics[session_metrics['session_id_new'].isin( df[df['event_type'] == 'view']['session_id_new'].unique() )] print("\nDescriptive Stats for View Sessions (n=620,000):") print(view_sessions_df['session_duration_min'].describe().round(2)) print(f"Skewness: {skew(view_sessions_df['session_duration_min']):.3f}") print(f"Median Duration: {view_sessions_df['session_duration_min'].median():.1f} min") # 绘制会话时长分布 plt.figure(figsize=(10, 6)) sns.histplot(view_sessions_df['session_duration_min'], bins=50, kde=True, stat="density", alpha=0.6) plt.axvline(view_sessions_df['session_duration_min'].median(), color='red', linestyle='--', label='Median') plt.xlabel('Session Duration (minutes)') plt.ylabel('Density') plt.title('Distribution of Session Duration for View-Only Sessions') plt.legend() plt.show()

结果：count=620000,mean=4.2,std=12.8,median=1.8,Skewness=5.1。分布严重右偏！中位数仅 1.8 分钟，意味着超过一半的浏览会话，用户只看了不到 2 分钟就离开了。这指向一个根本问题：首页或搜索结果页的吸引力不足，用户无法快速找到感兴趣的商品。而那 5% 超长会话（>15 分钟），很可能是用户在反复刷新、等待加载，或是页面卡顿导致的被动停留。

环节三：设备维度的交叉分析（Mobile vs Desktop）

# 按设备分组，计算加购率 device_funnel = df.groupby('device').agg({ 'event_type': lambda x: { 'view_count': (x == 'view').sum(), 'cart_count': (x == 'add_to_cart').sum(), 'purchase_count': (x == 'purchase').sum() } }).apply(lambda x: pd.Series(x['event_type'])) device_funnel['add_to_cart_rate'] = device_funnel['cart_count'] / device_funnel['view_count'] device_funnel['purchase_rate'] = device_funnel['purchase_count'] / device_funnel['cart_count'] print("\nFunnel by Device:") print(device_funnel.round(3))

结果：mobile:view_count=480,000,cart_count=96,000,add_to_cart_rate=0.20;desktop:view_count=140,000,cart_count=59,000,add_to_cart_rate=0.42。
洞察：移动端加购率（20%）远低于桌面端（42%），差距达 2.1 倍。问题根源极可能在移动端的加购按钮位置、点击热区大小、或加载速度。描述性统计在此刻，已从“数字”变成了“手术刀”，精准定位到具体平台和具体环节。

4.4 输出可执行洞察报告：从分析到行动

描述性统计的终点，不是一张漂亮的图，而是一份能让产品经理立刻打开 Figma 修改原型、让工程师立刻查看移动端网络请求日志的报告。我的标准报告结构：

1. 核心结论（Executive Summary）：一句话，用业务语言。

   “当前购买转化瓶颈在于移动端用户加购意愿低，75% 的浏览会话未触发加购，其中移动端加购率（20%）仅为桌面端（42%）的一半；超半数浏览会话时长不足 2 分钟，表明首页/搜索结果页吸引力或性能存在严重问题。”

2. 关键证据（Key Evidence）：用最简图表支撑结论。

   • 图1：全局漏斗图（突出“浏览→加购”环节的断崖式下跌）。
   • 图2：移动端 vs 桌面端加购率对比柱状图（标注 20% vs 42%）。
   • 图3：浏览会话时长直方图（红虚线标出中位数 1.8 分钟）。

3. 根因假设与验证建议（Root Cause Hypotheses & Next Steps）：

   • 假设1：移动端加购按钮太小/位置不佳。
     验证：用热力图工具（如 Hotjar）分析移动端加购按钮区域的点击热区。
   • 假设2：移动端商品图片加载慢，用户失去耐心。
     验证：提取移动端会话的page_load_time，计算其与会话时长的相关性；对比加载时间 >3s 的会话，其加购率是否显著降低。
   • 假设3：首页推荐算法对移动端用户不友好。
     验证：抽样分析移动端浏览会话中，用户点击的前 3 个商品类目，与桌面端对比，是否存在显著差异（如移动端更多点击“折扣”类目，而桌面端更多点击“新品”）。

这份报告，没有一个公式，但每一个数字，都指向一个可执行的动作。这就是描述性统计在数据科学中的终极价值：它不创造新知识，但它像最敏锐的侦探，从海量数据的蛛丝马迹中，揪出那个最该被解决的问题。

5. 常见问题与排查技巧实录：十年踩坑总结的避坑指南

5.1 “为什么我的均值和中位数差这么多？”——分布诊断的速查清单

这是新手最常抛出的问题。答案几乎总是：你的数据不服从正态分布。但具体原因，需要系统排查。我整理了一份“五分钟分布诊断速查表”，贴在团队共享文档首页：