Python电商销售数据分析：从Excel瓶颈到自动化报表实战-代码聚汇网

Python电商销售数据分析：从Excel瓶颈到自动化报表实战

半夏256·2026-08-30·阅读 21 GEO检测（免费）

python电商数据分析pandas

|难度：普通|阅读约 48 分钟

做电商运营或者数据分析的人应该都有过这种感觉：后台导出一份订单表，拿Excel打开，想着拉个透视表看看这个月卖得怎么样。结果数据一多，几万行还能撑住，几十万行的时候透视表转圈转到怀疑人生，公式拖下去整个窗口都能卡成白屏。更麻烦的是，老板随口问一句“这个月复购率是多少”，你翻遍后台所有报表都找不到现成的指标，只能自己拿订单号去重、再手动算回访用户，一套操作下来小半天就没了。

我用Python做电商销售数据分析，最开始就是为了解决这个“Excel到极限之后怎么办”的问题。后来跑过几个真实项目，从店铺后台的订单明细、用户表、商品表，到第三方平台的交易流水，整理出一套比较完整的分析链路：数据清洗、指标计算、用户分群、可视化报表，最后还能每天自动出一份分析结果。这篇文章就把整套方法拆开讲一遍，用的是模拟但足够接近真实业务的电商订单数据。适合刚接触Python、想用数据分析解决实际业务问题的人，也适合已经在用Excel做报表、打算把流程往Python迁移的运营和数据分析师。

1. 从一堆销售Excel到可分析的数据：先聊聊这活儿为什么值得用Python做

1.1 表格软件做分析时，最让人头疼的几个场景

先说说我为什么坚定地把分析流程从Excel挪到Python。不是说Excel不好——它处理小数据、做临时透视、给业务方看数，效率确实高。但一旦数据量上来，或者分析逻辑变复杂，Exce的短板就特别明显。

第一个场景是多表关联。电商平台的订单表、商品表、用户表往往是分开导出的。Excel里要做VLOOKUP，两个表几万行还能忍，十几万行的时候公式计算一次可能要几十秒，而且拉错一个范围，结果全是#N/A。用pandas做merge，十秒内完成几百万行的关联，这是第一个让我彻底转向Python的原因。

第二个场景是重复性工作。每个月都要出同样一套报表：销售额趋势、品类占比、复购率、TOP商品。Excel的流程是：打开文件、刷新透视表、调整格式、复制到邮件。如果换了月份的数据，所有步骤全部重来。Python可以用脚本把整个流程串成一气，跑一遍输出一张新报表，我只需要改一下文件路径。

第三个场景是计算逻辑不透明。Excel里一个字段怎么算出来的，后面接手的人根本看不懂，尤其是那种写了十几个嵌套IF的公式列。Python代码里每一步都很清楚：先过滤什么、再分组什么、最后聚合什么，对团队协作和审计都友好得多。

1.2 分析项目的整体流程和数据形态

在做之前，我先描述一下这个项目里用的数据形态。整个分析核心是订单明细表，字段包括：订单ID、用户ID、下单日期、商品ID、商品名称、一级类目、销售单价、销售数量、应付金额、实付金额、订单状态（已完成/已取消/退款中）、收货省份、支付方式。此外还有一张用户表，记录用户注册时间、会员等级；一张商品表，记录商品所属品牌、成本价。

整个分析流程分五步：

数据读取与初步探查：用pandas读取CSV，看shape、dtypes、describe，掌握数据概貌。
数据清洗：处理缺失值、重复值、异常订单，统一日期格式。
指标计算：按时间维度、用户维度、商品维度分别计算核心业务指标。
用户分群：用RFM模型给用户打标签，找出高价值客户。
可视化与报表输出：生成静态图表和交互式HTML看板，支持按日期筛选和类目筛选。

如果说每一步解决什么问题，简单概括就是：不洗数据，指标全是错的；不算指标，数据只是数字；不分群，不知道运营该找谁；不做可视化，分析结果无法对外传递。

1.3 环境准备：Python安装、虚拟环境与依赖库

这部分写给刚接触Python的读者。很多人在装环境这一步就被劝退了——不是下载失败，就是装完之后发现命令找不到。这里分享一个比较稳妥的安装流程。

