简介面向毕业设计、期末大作业与课程设计场景的完整Python项目聚焦大众点评数据采集后的可视化展示与评论情感倾向分析。代码全程附带注释从爬虫数据清洗、情感建模到图表展示均有清晰模块划分新手可参照注释理解关键实现部署门槛较低。压缩包采用ZIP格式资源共0个文件涵盖项目代码、说明文档与答辩PPT等主要类型其中代码对应系统功能实现PPT适合汇报演示整体包体大小26.35MB便于快速下载与本地运行。目前已有207人学习下载对于需要完成同类型数据分析或文本挖掘项目的读者可作为一套完整可运行的高分参考方案也可直接作为课设、毕设的代码基础扩展使用。1. 大众点评数据可视化与情感分析毕设项目从零到答辩的完整拆解毕业设计选大众点评数据可视化与情感分析是我带过的学生里通过率比较高的题目之一。原因很直接本地生活评论数据量大、业务语义清晰图表做出来效果直观情感分析又有实实在在的计算过程不是那种「看起来工作量很大、其实全是套模板」的题目。很多人一开始担心两个问题一是数据从哪来二是情感分析准不准。这个项目实际跑下来pandas 清洗数据、SnowNLP 做情感打分、ECharts 出图表难度曲线很平缓真正考验人的反而是数据预处理和演示时的稳定度。这篇按项目代码的实际拆解顺序来写从技术选型到情感分析从可视化看板到最后的答辩避坑完整还原一套能直接演示、能经得住导师追问的毕设系统。2. 技术选型与数据预处理Flask、ECharts、SnowNLP 落地前的准备工作2.1 技术选型为什么是 Flask ECharts SnowNLP 而不是别的组合毕设场景的技术选型原则和工业项目不完全一样。工业项目看扩展性、并发、可维护性毕设看的是三点演示时不出错、代码量足够、被追问时能解释清楚。这个项目用的组合是 Flask ECharts SnowNLP在三者之间做了明确分工。模块选型理由Web 框架Flask路由简单单个 Python 文件就能启动答辩现场部署成本最低可视化EChartsHTML 页面 前端 JS图表交互效果好饼图、柱状图、折线图开箱即用情感分析SnowNLP中文评论不需要自己训练模型装好包直接打分分词jieba与 SnowNLP 配合成熟词云和高频词统计都靠它数据库SQLite单文件数据库零配置避免 MySQL 环境不一致导致演示翻车为什么不换其他方案这里说几个常见误选。Django 功能强但自带 admin 和 ORM 体系答辩时多出很多「为什么要这样配」的问题对纯毕设来说偏重了。Vue 前后端分离看着时髦但涉及跨域、打包、node 环境增加的是部署环节的不可控因素。还有同学想上 Spark 做情感分析本科毕设的数据量撑不起来这个架构导师一眼就看出来是凑数。Flask 最诚实每个页面由后端渲染还是前端请求数据清清楚楚。这个项目里 Flask 承担的角色很纯粹提供数据接口、渲染页面入口、调度分析模块。数据量级在几千到一两万条评论时SQLite 完全够用查询响应在毫秒级演示时不会有任何卡顿感。2.2 数据集字段与预处理流程清洗不到位后面全白费大众点评评论数据的常见字段这个项目里基本都覆盖了。店铺角度有店名、行政区、星级评分、点评数、人均价格评论角度有条件、口味分、环境分、服务分、评论文本、评论时间。拿到原始数据后第一件事不是做分析而是清洗这一步直接决定情感分析的准确率上限。import pandas as pd df pd.read_csv(dianping_reviews.csv, encodingutf-8) # 去除完全重复的记录同一用户对同一店铺的重复点评没有分析价值 df df.drop_duplicates(subset[user_id, shop_id, comment_time]) # 评论文本中的全角空格、零宽字符清理这类字符会让分词结果出现空 token df[comment] df[comment].astype(str).str.replace( [\u3000\xa0\u200b-\u200d\ufeff], , regexTrue ) # 过滤过短评论低于 4 个字符的文本无法提供有效情感信号 raw_len len(df) df df[df[comment].str.len() 4] print(f过滤前 {raw_len} 条过滤后 {len(df)} 条)这里几个参数值得说明。drop_duplicates的subset指定了去重的判断依据只用user_id会误删不同店铺的真实评论所以必须把三个字段组合起来。正则里的\u3000是中文全角空格\xa0是不换行空格这两类字符在复制粘贴的数据里非常常见不清理的话分词阶段会产生孤立空串。评论长度阈值取 4是因为「好吃」「还行」这类两字评论虽然也有情感倾向但数量过多会把情感分布拉向两极对整体分布图产生误导。清洗完数据后还有一个值得做的步骤保存一份清洗后的副本。因为情感分析脚本可能要反复跑每次都从头读原始 CSV 清洗一遍很浪费时间。项目代码里一般会有cleaned_data.csv这个中间产物后续的分析模块统一从清洗后的文件读取。2.3 数据库表设计与项目目录结构让答辩时能随手指出每个文件的作用数据清洗完下一步就是建库导数据。这个项目用 SQLite 的好处在演示场景下体现得特别明显不需要额外启动数据库服务不必担心实验室电脑没装 MySQL 或者密码不对。答辩老师问起数据库设计时你可以直接说表结构还能现场用 Navicat 或命令行打开.db文件验证数据比空口描述有说服力得多。CREATE TABLE shop ( id INTEGER PRIMARY KEY AUTOINCREMENT, shop_name TEXT NOT NULL, district TEXT, star_rating REAL, review_count INTEGER, avg_price REAL ); CREATE TABLE review ( id INTEGER PRIMARY KEY AUTOINCREMENT, shop_id INTEGER NOT NULL, user_id TEXT, comment_time TEXT, rating_taste REAL, rating_env REAL, rating_service REAL, comment_content TEXT );两张表的结构设计遵循一个原则店铺维度和评论维度分开。shop表存聚合类的数据review表存明细类的数据通过shop_id关联。这样在做可视化时饼图和柱状图从shop表查聚合值词云和情感分布从review表查文本内容各司其职不需要做复杂的多表连接。项目目录结构通常是这样的project/ ├── app.py # Flask 主入口路由与接口定义 ├── analysis/ │ ├── sentiment.py # 情感分析核心模块 │ └── wordcloud.py # 词云生成模块 ├── data/ │ ├── dianping_reviews.csv │ └── cleaned_data.csv ├── templates/ │ └── index.html # 可视化展示页面 ├── static/ │ └── js/ # ECharts 配置脚本 └── requirements.txt目录拆分不需要太复杂但analysis模块单独拎出来是必要的。答辩时导师通常会问「情感分析这块代码在哪」你直接指向sentiment.py并打开文件现场讲解比在主应用文件里翻半天效果要好得多。这个项目的代码注释本身就比较完整每个函数上方都有说明新手对着目录结构就能理清执行流程。3. 情感分析实现jieba 分词、SnowNLP 打分与阈值调优3.1 评论情感分析的核心思路从词表匹配到概率模型大众点评评论的情感分析本质上是一个中文短文本二分类问题判断一条评论表达的是正面还是负面情绪。实现路径有两条。其一是词表匹配法维护一个正面词表和一个负面词表统计评论里命中各个词表的词数哪边多就归哪边。优点是简单透明缺点是对「不太行」「一般般」这类带有否定词和转折语义的句子束手无策。其二是用训练好的模型直接打分这个项目选的就是基于朴素贝叶斯的中文情感分析工具 SnowNLP。它的原理并不复杂模型在大量带标注的中文语料上训练过输入一段文本后sentiments属性会返回一个 0 到 1 之间的浮点数越接近 1 表示正面倾向越强越接近 0 表示负面倾向越强。朴素贝叶斯假设词与词之间相互独立计算的是文本属于正类还是负类的后验概率。为什么毕设用 SnowNLP 而不是自己训练模型最现实的原因是数据标注成本。要自己训练一个情感分类器需要几千条人工标注好的评论对毕设周期来说根本不现实。SnowNLP 开箱即用三行代码出结果而且语义判断能力比简单词表法强不少能识别出「环境不错但服务太慢」这种混合情感的句子——虽然它只能给出一个综合分数不会拆解出分方面情感但对毕设来说已经足够了。这个项目在情感分析模块的代码注释里也说明了这一点方便答辩时解释选型动机。3.2 情感打分的具体实现批量处理百万字符也不怕情感打分模块的代码不长但有几个细节写不对结果就会偏。先看核心实现from snownlp import SnowNLP import jieba import pandas as pd def analyze_comment(text: str) - float: 对单条评论进行情感打分返回 0~1 之间的情感倾向值 if not text or len(text) 4: return 0.5 # 过短文本返回中性值避免干扰统计分布 s SnowNLP(text) return s.sentiments df pd.read_csv(data/cleaned_data.csv, encodingutf-8) # 批量计算情感分数apply 循环比 for 逐行遍历更简洁 df[sentiment_score] df[comment].apply(analyze_comment) # 按 0.6 / 0.4 分界划分情感类别 df[sentiment_label] pd.cut( df[sentiment_score], bins[0, 0.4, 0.6, 1.0], labels[负面, 中性, 正面], ) print(df[sentiment_label].value_counts())这里的逻辑说明一下。SnowNLP(text)在内部会先做分词再计算贝叶斯概率所以严格来说不需要手动调用 jieba 就能得到情感分数。但项目中仍然引入 jieba是因为后面生成词云、提取高频特征词时需要独立的 jieba 分词结果。如果你对单条评论的准确率有更高要求可以改成先按标点切句再逐句打分取均值不过对大众点评这种短评论为主的数据整段打分已经够用。pd.cut的三个参数是调优的核心。bins定义了分数区间labels定义了每个区间对应的情感类别。0.6 和 0.4 是最常见的分界点但实际使用时你会发现直接用这两个阈值会有问题具体情况在 3.3 节细说。value_counts()输出的分布结果会直接供饼图数据使用所以这一步的输出格式要提前确认好。3.3 阈值调优与结果验证0.5 不一定是好的分界点跑完一遍情感分析先别急着做图看一眼分数分布。我当时的做法是输出描述性统计和直方图数据结果发现一个典型现象大多数评论的分数集中在 0.8 以上或 0.2 以下0.4 到 0.6 之间反而没什么样本。这其实不是 bug而是 SnowNLP 模型在电商和影评语料上训练的特性——它对态度鲜明的文本打分很果断对中性文本反而会偏向某一端。这带来一个实际问题如果你用 0.5 作为正负分界绝大多数评论都是正的或负的中性比例极低饼图上「正面」占比会显得夸张。项目里的做法是上调正面阈值、下调负面阈值中间留出 0.4 到 0.6 的灰色地带让中性类别至少占 10% 以上的样本。这不仅仅是让图表更好看在答辩时也更好解释「中性区间是情感不明确的评论模型对这类文本没有足够信心」。为了验证阈值的合理性我写了一个简单的抽样脚本随机取出每个类别的几条样本人工检查import random # 从每个情感类别中随机抽取 10 条输出原文和分数人工判断是否符合直觉 sample df.groupby(sentiment_label).apply( lambda x: x.sample(10, random_state42) ) for _, row in sample.iterrows(): print(f[{row[sentiment_label]}] {row[sentiment_score]:.3f} | {row[comment]}) # 建议输出到文件而不是终端方便答辩前整理成验证截图 sample.to_csv(data/sentiment_sample_check.csv, indexFalse, encodingutf-8-sig)random_state42是为了让抽样结果可复现你演示给别人看的时候每次跑出的样例一致讲解时更有条理。人工检查重点看两类边界样本分数在 0.4 到 0.6 之间的评论和分数在 0.6 到 0.7 之间的评论。前者看是否真的语义含混后者看是否明显是负面却被判成正面。大众点评里「口味不错但上菜太慢」这类转折句经常会被判成中性偏正面这是模型能力的边界答辩时主动说出来反而是加分项——说明你理解模型的局限性而不是把它当黑匣子。4. 数据可视化看板搭建ECharts 图表与 Flask 数据接口对接4.1 图表选型每张图回答一个具体问题可视化看板不是把图表堆上去就完事每张图要对应一个业务问题。这个项目里图表和问题的对应关系我建议你和代码里保持一致答辩时讲「为什么要放这张图」会非常顺。图表类型回答的问题数据来源饼图用户评价整体偏正面还是负面review 表按 sentiment_label 分组计数柱状图哪个行政区的负面评论占比最高review 表 join shop 表按 district 分组折线图评论量和情感均值随时间的变化趋势review 表按月份聚合词云用户最常提到的关键词是什么review 表 comment 字段分词取高频词柱状图用负面评论占比而不是评论总量这个细节很重要。如果一个区店铺多它的评论总量天然就高直接画总量柱状图看不出情感质量的差异。算占比让数据说话答辩时也能多讲一句「这里用的是相对指标而不是绝对指标」。4.2 Flask 接口设计后端查询与 JSON 返回的规范写法可视化页面需要的数据统一通过 Flask 接口提供前端页面启动时并行请求几个接口拿到数据后渲染图表。这种模式的好处是前端和后端解耦调试时可以直接在浏览器访问/api/sentiment_distribution查看返回的 JSON 结构。from flask import Flask, jsonify import sqlite3 import pandas as pd app Flask(__name__) DB_PATH data/dianping.db app.route(/api/sentiment_distribution) def sentiment_distribution(): 情感分布饼图接口返回正面/中性/负面三类评论的数量 conn sqlite3.connect(DB_PATH) query SELECT sentiment_label, COUNT(*) as cnt FROM review GROUP BY sentiment_label df pd.read_sql_query(query, conn) conn.close() data [ {name: row[sentiment_label], value: int(row[cnt])} for _, row in df.iterrows() ] return jsonify({code: 0, data: data})这里有几个写法上的讲究。GROUP BY sentiment_label是在数据库层完成聚合而不是把所有评论 load 到 Python 里再分组数据量到上万条时性能差距就出来了。int(row[cnt])是必须的因为 SQLite 的 COUNT 返回的是整型但 pandas 读出来可能是 int64 类型不转的话 JSON 序列化会报错。每个接口的返回结构统一用{code: 0, data: [...]}包裹前端判断code是否为 0 决定要不要渲染这个约定在多个图表接口之间保持一致省去很多调试时间。4.3 前端页面集成ECharts 渲染与异步数据加载前端部分用的是 ECharts 的常规引入方式。在templates/index.html里通过 CDN 引入 ECharts页面加载时用 fetch 请求上面的接口拿到数据后初始化图表。先说通用写法再指出坑。async function loadSentimentPie() { const response await fetch(/api/sentiment_distribution); const result await response.json(); if (result.code ! 0) return; const chart echarts.init(document.getElementById(sentimentPie)); chart.setOption({ title: { text: 评论情感分布, left: center }, tooltip: { trigger: item }, series: [{ type: pie, radius: [35%, 65%], data: result.data, label: { formatter: {b}: {c} ({d}%) } }] }); } window.addEventListener(load, loadSentimentPie);{b}: {c} ({d}%)是 ECharts 的模板字符串{b}是名称{c}是数值{d}是百分比。如果你发现 label 显示不对通常是这里写错了。radius: [35%, 65%]是环形图的半径范围内半径 35% 外半径 65%中间留空可以后续放总评论数视觉上比实心饼图更专业。window.addEventListener(load, ...)确保页面完全渲染后再发请求避免图表容器还没生成就初始化导致报错。词云图不在 ECharts 自带图表里这个项目用的是pyecharts的 WordCloud 或者前端 wordcloud2.js。如果后端生成词云图要注意中文字体问题这一步是毕设演示翻车的高发区具体排查方法放在第 5 章避坑里说。前端拿到词云数据后常见的做法是后端返回关键词列表和权重前端渲染成词云或者后端直接生成图片传给前端展示两种方式这个项目里都有代码注释说明建议用后端生成图片的方案前端只要一个img标签省掉一堆 JS 依赖。5. 常见问题排查与避坑演示前最容易翻车的五个位置5.1 SnowNLP 评分两极分化严重中性评论几乎为零现象跑完情感分析发现分数不是接近 0.95 就是接近 0.050.4 到 0.6 之间的样本不到 5%饼图正面占比特别夸张。原因SnowNLP 的训练语料以电商购物评论为主这类评论本身态度鲜明模型对中性表达没有足够的训练样本。再加上大众点评评论普遍短小「环境好」「价格实惠」这类短语在贝叶斯模型下会得到非常高的正面概率。解决不要用 0.5 作为唯一分界上调正面阈值到 0.6下调负面阈值到 0.4中间区间单独归为中性。同时在答辩材料里主动说明「模型对中性文本区分能力有限所以采用更保守的双阈值方案」这句话能让导师觉得你做过充分的调优思考。5.2 词云图中文全部显示为方框现象词云生成的图片里中文全部变成一个个方块英文和数字正常。原因WordCloud 库默认使用英文字体中文字符无法在默认字体下渲染就会画成方框。这个问题在 Windows 和 Linux 的表现一样只是系统字体路径不同。解决生成词云时显式指定font_path参数。from wordcloud import WordCloud # Windows 一般用 SimHei.ttf黑体Linux 可指定 /usr/share/fonts 下的中文字体 wordcloud WordCloud( font_pathC:/Windows/Fonts/simhei.ttf, width800, height600, background_colorwhite, max_words200, )答辩现场的电脑如果不是你自己常用的那台font_path要提前确认目标机器的字体路径。最好把字体文件复制到项目static/fonts目录下用相对路径引用这样换机器演示不会因为系统字体差异翻车。5.3 Flask 页面在本地能开换到实验室电脑打不开现象在自己电脑运行python app.py浏览器访问http://localhost:5000一切正常。到答辩现场用实验室电脑跑同一份代码浏览器提示无法访问。原因Flask 默认只监听127.0.0.1只有本机能访问。如果其他电脑想通过局域网访问你的服务必须显式指定监听地址同时 Windows 防火墙可能拦截 5000 端口的入站请求。解决if __name__ __main__: app.run(host0.0.0.0, port5000, debugFalse)host0.0.0.0不明思议就是监听所有网络接口。debugFalse是必须的调试模式下的 Werkzeug 调试器存在安全风险而且会自动重载答辩演示过程中如果代码被意外修改会当场重启。访问时用http://你的IP:5000IP 用ipconfig查。如果还是不通检查防火墙——Windows 下在控制面板里放行 5000 端口或者干脆在演讲开始前找管理员关掉防火墙。5.4 Python 3.12 环境下依赖库安装报错现象按requirements.txt用 pip 安装lxml或snownlp报编译错误提示Microsoft Visual C 14 is required。原因部分依赖包的新版本还不适配最新的 Python 3.12或需要本地编译环境。SnowNLP 的底层依赖scikit-learn在旧版本上对 Python 版本有上限要求。解决建议直接用 Python 3.9 或 3.10 新建虚拟环境避开编译问题。conda create -n dianping python3.9 -y conda activate dianping pip install flask snownlp jieba pandas pyecharts wordcloud装了之后先跑一个最小验证确认from snownlp import SnowNLP能正常 import再做后续工作。这一步能省掉大量排查时间我见过太多因为环境不一致导致项目跑不起来的案例了。5.5 情感分析结果导入数据库后图表接口返回的数据不对现象图表接口能访问但饼图比例和情感分析脚本输出的value_counts()结果不一致。原因数据库里的sentiment_label字段是在情感分析阶段写入的如果你调整过阈值代码但数据库里的旧数据没有重新更新就会出现两边对不上的情况。常见做法是清洗脚本、打分脚本、入库脚本分开执行某一步忘记重跑就会出这种问题。解决项目里加一个统一的运行脚本按顺序执行清洗、打分、入库三步并保证每次调整阈值后强制全量重跑。python analysis/clean_data.py python analysis/sentiment.py python analysis/load_to_db.py也可以更简单在sentiment.py里直接连数据库 UPDATE而不是先输出 CSV 再手动导入。重要的是记住一条改了情感阈值必须从第二步开始跑图表数据才能跟着更新。这类问题最容易在答辩前一晚出现拷到演示电脑上跑出来的图和 U 盘里截图对不上当场就尴尬了。6. 效果验证与答辩演示让情感分析结果经得起追问情感分析的准确率是答辩时导师最可能深挖的点。你不能只说「用了 SnowNLP」而要给出一套验证过程和效果数据。我的做法是准备了 100 条人工标注样本其中 50 条从情感分析结果的「正面」类别中随机抽取50 条从「负面」类别中抽取自己手工判断标注后与模型结果对比计算不一致的数量。这个验证不是为了发论文而是为了回答「你这个情感分析到底准不准」的问题把截图和对比表放进 PPT导师看到你是做过验证的这一环节就过了。验证脚本的核心逻辑不复杂把每条评论的人工标签和模型标签放在一张表里计算一致性比例。我当时跑出来的准确率在 80% 上下这个数字不算惊艳但完全够用关键在于你能够解释清楚误差来源和局限。答辩演示时还有两个技巧值得照做。其一是演示前把数据的查询结果缓存住不要现场跑完整的分析流程——如果你从清洗到情感分析到图表展示都现场执行一旦某一步因为电脑性能或环境问题慢了几秒注意力就被打断了。其二是对比图表的顺序安排先展示整体情感分布的饼图再展示负面评论占比最高的区域柱状图最后落到词云和具体评论案例形成一个从宏观到微观的讲述线。导师顺着这条线走每一个问题你都有对应的图表和数据支撑。另外在演示中建议主动提一句「项目代码里包含了较为完整的注释方便后续扩展功能」这句话成本低但效果好。导师如果课后想翻代码注释完整度直接影响他对你这个毕设工作量的评价。我从那次答辩以后养成了一个习惯任何分析类的项目跑通主流程之后第一件事就是固化运行脚本的顺序并做全量重跑验证确认每一步的输出和数据库、图表完全一致后再考虑打包交付。大众点评这个项目从数据清洗到情感分析再到可视化看板完整流程并不复杂真正的功夫都花在细节上。希望这份拆解能帮到正在做这个题目或者准备选这个题目的你。本文还有配套的精品资源点击获取