简介基于Python的商品销售数据分析可视化系统源码采用Django框架开发并集成网络爬虫模块用于采集、清洗商品销售数据并进行可视化展示覆盖毕业设计或Web开发实训的完整项目链路。压缩包共1480个文件体积17.68MB前端资源占据较大比重包括JavaScript、CSS、HTML文件以及SCSS/LESS样式表、字体与图片素材另有13个Python核心源码文件及对应pyc编译文件、JSON配置和Template模板等目录布局清晰便于按模块查阅。项目已通过本地编译测试各部分功能均获得指导老师认可能够直接运行。目前已有181人学习下载。借助该源码可快速理解Django项目的MTV分层结构、爬虫程序的编写方式以及数据可视化方案同时内置的后台管理界面风格统一适合作为课程设计或毕业设计的基础框架进行二次开发减少从零搭建环境与调试功能的时间成本。1. 这套带爬虫的商品销售分析系统到底解决了什么问题先给结论这是把“数据采集 — 数据清洗 — 指标计算 — 可视化展示”整条链路串起来的完整项目源码。你把它跑起来就能定期从商品页或销售页抓数据清洗后算销售额、销量、类目占比、环比趋势最后输出成图表甚至可视化大屏。很多人拿到源码第一时间想的是“爬虫怎么写”但真正卡住后续迭代的通常是数据口径不统一、图表表达不到位、跑几天就断。这套系统的价值在于它把销售分析里最常踩的坑提前处理了一部分——字段怎么定义、数据怎么落盘、图表怎么选型都有可改可跑的代码作参照。适合刚入门数据分析的学生、做电商运营想自己拉数据的人也适合需要快速搭一个“能看”的系统原型给业务方的开发者。接下来按采集、清洗、展示、排错的顺序拆开讲。2. 商品数据采集爬虫只写“拿到页面”是不够的2.1 先定字段和落盘方式再写请求代码常见做法是先想清楚要哪些字段再写爬虫。商品销售分析最常用的字段有商品标题、价格、销量月销或累计、上架时间、店铺名、所属类目、评论数、采集时间。注意“采集时间”很多人一开始不建导致后面做不了时间序列分析只能看总量。落盘方式我一般首选 CSV 或 SQLite。CSV 的好处是可视化阶段 pandas 直接read_csv但数据量大了以后并发写入会出问题SQLite 更适合定时任务增量跑按item_id 采集日期做唯一约束天然去重。小规模个人项目用 CSV 就够没必要一上来就上 MySQL。# 采集的字段和落盘结构先定下来 import csv from datetime import datetime FIELD_NAMES [ item_id, title, price, month_sales, shop_name, category, comment_count, collected_at ] def init_csv(pathsales_data.csv): 初始化 CSV 文件带表头 with open(path, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnamesFIELD_NAMES) writer.writeheader()逻辑说明FIELD_NAMES就是后面所有分析脚本依赖的字段契约。utf-8-sig编码很重要Excel 直接打开 CSV 时如果没有 BOM 头中文列名会乱码——这是 csv 模块最容易踩的坑。init_csv只在第一次运行时调用后续用追加模式写入。参数说明encoding用utf-8-sig而不是utf-8目的是兼容 Excel 的打开方式newline是文档明确要求避免 Windows 下 CSV 出现空行。collected_at字段用datetime.now()在写入时生成保证可回溯。2.2 用 requests 拉页面用 xpath 抽数据爬虫部分不复杂requests 发请求拿 HTMLlxml 的 xpath 从 HTML 里提取字段。写得好的 xpath 比正则好维护得多尤其是页面结构调整时通常只改一个表达式不用重写整段解析逻辑。import requests from lxml import etree HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: text/html,application/xhtmlxml, Accept-Language: zh-CN,zh;q0.9, } def fetch_page(url, timeout10, retries3): for attempt in range(retries): try: resp requests.get(url, headersHEADERS, timeouttimeout) if resp.status_code 200: return resp.text except requests.RequestException as e: print(f第 {attempt 1} 次请求失败: {e}) return None def parse_product(html_text): 从 HTML 中提取单个商品的字段 if not html_text: return [] tree etree.HTML(html_text) items [] # 商品列表项按真实页面结构调整 xpath for node in tree.xpath(//div[contains(class, product-item)]): item { item_id: node.xpath(.//a/data-id)[0] if node.xpath(.//a/data-id) else , title: node.xpath(.//a[contains(class, title)]/text())[0].strip() if node.xpath(.//a[contains(class, title)]/text()) else , price: node.xpath(.//span[contains(class, price)]/text())[0].strip() if node.xpath(.//span[contains(class, price)]/text()) else , month_sales: node.xpath(.//span[contains(class, sales)]/text())[0].strip() if node.xpath(.//span[contains(class, sales)]/text()) else 0, } items.append(item) return items逻辑说明fetch_page里做了超时和重试这是爬虫稳定性的基础。parse_product先用etree.HTML把文本解析成可查询的节点树再用 xpath 按节点路径取值。注意这里没有直接用一段很长的绝对路径而是用contains(class, product-item)这种相对宽松的匹配页面加个空属性不至于直接崩。参数说明timeout10控制单次请求上限避免某个商品页卡死整个采集任务retries3是遇到网络波动时自动重试的次数。这两组参数在真实项目里要看目标站点的响应速度调太激进会被限流太保守会拖慢采集。xpath 里.//a/data-id这种形式是“从当前节点往下找”比全局//div/...更稳。这里要延伸一个重点解析逻辑出现空列表时不要急着改 xpath 字符串先确认页面是否被反爬拦截。很多翻车案例是 HTML 结构没变但返回的是一个验证页或空白页xpath 当然匹配不到。排错顺序应该是“先看响应内容再改 xpath”而不是反过来。2.3 反爬应对只做必要的一层严格来说商品销售数据采集涉及的“反爬应对”主要是请求头伪装、访问频率控制、失败重试。这套源码里一般会写一个简单的限速器和请求头池。不要过度设计个人项目用到随机延时已经足够。import time import random class RateLimiter: 简单的访问频率控制 def __init__(self, min_interval1.5, max_interval4.0): self.min_interval min_interval self.max_interval max_interval self.last_request_time 0 def wait(self): now time.time() gap now - self.last_request_time need random.uniform(self.min_interval, self.max_interval) if gap need: time.sleep(need - gap) self.last_request_time time.time() # 使用方式 limiter RateLimiter(min_interval2.0, max_interval5.0) for url in url_list: limiter.wait() html fetch_page(url) # 后续解析与入库...参数说明min_interval1.5和max_interval4.0是两次请求之间的随机等待时间区间。随机是为了避免固定频率的特征被识别具体值根据目标站点的响应速度和自己的容忍度来调——对方响应 0.5 秒你就没必要等 4 秒如果出现请求失败或验证码说明等待区间太小要往上加。这套代码的边界很清晰它解决的是“静态页面可见数据”的采集。如果你打开页面 F12 看到数据根本不在一开始的 HTML 里而是要通过额外接口异步加载那 requests xpath 就抓不到需要启动浏览器渲染常见工具有 Selenium 或 Playwright。但那是另一个复杂度层级先跑通静态链路更重要。3. 销售数据清洗与分析口径统一才能算出真实业绩3.1 去重、空值、类型转换是分析正确的前提爬虫采集的数据是“脏”的典型问题包括同一商品被抓两次、价格字段里混入“¥”或“满减标签”、销量写成“1万”、类目为空。这些不处理后面所有聚合结果都是错的。pandas 做数据清洗是最顺手的路径。import pandas as pd df pd.read_csv(sales_data.csv) # 1. 去重同一商品同一天只保留一条 df df.drop_duplicates(subset[item_id, collected_at], keeplast) # 2. 价格清洗去掉货币符号和特殊标签转成浮点 df[price] df[price].astype(str).str.replace(¥, , regexFalse) df[price] df[price].astype(str).str.replace(r满\d减\d, , regexTrue) df[price] pd.to_numeric(df[price], errorscoerce) # 3. 销量清洗把“1.2万”这样的文本转成数字 def parse_sales(val): val str(val).replace(万, 万).replace(, ) if 万 in val: return float(val.replace(万, )) * 10000 return pd.to_numeric(val, errorscoerce) df[month_sales] df[month_sales].apply(parse_sales) # 4. 空值处理删除价格和销量都为空的记录 df df.dropna(subset[price, month_sales], howall) print(df.info()) print(df.head())逻辑说明清洗顺序很重要。先去重再转类型最后补空值。如果先删空值再去重可能导致同商品两条记录里较新的一条因为字段缺失被删掉留下旧数据。参数说明subset[item_id, collected_at]定义了“重复”的判断标准——同一天同一商品只留一条。keeplast保留重复项中最后出现的记录因为后采集的数据通常更新。errorscoerce把所有转不了数字的值变成 NaN后面统一处理。价格里的“满减标签”用正则r满\d减\d剥离注意regexTrue表示这个 replace 走正则逻辑。3.2 销售额、类目占比、环比用 groupby 一次算完分析指标里最常用的是总销售额、类目销售额占比、Top 商品排行、月度环比。一次性写多个 groupby 再合并是数据分析里非常省事的方式。# 构造销售额列 df[revenue] df[price] * df[month_sales] # 按类目聚合 category_stats df.groupby(category).agg( total_revenue(revenue, sum), total_sales(month_sales, sum), avg_price(price, mean), product_count(item_id, nunique) ).reset_index() # 销售额占比 category_stats[revenue_ratio] category_stats[total_revenue] / category_stats[total_revenue].sum() # 按类目采集日期做时间序列算环比 daily df.groupby([collected_at, category]).agg( daily_revenue(revenue, sum) ).reset_index() # 环比用 pandas 的 shift注意先排序 daily daily.sort_values([category, collected_at]) daily[prev_revenue] daily.groupby(category)[daily_revenue].shift(1) daily[mom_ratio] (daily[daily_revenue] - daily[prev_revenue]) / daily[prev_revenue] print(category_stats.head()) print(daily.head())逻辑说明groupby().agg()把多个统计量一次算完nunique是统计去重后的商品数比count更准确。环比这里用shift(1)取上一期值配合groupby(category)保证每个类目内部自己比不会跨类目错位。参数说明agg里的写法是(字段, 函数)新版 pandas 推荐这种显式写法比旧版{字段: 函数}更稳定也不会触发未来版本警告。sort_values([category, collected_at])必须先按类目再按日期排序否则 shift 取到的“上一行”不是同一类目的上一期。3.3 你需要注意的“口径坑”同一份爬虫数据不同人算出来的销售额可能差一大截原因是“销售额”这个口径没定死。是按price * month_sales算还是按price * comment_count算是按采集当天的价格算还是按上架时的价格算源码里常见做法是用price * month_sales因为销量字段对应当前价格的销售结果虽然不精确但可复现。另一个坑是collected_at字段的格式CSV 里存的是字符串比如2024-06-01 10:23:45直接 groupby 是按“到秒”分组同一天的数据会被拆成很多组。正确做法是df[collect_date] pd.to_datetime(df[collected_at]).dt.date再按天分组。这是数据分析里最常见的“看起来对、实际上分错组”的问题。# 日期截断到天 df[collect_date] pd.to_datetime(df[collected_at]).dt.date # 重新按天和类目聚合 daily df.groupby([collect_date, category]).agg( daily_revenue(revenue, sum) ).reset_index()逻辑说明pd.to_datetime把字符串转成 datetime 类型.dt.date取出日期部分丢掉时分秒。之后 groupby 就按自然日聚合了。参数说明如果原始日期格式不是标准的YYYY-MM-DD需要先pd.to_datetime(col, format%Y-%m-%d %H:%M:%S)把 format 指定清楚否则遇到2024/06/01或01-06-2024这种不标准格式时解析结果可能南辕北辙。4. 可视化让销售问题一眼就能被看见4.1 图表选型按“要回答什么问题”来定可视化从来不是图越多越好而是每张图都能回答一个具体问题。做商品销售分析时我一般固定四类图总销售额趋势用折线图、类目销售额占比用饼图或环形图、Top 商品榜单用横向柱状图、类目对比用分组柱状图。这套源码里可视化库有 pyecharts 和 matplotlib 两种写法前者更适合做可视化大屏后者适合快速出图后贴进报表。import matplotlib.pyplot as plt import matplotlib # 解决中文显示问题这个是必须设置的 matplotlib.rcParams[font.sans-serif] [Microsoft YaHei, SimHei, PingFang SC] matplotlib.rcParams[axes.unicode_minus] False # Top 10 商品销售额横向柱状图 top_items df.groupby(title)[revenue].sum().nlargest(10).sort_values() plt.figure(figsize(10, 6)) plt.barh(top_items.index, top_items.values, color#4C72B0) plt.xlabel(销售额元) plt.title(Top 10 商品销售额排行榜) plt.tight_layout() plt.savefig(top10_products.png, dpi200) plt.show()逻辑说明nlargest(10).sort_values()先取销售额前十再按值升序排列让 barh 画出来的图是从大到小从上往下排。rcParams里两行配置是 matplotlib 中文显示的固定套路不设置的话图里全是方块。参数说明font.sans-serif是一个备选字体列表Windows 下优先用Microsoft YaHeimacOS 会命中PingFang SC。axes.unicode_minus必须设成False否则负号显示成乱码。dpi200控制输出清晰度贴进 PPT 或报告时建议不低于 150。4.2 用 pyecharts 拼一个销售可视化大屏可视化大屏的关键不是炫技而是把核心指标放在一屏之内让人不用滚动就能看到整体状况。用 pyecharts 做这种布局非常合适它生成的是 HTML 页面浏览器直接打开不需要搭前端服务。from pyecharts.charts import Line, Pie, Grid from pyecharts import options as opts # 每日销售额趋势折线图 line Line() line.add_xaxis([str(d) for d in daily[collect_date].tolist()]) line.add_yaxis(销售额, daily[daily_revenue].round(2).tolist(), is_smoothTrue, linestyle_optsopts.LineStyleOpts(width2, color#5B9BD5)) line.set_global_opts(title_optsopts.TitleOpts(title每日销售额趋势)) # 类目占比环形饼图 pie_data [list(z) for z in zip(category_stats[category], category_stats[revenue_ratio])] pie Pie() pie.add(类目占比, pie_data, radius[40%, 70%]) pie.set_global_opts(title_optsopts.TitleOpts(title类目销售额占比)) # 用 Grid 并排排版 grid Grid() grid.add(line, grid_optsopts.GridOpts(pos_left10%, pos_right50%)) grid.add(pie, grid_optsopts.GridOpts(pos_left55%)) grid.render(sales_dashboard.html)逻辑说明Grid把折线图和饼图放在同一页面左右两侧。pyecharts 的链式调用风格很直观add_xaxis/add_yaxis配好数据后set_global_opts设置标题。radius[40%, 70%]是环形图的关键参数内半径 40%外半径 70%中间空出来可以放文字。参数说明折线图里is_smoothTrue会让曲线变得更圆滑适合展示趋势LineStyleOpts(width2)控制线宽。饼图的radius列表里两个值都是相对于画布尺寸的百分比改内半径可以调整环的粗细。pos_left和pos_right控制各自占位先画在左半区第二个图放在右半区避免重叠。4.3 图表不能只“好看”要配上可交互的能力做数据分析可视化最忌讳的是生成一张静态 PNG 就完事。业务方大概率会追问这个占比是哪个时间段的、点击其中一个类目能不能看到该类目下的 Top 商品pyecharts 天然支持这些交互——鼠标悬停显示数值、点击图例筛选数据不需要额外代码。所以在交付源码时建议保留render(sales_dashboard.html)的输出方式而不是转成图片。如果你需要定时刷新数据把爬虫和分析脚本做成同一个数据源每次重新分析时都重新生成 HTML。浏览器里按 F5 刷新就是最新数据。这里有个小技巧把采集时间写进页面副标题这样看图的人知道这是哪一天的数据不会拿三天前的数据做今天的判断。line.set_global_opts( title_optsopts.TitleOpts( title每日销售额趋势, subtitlef数据采集时间{df[collected_at].max()[:16]} ) )逻辑说明subtitle从清洗后的 DataFrame 里取最近一次采集时间拼进副标题。因为collected_at是字符串[:16]截断到分钟级别避免把秒数也露出来。这是一个很小但很显专业的细节。5. 跑通源码的避坑指南5 个高频故障与排查方法5.1 爬虫返回空列表先看响应内容再改 xpath现象parse_product返回[]分析脚本拿不到数据。 原因最常见的是页面反爬拦截返回的是验证页而不是商品列表页其次是 HTML 结构变更class 名失效。 解决先保存 HTML 到本地文件打开看内容。html_text fetch_page(https://example.com/products) if html_text: with open(debug.html, w, encodingutf-8) as f: f.write(html_text)逻辑说明把响应原文落盘是排查爬虫问题的第一动作。看文件里商品节点的 class 还在不在、页面是否跳转到验证页、是否要求登录。只要这一步确认了问题就分清了——是反爬还是页面改版。参数说明encodingutf-8写入时必须指定避免中文在 Windows 默认编码下写坏。5.2 中文乱码贯穿整个链路现象CSV 打开乱码、图表标题变方块、数据库插入报错。 原因CSV 没用 BOM、requests 没有按页面 charset 解码、matplotlib 默认字体不支持中文。 解决三处固定写法逐一检查。requests 拿到resp.text时如果乱码改为resp.content.decode(resp.encoding or utf-8, errorsignore)。CSV 写入时用utf-8-sig。图表字体在 4.1 已经设置过。逻辑说明resp.text是 requests 根据响应头猜的编码解码的结果猜测失败就乱码。显式用resp.encoding可以拿到请求头声明的字符集errorsignore保证遇到无法解码的字符不至于抛异常。5.3 销售额算出来数值异常偏大现象某类目销售额比常识高几个数量级。 原因销量字段没有清洗干净1.2万被pd.to_numeric转成了 NaN随后dropna没删干净或者价格里混入“券后价”这种特殊文本。 解决清洗后先打印df[price].describe()和df[month_sales].describe()看最大值、最小值是否符合业务常识。比如单品价格上百万、月销上亿都是清洗遗漏的信号。逻辑说明describe 看一眼分布就能发现极端值。价格均值 500最大值 999999基本可断定有脏数据没清理。参数说明describe()默认只统计数值列输出 count、mean、std、min、max是数据清洗后的例行体检项。5.4 定时任务跑几天就断现象前三天数据正常第四天开始缺数据或直接报错。 原因目标页面改了结构、IP 被限制、本地磁盘满了、CSV 文件被 Excel 占用导致写入权限失败。 解决把单次采集包在try...except里失败时写日志而不是直接退出CSV 文件关闭后再用 Excel 打开采集间隔加长到 5 秒以上。import logging logging.basicConfig(filenamecrawler.log, levellogging.INFO, format%(asctime)s %(levelname)s %(message)s) try: html fetch_page(url) items parse_product(html) save_to_csv(items) logging.info(f采集成功: {url}, 共 {len(items)} 条) except Exception as e: logging.error(f采集失败: {url}, 错误: {e})逻辑说明logging 比 print 更适合长期运行的脚本日志落盘后即使你不在电脑前也能事后排查。参数说明levellogging.INFO表示 INFO 及以上级别的日志都会记录format里加时间戳是定时任务的硬性要求没有时间没法定位是哪天开始出错的。5.5 pyecharts 渲染出来是空白页现象HTML 文件能打开但图表区域一片空白。 原因常见的是 pyecharts 版本不匹配图表配置对象和渲染器版本不一致或者 HTML 里引用的 JS 文件路径是远程 CDN内网环境加载失败。 解决检查本机pip show pyecharts版本保证项目需求文件里的版本号一致离线环境用render(dashboard.html)生成后把 JS 库一起打包或者在项目根目录放一个本地 jshost 路径配置。逻辑说明pyecharts 生成的 HTML 默认通过 CDN 加载 echarts 的 JS 文件。内网环境无法访问公网时页面自然白屏。解决方案是改用本地资源把 echarts.min.js 下载到项目里后通过pyecharts.globals.CurrentConfig.ONLINE_HOST改成本地路径。这个版本兼容问题在源码里经常被忽略跑通代码后建议第一时间检查。6. 让这套系统真正“能用起来”三个进阶技巧6.1 把单次脚本改成增量采集现在这套系统跑一次只抓当前页面重复运行会把数据再写一遍。改造成增量采集核心做法是记录上一次采集的最大时间戳或商品 ID 列表然后新数据对比跳过已存在的记录。# 读取已有数据中的 item_id 集合用于增量过滤 existing_ids set() if os.path.exists(sales_data.csv): existing_df pd.read_csv(sales_data.csv, usecols[item_id]) existing_ids set(existing_df[item_id].tolist()) new_items [item for item in items if item[item_id] not in existing_ids]逻辑说明用usecols只读一列比读全表快得多。过滤后只追加新增商品再配合collected_at字段依然保留每天跑一次就形成了时间序列。参数说明增量过滤只在“商品 ID 不变但销量变化”时才有意义——如果你的分析需要考虑销量变化那就不要过滤而是同 ID 新记录全量追加靠drop_duplicates保证取最新值。6.2 指标导出成 Excel 报表可视化大屏适合看趋势业务方做汇报时更想要一张 Excel。把 category_stats 和 daily 两个表导出到同一个 Excel 文件的不同 sheet是最实用的交付方式。with pd.ExcelWriter(销售分析报表.xlsx, engineopenpyxl) as writer: category_stats.to_excel(writer, sheet_name类目汇总, indexFalse) daily.to_excel(writer, sheet_name每日趋势, indexFalse)逻辑说明ExcelWriter配合to_excel可以一个文件写多张表。indexFalse避免把 pandas 的行号写进 Excel否则导出后第一列全是 0、1、2 这种无意义序号。参数说明engineopenpyxl在写 xlsx 格式时是标配xls 才需要xlwt。6.3 用函数封装让整个链路可复用把清洗、计算、可视化各包成一个函数主程序只负责按顺序调用。新手常犯的错误是把几百行代码全部平铺在一个脚本里改一个参数就得从头跑一遍。封装后爬虫可以单独跑、分析可以单独跑互不干扰。def main(): # 1. 数据采集可独立运行 crawl_all_pages() # 2. 清洗与分析输入 CSV输出 DataFrame df clean_sales_data(sales_data.csv) # 3. 可视化输出 HTML 大屏 generate_dashboard(df) print(全部任务执行完成) if __name__ __main__: main()逻辑说明main()把三段逻辑按顺序串起来每段都能单独 import 后复用。if __name__ __main__保证只有直接运行这个文件时才执行主流程被其他脚本 import 时不会重复跑。参数说明这个结构直接支持 Windows 计划任务或 Linux crontab 调度每天早上 9 点跑一次业务方上班就能看到昨天的数据。我的使用习惯是先把爬虫、清洗、可视化三个脚本分开运行验证全部通过后再合并成main()。这个习惯帮我避免了很多“刚改完爬虫可视化也跟着报错”的连锁问题。跑数据的脚本不能只在自己电脑上能跑换台机器、换个目录也能跑这套源码才算真正接手了。希望帮到你。本文还有配套的精品资源点击获取