Windows推荐直接去Python官网下载安装包，安装的时候有两个关键点：

安装界面底部勾选“Add Python to PATH”，否则后面在命令行里敲python会提示找不到。
选“Customize installation”，把“Install for all users”勾上，避免后续权限问题。

装完之后，打开命令行（cmd或PowerShell），输入python --version验证版本。如果显示“不是内部或外部命令”，说明PATH没有配置成功，需要手动把Python安装目录和Scripts子目录加到系统环境变量里。这一步是网上热词里“Python环境变量配置”的核心操作，路径一般是C:\Users\用户名\AppData\Local\Programs\Python\Python311\和同目录下的Scripts文件夹。

依赖库我建议装在一个虚拟环境里。虚拟环境的好处是不同项目用不同版本的库不会互相干扰。创建命令：

bash复制python -m venv sales_env
sales_env\Scripts\activate

激活后，命令行前面会出现(sales_env)前缀，然后用pip安装依赖：

bash复制pip install pandas matplotlib pyecharts openpyxl

pandas负责数据处理，matplotlib做静态可视化，pyecharts做交互式看板，openpyxl用于读写Excel文件。如果下载速度慢，可以换用国内镜像源：

bash复制pip install -i https://pypi.tuna.tsinghua.edu.cn/simple pandas matplotlib pyecharts openpyxl

安装完pandas之后，可以在Python环境里验证一下：

python复制import pandas as pd
print(pd.__version__)

能正常输出版本号，说明环境已经OK了。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 订单表清洗：处理脏数据是最花时间、也最影响结果的一步

2.1 拿到一批销售数据后，先别急着算，先看数据长什么样

很多人拿到数据的第一反应是直接groupby求和。这个习惯在实战里非常危险——脏数据会直接污染结果，而且你往往意识不到。我在第一次做数据分析时就踩过这个坑：算出来的GMV比后台报表高了整整15%，排查了半天才发现订单表里混着大量“已取消”的订单。

所以拿到数据后，第一件事永远是“看”。用pandas读取数据后，我会先执行这几行：

python复制import pandas as pd

df = pd.read_csv('orders.csv', encoding='utf-8')
print(df.shape)          # 看看有多少行多少列
print(df.info())         # 查看每列的数据类型和非空情况
print(df.describe())     # 数值列的统计概览
print(df.head(10))       # 看看前10行长什么样

df.info()特别关键，它会告诉你每一列有没有缺失值、数据类型是否正确。常见的坑有：

日期列被读成了object字符串，需要转成datetime。
金额列被读成了object，说明里面有“1,200.00”这种带千分位的字符串，或者混入了非法值。
订单状态列有漏填，会导致数据行数虚高。

2.2 缺失值、重复订单、异常金额怎么处理

数据清洗没有固定模板，但有几个高频操作是绕不开的。

第一是重复订单。同一个订单ID出现两次，原因可能是上游系统重复推送，也可能是退款和原订单产生了多行记录。处理方式：

python复制# 查看重复订单ID
dup = df[df.duplicated('order_id', keep=False)]
# 完全重复的行直接删除
df = df.drop_duplicates()
# 如果同一订单ID有多行但金额不同，需要进一步人工确认

注意drop_duplicates()默认是所有列都一样才去重。如果只想按订单ID去重，需要指定subset=['order_id']，否则看似重复的订单因为某个字段不同会保留下来。

第二是缺失值。订单表中商品ID、用户ID、订单金额是最关键的三个字段，如果这三个字段有缺失，我一般直接删除对应行，因为缺失这些信息无法做任何有效分析。其他字段比如收货省份缺失，可以单独用“未知”填充，保留行信息。

python复制# 删除关键字段缺失的行
df = df.dropna(subset=['order_id', 'user_id', 'order_amount'])
# 非关键字段用固定值填充
df['province'] = df['province'].fillna('未知')

第三是异常金额。电商订单里金额为0、负数、或者超出正常范围的情况很常见。金额为0的订单可能是赠品单，负数可能是退款单。处理逻辑需要结合业务来定：如果只分析已完成的销售，就过滤掉“已取消”“已退款”“退款中”的订单。如果分析支付流水，就要单独区分。

