简介这是一份基于Python开发、面向毕业设计与期末大作业场景的商品评价系统完整资源覆盖淘宝、京东商品评论爬虫采集与情感分析全流程。系统整合了Python爬虫、数据处理及LSTM等情感分析模型适合需要完成电商评论分析类项目的计算机专业学生也适合希望快速上手爬虫与文本分析实战的开发者。资源包共103个文件压缩包大小约55.57MB。其中37个csv文件存放不同商品的中文评论数据7个py为爬虫与模型训练源码jpg/png图片包含界面截图与结构图4个xml配置文件及pt、lstmmodel等模型文件对应项目配置与训练结果另有chromedriver驱动和exe辅助工具整体目录清晰、可直接导入运行。需要说明的是作者表示源码均经本地编译通过评审分达95分以上内容经助教审定难度适中适合作为毕业设计或课程设计参考。目前已有218人浏览学习具备一定参考价值。资源包含完整项目源码、评论数据集、模型文件及配套说明便于直接部署或在此基础上进行个性化扩展。1. 拿到“基于Python淘宝、京东爬虫及商品评论情感分析的商品评价系统”这份毕业设计源码第一件事该看什么做过毕设或者带过毕设的人都知道这类“商品评价系统”最大的问题不是代码跑不起来而是拿到手之后不知道整个项目由哪几块拼成更不知道从哪里下手改。它本质上是一条数据流水线用爬虫把淘宝、京东的商品评论抓下来存进数据库然后用情感分析模型给每条评论打正向或负向标签最后用一个可视化界面把分析结果展示出来。整个链路听起来不复杂但实际落地的时候爬虫的反爬、评论字段的清洗、情感分析的准确率、可视化图表的数据格式每一个环节都能让新手卡上两三天。这份源码适合的人群很明确正在做电商数据方向毕业设计的本科/专科生想快速搭一个“爬虫数据分析”完整项目的初学者以及想在一个真实业务场景里把 Python 基础语法、requests、pandas、Flask/Django 和机器学习串起来的从业者。它的价值不在于算法多先进而在于完整——从前端爬取到后端存储再到前端展示是一条闭合的链路能让你在答辩时把“数据从哪来、怎么处理、结果怎么用”讲得清清楚楚。我最近把这类项目重新梳理了一遍从爬虫结构、情感分析流程、系统整合到踩坑记录把最值得看的几个部分拆开讲清楚这篇文章会告诉你哪些模块可以直接用哪些必须改以及改的时候会遇到哪些坑。2. 先把整个系统的技术链路拆清楚爬虫、存储、分析、展示四层架构拿到源码的第一步不是看代码而是看目录结构和数据流。绝大多数毕设项目的代码组织方式都差不多但如果你连这个项目的分层都没搞清楚后面改任何一个功能都会寸步难行。2.1 项目目录应该长什么样从入口文件到核心模块的导航你解压这份源码后第一步要做的不是直接运行main.py而是先打开目录确认这几个关键文件是否存在。一个标准的商品评价系统源码通常包含以下模块project_root/ ├── spider/ # 爬虫模块 │ ├── taobao_spider.py # 淘宝评论爬虫 │ ├── jd_spider.py # 京东评论爬虫 │ └── user_agent.py # 请求头管理 ├── analysis/ # 情感分析模块 │ ├── sentiment_model.py # 情感分析核心代码 │ └── data_clean.py # 文本清洗 ├── db/ # 数据库模块 │ ├── models.py # ORM 模型定义 │ └── database.py # 数据库连接 ├── web/ # Web 可视化模块 │ ├── app.py # Flask 或 Django 入口 │ ├── templates/ # HTML 页面 │ └── static/ # 静态资源 ├── data/ # 抓取或预处理后的数据 ├── requirements.txt # 依赖列表 └── README.md # 项目说明这是一个典型的四层结构spider负责数据采集db负责持久化analysis负责情感分析web负责结果展示。你首先要确认的是这四层之间的数据传递方式——通常是爬虫抓完数据写入数据库分析模块从数据库读取数据分析完成后把结果再写回数据库或生成中间文件最后 Web 层从数据库查数据渲染到前端页面。2.2 数据流是整个系统的心脏从爬虫到数据库到分析结果我习惯把数据流画成一条直线这条线走通了你就能自定义任何环节爬虫采集原始评论 - 数据清洗 - 存入 MySQL/SQLite - 情感分析模块读取 - 输出情感标签 - 写入结果表 - Web 层查询统计 - 前端可视化展示这条链路里最容易被忽略的是“数据清洗”这一步。淘宝和京东的评论内容通常包含大量噪声HTML 实体字符、emoji、用户、短链接、“此用户没有填写评价”这类系统默认文案这些都要在入库前或者分析前清洗掉。源码里如果有一份data_clean.py这部分代码的质量直接决定情感分析的准确率。参数说明数据库表至少要包含id、product_id、comment_content、comment_time、rating、sentiment_result这几个核心字段。rating是可选的京东和淘宝的评论偶尔能抓到评分它是你检验情感分析模型准确率的重要参照——如果用户打了 1 星但模型分析结果是正向说明模型或者清洗逻辑出了问题。2.3 电商平台反爬的边界在哪里一个必须知道的现实问题这里要特别提醒一点淘宝和京东对爬虫的封禁策略是国内电商里最严格的一档。常见做法是模拟浏览器请求头、控制请求频率、设置随机等待时间但即便如此大规模爬取仍然很容易触发验证码和滑块检测。所以这份源码里的爬虫部分大概率是用于小规模教学演示的——抓取几十到几百条评论没问题想抓几万条反爬成本会非常高。我一般会建议毕设项目换一个稳妥的替代方案使用电商平台开放的评论接口。京东的商品评论其实有一个公开的 JSON 接口不需要登录就能返回评论数据淘宝的话相对复杂一些但也可以通过手机端接口做小规模抓取。你拿到源码后先看看jd_spider.py是否用了接口而不是页面解析——如果是页面解析你需要评估一下解析规则的稳定性。3. 用 requests 写一个可用的京东评论爬虫并把数据存进 SQLite京东的评论接口是典型的前后端分离架构数据以 JSON 形式直接返回不需要解析 HTML。这是新手入门爬虫最友好的一个场景也是这份源码里最值得先跑通的部分。3.1 京东评论接口的调用方式从构造请求到解析 JSON京东商品评论接口的基地址是https://club.jd.com/comment/productPageComments.action它接受几个关键参数productId商品 ID、score评分筛选0 代表全部、sortType排序方式5 代表按时间排序、page页码和pageSize每页数量。这个接口返回的数据结构里comments数组里每一条都有一个content字段那就是评论正文。import requests import json def fetch_jd_comments(product_id, pages3): 抓取京东商品评论 :param product_id: 商品ID例如 100012043978 :param pages: 抓取页数 comments [] url https://club.jd.com/comment/productPageComments.action headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: fhttps://item.jd.com/{product_id}.html } for page in range(pages): params { productId: product_id, score: 0, sortType: 5, page: page, pageSize: 10 } resp requests.get(url, paramsparams, headersheaders, timeout10) resp.encoding utf-8 data json.loads(resp.text) for comment in data.get(comments, []): comments.append({ product_id: product_id, content: comment[content], time: comment[creationTime], rating: comment.get(score, None) }) # 每次请求间隔0.5秒避免请求过快被封 time.sleep(0.5) return comments这个代码块的逻辑很直接构造请求参数 - 发送 GET 请求 - 解析 JSON - 提取评论字段。需要注意的是Referer头京东接口会校验来源页面不加这个头很容易返回空数据或者请求失败。time.sleep(0.5)是必要的京东对短时间高频请求的封禁阈值很低0.5 秒已经是比较保守的间隔了。3.2 用 SQLAlchemy 把评论数据落地ORM 比 SQL 拼接更省心爬虫抓到的评论要存进数据库。这份源码的数据库层如果是用 SQLAlchemy 写的你会省很多事如果是用裸 SQL建议你在毕设阶段就改成 ORM。from sqlalchemy import create_engine, Column, Integer, String, DateTime from sqlalchemy.orm import declarative_base, sessionmaker Base declarative_base() class Comment(Base): __tablename__ comments id Column(Integer, primary_keyTrue, autoincrementTrue) product_id Column(String(32), nullableFalse) content Column(String(1000), nullableFalse) comment_time Column(DateTime, nullableTrue) rating Column(Integer, nullableTrue) sentiment Column(String(10), nullableTrue) # 后续情感分析结果写这里 # 创建数据库文件 engine create_engine(sqlite:///jd_comments.db, echoFalse) Base.metadata.create_all(engine) Session sessionmaker(bindengine) # 批量写入示例 def save_comments(comment_list): session Session() for item in comment_list: session.add(Comment( product_iditem[product_id], contentitem[content], comment_timeitem.get(time), ratingitem[rating] )) session.commit() session.close()存评论用 SQLite 就足够了毕设项目的数据量一般也就几万条SQLite 完全扛得住。用 SQLAlchemy 的好处是如果你的数据量真的上去了后续要迁移到 MySQL只需要改create_engine的数据库连接字符串Python 代码一行都不用动。3.3 淘宝评论爬虫的特殊之处登录态和动态加载是两座大山很多拿到这套源码的同学会在淘宝部分翻车原因是淘宝商品评论页的接口需要登录态也就是 Cookie 里必须有有效的用户身份信息才能访问。源码里如果不带 Cookie 处理那跑出来的结果大概率是空的。淘宝评论接口的主要问题是它的返回数据里混入了大量 HTML 转义字符比如\u003d这种 Unicode 编码清洗时需要额外处理。如果你是拿这套源码做毕设答辩一个老实的建议是主攻京东部分把京东讲透淘宝部分做一个功能演示即可。淘宝的接口要比京东复杂一个数量级爬虫代码占整个项目的比重也会大很多反而冲淡了“情感分析”这个核心主题。4. 商品评论情感分析是整套系统的灵魂从朴素贝叶斯到模型评估爬虫只是手段情感分析才是这套系统的核心卖点。答辩时老师最关心的就是你怎么做情感分析的准确率多少为什么选这个方法。4.1 为什么情感分析选朴素贝叶斯而不是深度学习模型市面上这个方向的毕设项目绝大多数用的是朴素贝叶斯或者简单的 SVM。原因很简单深度学习模型虽然准确率高但需要标注数据、训练时间克扣而且毕设不需要那么高的精度——核心是把流程跑通、讲清楚原理。朴素贝叶斯在中文短文本情感分析上的表现其实不差。评论本身是短文本特征维度相对较少朴素贝叶斯“假设特征相互独立”的理论缺陷在短文本场景下被大幅弱化。尤其是在“好评/差评”这种二分类任务上它比很多复杂模型更有优势。from sklearn.naive_bayes import MultinomialNB from sklearn.feature_extraction.text import CountVectorizer # 训练数据正例和负例各若干条 train_texts [质量很好非常满意, 物流很快服务态度好, 做工粗糙有异味, 用了几天就坏了很差] train_labels [1, 1, 0, 0] # 使用jieba分词后再做向量化 vectorizer CountVectorizer() X_train vectorizer.fit_transform([ .join(jieba.cut(t)) for t in train_texts]) clf MultinomialNB() clf.fit(X_train, train_labels) # 预测新评论 def predict(text): X_test vectorizer.transform([ .join(jieba.cut(text))]) return 正向 if clf.predict(X_test)[0] 1 else 负向MultinomialNB 适合离散特征也就是词频或者 TF-IDF 值而 CountVectorizer 就是统计词频的。中文文本和英文不一样必须先用 jieba 分词再把分词结果用空格连接否则整句话会被当成一个词向量化之后完全没有区分度。参数的调整重点有两个CountVectorizer的min_df参数和max_features参数。min_df2表示只保留在至少 2 条评论中出现过的词可以过滤掉只在单条评论里出现的噪声词max_features1000表示只保留词频最高的 1000 个词作为特征减少维度、加快训练。这两个参数对最终准确率的影响非常明显。4.2 没有标注数据怎么办基于情感词典的伪标注方案实战中你大概率没有现成的标注数据训练模型。我一般会用一个很实用的方案先用情感词典给评论打伪标签再用伪标签数据训练模型。# 简单情感词典示例实际使用可以用大连理工的情感词汇本体库 pos_words [很好, 满意, 速度快, 质量好, 值得, 好评] neg_words [很差, 差评, 异味, 坏了, 退货, 垃圾] def pseudo_label(text): pos_count sum(1 for w in pos_words if w in text) neg_count sum(1 for w in neg_words if w in text) if pos_count neg_count: return 1 elif neg_count pos_count: return 0 return None # 不确定的丢掉这个方案的逻辑是用词典先粗筛出一批置信度较高的样本把不确定的样本去掉然后用这批伪标注数据训练朴素贝叶斯。这种做法在真实项目中很多见数据质量虽然不如人工标注但作为毕设演示已经足够。答辩时如果你能说清楚“先词典构建伪标注集 - 训练模型 - 人工抽检验证”老师会认为你对整个流程有清晰认知。4.3 准确率怎么评估用京东的真实星级评论做校验京东评论接口返回的score字段就是天然的真实标签。这就是我为什么强调爬虫阶段一定要把 rating 字段存下来——它是你验证情感分析模型的黄金标准。具体验证方式爬 200 条包含评分数据的评论把评分 1-2 星视为负向、4-5 星视为正向、3 星视为中性弃用然后用你的模型对这 200 条评论做预测计算准确率。如果你模型的准确率低于 80%说明清洗或者特征选择有优化空间。常见的问题集中在分词不准确导致关键否定词丢失“不是很好”被分成了“不是/很好”、忽略程度副词“非常差”和“差”被同等对待、emoji 表情清洗过度导致正面信息丢失。5. 把系统串起来的避坑实操从数据库字段到前端图表的五个血泪教训跑通单个模块很简单把整个系统串起来才是真正容易翻车的地方。这里我整理了五条高频踩坑记录每一条都是我见过实际项目重复踩过的问题。5.1 Flask 启动后页面能打开但图表空白JSON 序列化问题现象Web 页面正常渲染图表区域空白浏览器控制台报错。原因Flask 传给前端的 JSON 数据里含numpy的int64或float64类型这些类型不是标准 JSON 类型JavaScript 无法解析。解决在 Flask 的 JSON 编码器中注册类型转换器或者在后端直接把数据转换成 Python 原生类型。最简单的做法data { positive_count: int(pos_count), # 强制转成 int negatice_count: int(neg_count), positive_rate: round(float(pos_rate), 4) # float 转换并保留4位 }5.2 情感分析结果全是“正向”样本不平衡问题现象模型跑完所有评论都被预测为正向负向评论一条都没有。原因训练数据里正例比负例多太多朴素贝叶斯学到的先验概率严重偏向正向负向的判别阈值被压缩得不成比例。解决训练时正负样本数量对齐或者用class_weight参数给少数类分配更高权重。keras 或者 sklearn 的模型都支持这个参数代价是负向的召回率上升误判也会多一些但至少不会出现全正向的结果。5.3 数据库中文乱码现象SQLite 下没这个问题但迁移到 MySQL 后评论内容全是问号。原因MySQL 数据库默认字符集是latin1不支持中文。解决建库时显式指定字符集CREATE DATABASE goods_review CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;连接字符串里也要加上charsetutf8mb4参数两个地方缺一不可。5.4 爬虫抓到一半被平台封了现象前几十条评论正常突然返回验证码或者 403 状态码。原因请求频率过高或者 User-Agent 长期不变被识别。解决用fake_useragent库每次请求随机更换 User-Agent把请求间隔调到 1 秒以上同时设置重试机制。这里说的重试是重新发送请求不是绕过验证码毕设项目千万不要去做任何破解验证码相关的工作。5.5 页面能跑起来但评论数对不上数据库现象数据库里有 5000 条评论页面统计只有 2000 条。原因页面查询统计用的 SQL 条件跟入库时的字段不一致常见的是过滤了sentiment为空的数据。解决检查 Web 层的查询语句最好把统计口径统一。如果sentiment字段为空说明情感分析模块没有成功运行应该排查分析模块的日志而不是跳过数据。6. 做一套自己说了算的可视化看板从 Flask ECharts 到真正能答辩的演示很多毕设系统的可视化做得很单薄就一个柱状图和一个词云答辩的时候根本撑不起场面。这一章给你一个能落地的升级方案时间投入不大但演示效果会明显好一截。6.1 用 ECharts 渲染一个评论情感仪表盘ECharts 的仪表盘组件适合展示正向评价占比这是这个系统最核心的输出指标之一。配合 Flask 的接口返回整个看板的逻辑可以非常清晰# Flask 后端接口 from flask import Flask, jsonify import sqlite3 app Flask(__name__) app.route(/api/summary, methods[GET]) def summary(): conn sqlite3.connect(jd_comments.db) cursor conn.cursor() cursor.execute( SELECT sentiment, COUNT(*) FROM comments GROUP BY sentiment ) result dict(cursor.fetchall()) total result.get(正向, 0) result.get(负向, 0) pos_rate round(result.get(正向, 0) / total, 4) if total else 0 return jsonify({ pos_count: result.get(正向, 0), neg_count: result.get(负向, 0), pos_rate: pos_rate })前端用 ECharts 仪表盘接收这个接口的数据设置一个threshold阈值参数比如低于 80% 显示为黄色70% 以下显示为红色。这个细节让演示效果更真实。6.2 升级版按商品维度对比情感得分如果只想做一个图表就直接做“商品对比条形图”。筛选 4 到 5 个同类商品对比它们的正向评价率然后分析差异可能的原因。这个环节能让答辩老师看到你的系统具有业务分析能力而不仅仅是技术演示。6.3 一个很有用的校验经验评论时间分布和情感趋势的联合视图把评论时间按月聚合正向率和评论量放在同一个时间轴上能看出一个非常有意思的现象很多商品的负向评论集中爆发是有时间点的比如促销后的一周内。做学术展示的时候这个发现比任何技术参数都要震撼。这一部分投入的代码量不大主要是拼接一个时间维度的 SQL 聚合查询再画一条双 Y 轴折线图。ECharts 的dual_axis模式网上示例很多直接把数据源替换成你的评论表即可。我个人的习惯是每接到一个类似的系统都会在数据入口和出口各加一个日志节点记录这次爬取多少条评论、分析完成多少条、被过滤器丢弃多少条。有一次就是因为这个日志习惯发现清洗正则把一个“很满意”的词拆成了“很”和“满意”导致 30% 的评论被误判为中性丢弃。数据质量的问题大部分时候不是肉眼能看到的得靠日志和数据对账才能发现。说到底这套商品评价系统最值得投入的不是爬虫反爬而是数据质量和情感分析的稳定性。希望你拿到这套源码后能少走些弯路也希望这篇梳理能帮到你。本文还有配套的精品资源点击获取