python复制# 只看已完成的订单
df_valid = df[df['order_status'] == '已完成']
# 金额范围过滤：单价和数量都大于0
df_valid = df_valid[(df_valid['product_price'] > 0) & (df_valid['quantity'] > 0)]

2.3 统一日期时间格式和商品分类

日期字段如果被读成字符串，排序、按月份聚合都会出错。pandas提供to_datetime方法，能自动识别大部分常见格式：

python复制df['order_date'] = pd.to_datetime(df['order_date'])
# 提取年、月、日、周几，方便后续按不同时间粒度聚合
df['year'] = df['order_date'].dt.year
df['month'] = df['order_date'].dt.month
df['day'] = df['order_date'].dt.day
df['weekday'] = df['order_date'].dt.weekday

商品分类也是需要统一的字段。不同时期导入的商品，分类名称经常会不一致，比如“女装”和“女士服装”其实是一类，“手机”和“手机数码”可能让人困惑。这一步需要结合商品表做一个分类映射，把所有变体统一成一级类目。

python复制category_map = {
    '女士服装': '女装',
    '女装': '女装',
    '男士T恤': '男装',
    '男装T恤': '男装',
}
df['category'] = df['category'].map(category_map).fillna('其他')

数据清洗的耗时通常占到整个项目的一半以上。很多人觉得清洗“不如建模高端”，但实际业务里，清洗质量直接决定分析结果能不能用。宁可前面多花时间把脏数据处理干净，也不要等到计算出不可思议的业务数字之后再去排查。

3. 核心销售指标的计算逻辑：GMV、客单价、复购率这些数到底该怎么算

3.1 GMV和销售额的区别，别把订单表里的数直接相加

“GMV”这个词在电商里被用得很随意，但它和实际到账的销售额是有本质区别的。简单说，GMV是成交总额，包含下单但未支付、已取消、退款中的所有金额；销售额则是实际确认的收入，要刨掉取消和退款。

如果直接用订单表的“实付金额”这一列求和，结果通常会偏高。因为订单表里可能包含已取消的订单、退款中的订单，这些订单的金额不应当计入最终销售额。计算逻辑应该是：

python复制# GMV口径：所有订单金额之和
gmv = df['order_amount'].sum()

# 销售额口径：仅已完成订单
sales_amount = df[df['order_status'] == '已完成']['order_amount'].sum()

# 到手口径：已完成订单减去退款金额
refund_amount = df[df['order_status'] == '退款中']['refund_amount'].sum()
net_sales = sales_amount - refund_amount

三个口径的差异，就是业务上“看起来卖了很多，实际没赚那么多”的原因。做分析之前一定要先定义清楚口径，否则业务方用GMV数字、你用净销售额数字，两个人对不到一起，讨论半天都是白费。

3.2 用户维度分析：客单价、购买频次、复购率

用户维度几个常用指标，我逐个说清楚定义和pandas实现。

客单价的定义是“平均每个订单的支付金额”，但电商里更常看的是“每个用户的平均消费金额”。两者差在于：前者是以订单为粒度，后者是以用户为粒度。订单粒度的客单价计算是：

python复制# 订单粒度客单价
aov = df_valid.groupby('order_id')['order_amount'].sum().mean()

用户粒度的人均消费金额：

python复制# 用户维度聚合
user_stats = df_valid.groupby('user_id').agg(
    total_spend=('order_amount', 'sum'),
    order_count=('order_id', 'nunique'),
    first_order=('order_date', 'min'),
    last_order=('order_date', 'max'),
)

购买频次可以用总订单数除以用户数。复购率这个指标则有两种常见算法，不同口径差别很大。一种是以“所有用户”为分母，计算下过2次及以上订单的用户占比；另一种是以“已经买过一次的用户”为分母，计算再次购买的比例。我推荐第二种，因为真正的复购行为是有过一次购买后再次回购，新客首次下单不应该被算作复购分母里的未复购人群。

python复制# 每个用户的订单数（去重订单ID）
user_order_counts = df_valid.groupby('user_id')['order_id'].nunique()

# 复购率：买过2次及以上的用户 / 买过1次及以上的用户
repurchase_rate = (user_order_counts >= 2).sum() / len(user_order_counts)

务必注意nunique()和count()的区别。如果订单表里同一订单ID有多行明细，用count()会把同一个订单重复计多次，复购率会被虚高。

3.3 商品维度分析：Top N商品、类目贡献、退货率

商品维度的分析更多是“找机会点”。先看销售额TopN和销量TopN：

python复制# 商品销售额排行
product_sales = df_valid.groupby('product_id').agg(
    sales_amount=('order_amount', 'sum'),
    sales_quantity=('quantity', 'sum'),
    order_count=('order_id', 'nunique'),
).sort_values('sales_amount', ascending=False)

# 类目销售贡献
category_sales = df_valid.groupby('category')['order_amount'].sum().sort_values(ascending=False)

类目贡献可以结合帕累托法则，看看头部20%的类目贡献了多少销售额。通常一个店铺里，排名前5的类目就能贡献80%以上的GMV，这就是选品和库存策略的核心依据。

退货率也是商品分析里不可忽视的指标。退货率高的商品，表面上GMV很漂亮，实际扣除退货成本之后可能根本不赚钱。退货率的计算：

python复制# 按商品统计销量和退货量
refund_stats = df_valid.groupby('product_id').agg(
    total_qty=('quantity', 'sum'),
    refund_qty=('退款数量', 'sum'),
)
refund_stats['refund_rate'] = refund_stats['refund_qty'] / refund_stats['total_qty']

退货数据的质量往往比销售数据更差，很多店铺的记录里退款数量字段是空的。如果字段空缺太多，我会单独用订单状态为“退款”的订单去关联商品表，而不是直接用退款数量列。

4. 用户价值分群：用RFM模型找出真正值得运营的用户

4.1 RFM模型的基本逻辑

RFM模型是电商用户分析里最经典、也最实用的框架，三个维度分别是：

R（Recency）：最近一次购买时间距今多久，越短说明用户越活跃。
F（Frequency）：购买频次，一段时间内下单次数，越高说明用户越忠诚。
M（Monetary）：消费金额，累计消费越多说明用户价值越高。

RFM模型的核心价值不是算出三个数值，而是通过三个维度的交叉组合，把用户切成几类：高价值用户、潜力用户、流失用户。运营动作可以直接基于分类来制定——高价值用户重点维护，流失用户定向召回，潜力用户做转化刺激。

RFM模型的实现通常分四步：计算R/F/M三值 -> 给每个维度打分 -> 按阈值分箱 -> 打标签。下面详细说明每一步。

4.2 用pandas实现RFM打分与分群

先假设分析时间窗口是最近180天，参考日期取数据中最大订单日期（避免用到未来日期）。

python复制import datetime

# 参考日期：分析窗口的截止日，取数据里最大下单日期+1天
reference_date = df_valid['order_date'].max() + datetime.timedelta(days=1)

rfm = df_valid.groupby('user_id').agg(
    last_order_date=('order_date', 'max'),
    order_count=('order_id', 'nunique'),
    total_amount=('order_amount', 'sum'),
)

rfm['R'] = (reference_date - rfm['last_order_date']).dt.days
rfm['F'] = rfm['order_count']
rfm['M'] = rfm['total_amount']

接下来是打分。打分的逻辑不一定要用复杂的模型，直接用分位数划分即可。我给R维度打的是反向分——R值越小（最近刚买过）得分越高；F和M维度是正向分——值越大得分越高。

python复制# 用四分位数打分
rfm['R_score'] = pd.qcut(rfm['R'], 4, labels=[4, 3, 2, 1])
rfm['F_score'] = pd.qcut(rfm['F'].rank(method='first'), 4, labels=[1, 2, 3, 4])
rfm['M_score'] = pd.qcut(rfm['M'].rank(method='first'), 4, labels=[1, 2, 3, 4])

pd.qcut是按分位数分箱，但如果数据中有大量重复值，可能会报Bin edges must be unique错误。这时可以用rank(method='first')先给数据排个序，让相同值有先后顺序，避免分箱边界重复。这是很多教程里没提的细节，实测非常有用。

分完箱之后，把评分转成数字，再划分等级：

python复制rfm['R_score'] = rfm['R_score'].astype(int)
rfm['F_score'] = rfm['F_score'].astype(int)
rfm['M_score'] = rfm['M_score'].astype(int)

# 综合分数
rfm['RFM_score'] = rfm['R_score'] * 100 + rfm['F_score'] * 10 + rfm['M_score']

# 定义用户等级
def rfm_label(row):
    if row['R_score'] >= 3 and row['F_score'] >= 3 and row['M_score'] >= 3:
        return '高价值用户'
    if row['R_score'] >= 3 and row['F_score'] >= 3:
        return '潜力用户'
    if row['R_score'] >= 3 and row['F_score'] < 3:
        return '新用户'
    if row['R_score'] < 3 and row['F_score'] >= 3:
        return '沉默高价值用户'
    return '低活跃用户'

rfm['user_segment'] = rfm.apply(rfm_label, axis=1)

apply按行遍历在数据量大时比较慢，如果用户数超过几十万，建议改成向量化条件赋值：

python复制import numpy as np

conditions = [
    (rfm['R_score'] >= 3) & (rfm['F_score'] >= 3) & (rfm['M_score'] >= 3),
    (rfm['R_score'] >= 3) & (rfm['F_score'] >= 3),
    (rfm['R_score'] >= 3) & (rfm['F_score'] < 3),
    (rfm['R_score'] < 3) & (rfm['F_score'] >= 3),
]
choices = ['高价值用户', '潜力用户', '新用户', '沉默高价值用户']
rfm['user_segment'] = np.select(conditions, choices, default='低活跃用户')

4.3 分群结果怎么落到运营动作上

RFM分完群之后，最关键的下一步是把结果输出成运营可以使用的表格。每类人群对应不同的运营策略：

用户类型	特征	建议运营动作
高价值用户	近期购买、频次高、金额高	VIP专享客服，新品优先试用，生日礼包
潜力用户	近期活跃、频次高，但金额偏低	组合套餐推荐，满减券刺激客单价
新用户	最近首购，频次和金额都较低	引导加购，二次购买优惠券
沉默高价值用户	历史消费高但最近没来	召回短信，爆款推荐，专属折扣
低活跃用户	长期未购买	低成本触达，为主推款引流

运营活动的效果评估需要建立对照：把分群结果导出后，每类用户随机分成实验组和对照组，一组触达、一组不触达，两周后比较复购率差异。这个闭环逻辑，比单纯发券要科学得多。

RFM分群结果导出Excel也很简单：

python复制rfm[['user_id', 'R_score', 'F_score', 'M_score', 'user_segment']].to_excel('rfm_result.xlsx', index=False)

5. 可视化报表：从静态图到能点能筛的HTML看板

5.1 用matplotlib快速看整体趋势

分析结果最终是要给人看的。如果只是自己在终端里打印几个数字，老板看不懂，运营不买账。可视化是整个分析链路里“最后一公里”的关键。

先用matplotlib画销售趋势图和类目占比图，快速评估整体情况。

python复制import matplotlib.pyplot as plt

# 设置中文字体
plt.rcParams['font.sans-serif'] = ['SimHei']
plt.rcParams['axes.unicode_minus'] = False

# 月度销售趋势
df_valid['year_month'] = df_valid['order_date'].dt.to_period('M')
monthly_sales = df_valid.groupby('year_month')['order_amount'].sum()

fig, ax = plt.subplots(figsize=(10, 5))
monthly_sales.plot(kind='line', marker='o', ax=ax)
ax.set_title('月度销售额趋势')
ax.set_xlabel('月份')
ax.set_ylabel('销售额')
plt.tight_layout()
plt.show()

这里有个容易踩的坑：matplotlib默认字体不支持中文，图里会出现方框。解决方式是在代码开头设置中文字体。如果SimHei在你的系统里不存在，可以换成Arial Unicode MS（macOS）或者直接用plt.rcParams['font.family'] = 'sans-serif'后指定一个存在的中文字体。

静态图的优势是轻量、出图快，适合放在周报、月报里。劣势是不能交互，用户想看某个具体的日期、某个具体的类目，没法直接点。

5.2 用pyecharts做交互式看板

交互式看板推荐用pyecharts。它可以生成一个HTML文件，在浏览器里打开，支持鼠标悬浮查看数值、图例筛选、指定日期范围缩放。

一个看板通常包含几个核心图表：

折线图：日/月销售额趋势。
柱状图：各品类销售额对比。
饼图：支付方式占比。
表格：Top10热销商品。

pyecharts的基本用法是链式调用配置：

python复制from pyecharts.charts import Bar, Line, Pie
from pyecharts import options as opts

# 月度销售柱状图
bar = (
    Bar()
    .add_xaxis([str(m) for m in monthly_sales.index])
    .add_yaxis("销售额", monthly_sales.round(2).tolist())
    .set_global_opts(
        title_opts=opts.TitleOpts(title="月度销售额"),
        yaxis_opts=opts.AxisOpts(name="金额(元)"),
    )
)
bar.render("monthly_sales_bar.html")

如果要把多个图表放在同一个看板页面里，可以用Page容器组合：

python复制from pyecharts.charts import Page

page = Page()
page.add(bar)
page.add(pie)
page.render("sales_dashboard.html")

pyecharts的图表文件是独立的JS渲染HTML，不需要联网也能在浏览器查看，非常适合发给运营同事。

5.3 模板化输出日报：每天自动生成一份分析结果

这步是把分析流程自动化的关键。很多运营每天都问“昨天卖了多少”，每次都手动跑脚本、截图、发微信群，耗时又没技术含量。用Python可以做成自动日报：读取昨日新增的订单数据，自动生成图文摘要和图表，输出到一个固定文件。

核心思路是把所有分析逻辑写成一个脚本，然后每天定时执行。脚本的输入是当天新增数据，输出是HTML报告或Excel文件。定时执行可以借用系统的计划任务：Windows用“任务计划程序”，macOS/Linux用crontab。命令大概这样：

bash复制0 9 * * * cd /path/to/project && /path/to/venv/bin/python generate_daily_report.py >> logs/daily.log 2>&1

这样每天早上九点自动跑一遍分析，生成报告。运营上班打开浏览器就能看到最新的销售数据，不用再等人手动跑数。这一步做完，分析项目的ROI才算真正体现出来。

6. 百万行订单数据下Pandas提速的几种实用做法

6.1 数据类型优化：object转category能省一半内存

数据量小的时候，Pandas跑起来很流畅，没人关心内存。但电商订单明细动辄几十万上百万行，加上多表关联，内存占用直接飙升。我见过最夸张的情况是，一个500万行的订单表读进pandas占了快8GB内存，几乎把16GB内存的电脑拖死。优化后内存降到了不到2GB。

优化方式主要有两个。第一个是读取时指定列类型，第二个是把字符串列转成category类型。

订单状态、支付方式、收货省份这些字段，实际取值种类很少，但每行都重复存了字符串，非常浪费内存。转成category类型之后，pandas内部只存整数编码和一份映射表，内存占用大幅下降：

python复制df['order_status'] = df['order_status'].astype('category')
df['province'] = df['province'].astype('category')

更彻底的优化是在读取时就指定类型：

python复制dtype_map = {
    'order_status': 'category',
    'province': 'category',
    'payment_method': 'category',
}
df = pd.read_csv('orders.csv', dtype=dtype_map)

6.2 能向量化就别用apply循环

Pandas性能优化里，向量化和循环的差距常常能达到100倍以上。很多人写代码习惯用for循环逐行处理，或者用apply逐行计算。这在数据量小的时候看不出问题，数据量一大就慢得明显。

举个例子，给订单打“是否高价值订单”的标签，有几种写法：

python复制# 慢：apply逐行
df['is_high_value'] = df.apply(lambda row: 1 if row['order_amount'] > 500 else 0, axis=1)

# 快：向量化
df['is_high_value'] = (df['order_amount'] > 500).astype(int)

第二种写法直接用布尔比较和类型转换，底层是C语言实现的，速度比Python循环快几十倍。原则是：尽可能让pandas的内置方法处理数据，而不是让Python解释器逐个处理每一行。

groupby和transform的组合也值得留意。如果要在分组内计算统计量，然后映射回每一行，用groupby加transform会比先groupby再map更简洁高效：

python复制# 计算每个用户的订单金额均值，映射回订单级别
df['user_avg_amount'] = df.groupby('user_id')['order_amount'].transform('mean')

6.3 数据量大时的分批处理和保存格式选择

当订单数据数量级到达千万行时，单次读入内存可能都不现实。这时有两种常用方案：

第一种是分批读取。用read_csv的chunksize参数，每次只读一部分数据，处理完再合并结果：

python复制chunk_list = []
for chunk in pd.read_csv('orders.csv', chunksize=500000, dtype=dtype_map):
    # 对每个chunk做清洗
    chunk = chunk[chunk['order_status'] == '已完成']
    chunk_list.append(chunk)

df = pd.concat(chunk_list, ignore_index=True)

第二种是改用更高效的数据格式。CSV虽然通用，但是读取慢、体积大。如果数据量已经达到几百MB甚至GB级别，建议转成Parquet或Feather格式。Parquet的压缩率高、读取速度快，而且在PySpark、DuckDB等工具中也能直接使用：

python复制# 一次性将清洗后的数据保存为parquet
df.to_parquet('orders_clean.parquet')
# 之后读取直接pd.read_parquet('orders_clean.parquet')

这里有个细节：pandas本身不带parquet读写功能，需要先装pyarrow库：

bash复制pip install pyarrow

Parquet文件比CSV在磁盘上小很多，读取速度通常快3~5倍。如果你的数据每天都会更新，建议把当天数据追加到一个Parquet分区目录里，每天只读取当天的新数据，长期累积分析时再全量加载。

另外，如果需要把分析结果发给别人做进一步处理，Excel仍然是接受度最高的格式。但注意Excel的单表上限是1048576行，超过这个行数保存会报错。这也是热词里总有人搜“Python创建表格怎么只能65536”的原因——Excel老版本的限制是65536行，新版本放宽到1048576行，但依然不建议用Excel存大数据集。

7. 几个实际项目中反复踩过的坑

最后这部分，集中说几个我在真实电商数据分析项目里反复踩过的坑，都属于网上教程里不怎么提、但实际非常影响结果的问题。

第一个是时区问题。电商平台导出的订单时间，有些是GMT+8，有些是UTC，有些带时区标记有些不带。如果不统一时区，按日汇总时销售量就会出现“少一天”或“多一天”的错觉。处理方式是在读取后统一转成北京时间：

python复制df['order_date'] = pd.to_datetime(df['order_date'], utc=True)
df['order_date'] = df['order_date'].dt.tz_convert('Asia/Shanghai')
df['order_date'] = df['order_date'].dt.tz_localize(None)

第二个是金额精度问题。订单表里的金额字段，有的平台导出来是float，有的是decimal字符串，还有的存的是分而不是元。如果不确认单位就开算，最后数字差100倍。我习惯把所有金额字段统一转成元并且保留两位小数，再单独写一条校验逻辑，确保单价*数量与应付金额的误差在合理范围内。

第三个是分类映射不完整。数据清洗时做的category_map，很可能漏掉一部分新出现的分类。漏掉之后会被fillna('其他')吞掉，在后续分析里“其他”类目占比会异常高。解决方法是清洗后检查一下“其他”类目占比，如果超过10%，说明映射表大概率有缺失，需要回业务侧确认。

第四个是取消订单的退款字段。很多订单在后端是“原订单+退款记录”两条，如果不加处理，同一笔销售会重复计算。处理方式是用订单ID+商品ID做唯一键，先删除重复记录，再汇总金额。

我在实际跑项目中形成一个习惯：每次清洗完数据，会编写几条校验规则自动检查结果合理性。比如总销售额必须等于订单明细金额之和、用户数不能超过订单表用户ID去重数、退款金额不能超过销售额等等。这些校验脚本虽然简单，但能避免大量返工，尤其是数据源结构发生变化的时候，校验规则能在第一时间暴露问题。

用Python做电商销售数据分析，最大的价值不是“会写几行代码”，而是把一套原本需要人工反复处理的分析流程，变成可复现、可扩展、可自动化的系统。从读数据、洗数据、算指标，到用户分群、出报表，每一步都有标准化的处理方式。踩过几次坑之后，我最大的体会是：数据清洗和口径定义永远是最重要的一环，后续的分析方法再花哨，也弥补不了上游数据的错误。希望这篇文章能帮你少走一些弯路，把时间花在真正有价值的数据解读和业务决策上。