简介：面向计算机专业毕业设计或 Python 项目实战学习者，这份源码与文档完整实现了旅游景点评论情感分析系统，经导师指导后评审获得 98 分，覆盖数据采集、文本预处理、情感分类及可视化展示等完整环节。压缩包共 102 个文件、约 47.72MB，以 32 个 Python 源文件作为后端核心逻辑，配合 10 个 Vue 页面、6 个 JavaScript 脚本与 3 个 HTML 入口实现前端交互，另有 JSON 配置、Markdown/Text 说明文档、图片素材等辅助资料，目录结构清晰便于按模块研读。目前已有 54 人学习下载。项目难度适中，源码均经本地编译调试确认可运行，适合需要完整参考毕业设计实现思路、快速搭建情感分析应用并理解前后端协同流程的学习者直接使用。
1. 这不是玩具 demo：基于 Python 的旅游景点评论情感分析系统到底能做什么
很多同学第一次接触“情感分析”毕业设计时，以为就是拿一个词典库查词打正负分，那种东西根本撑不起一套完整系统。这份基于 Python 的旅游景点评论情感分析系统设计与实现源码，是有前端页面、有后端接口、有情感模型、有结果可视化的完整小工程，评审分 98 分。它能解决的是“如何在真实景点评论数据上，把正面、负面、中性情绪以可视化的方式呈现出来”这件事，适合正在做 Python 课设、毕业设计，或者想练手完整项目流程的从业者和学生。你拿到手能直接编译运行，也能在它的基础上改模型、换数据、接爬虫，往下扩展的空间不小。
2. 系统拆解：从文件清单反推 Flask + Quasar 技术与数据流
2.1 从七个关键文件反推技术栈
拿到一个源码包，别急着跑，先看文件清单。这份资源里出现的.editorconfig、.gitignore、index.html、result.html、index.template.html、favicon.ico、light.jpg、quasar.conf.js，信息量已经很大了。
.editorconfig说明工程对代码风格有统一约定，缩进、换行、编码都有人管过，不是随手丢出来的代码。quasar.conf.js是关键线索，Quasar 是一套基于 Vue 的跨端 UI 框架，它能构建出index.html和result.html这样可以直接由后端托管的静态页面。也就是说，这个项目的前端不是那种手写的单页 HTML，而是用组件化方式组织起来的，构建之后才生成最终页面文件。
后端技术栈则是以 Python 为主，入口文件常见做法是用 Flask 起一个轻量 Web 服务。为什么这么判断？因为这类课设项目一旦上了 Django，复杂度会翻好几倍，而且需要数据库配置、Admin 后台一大堆东西，对于“评论情感分析”这个场景属于杀鸡用牛刀。Flask 的一个核心优势就是路由简单、静态文件托管方便，把 Quasar 构建出来的dist目录直接指给 Flask 就能跑通整个演示流程，这也是绝大多数合格从业者遇到“Python 后端 + 前端页面”时的默认选择。
技术栈可以归纳成一句话：Vue/Quasar 负责交互界面，Python/Flask 负责接口和业务逻辑，情感分析模块单独拆出来作为核心组件。这个分层最大的好处是每一块都能单独验证，你在答辩时可以打开浏览器只测前端，也可以在终端里单独跑情感分析的函数，讲起来层次很清晰。
2.2 一条评论从输入到可视化展示的完整流程
这个系统的业务链路并不复杂，但每一环都有实际的技术动作。用户在首页输入景点评论，点击提交之后，流程会按下面这个顺序走：
- 前端把用户输入的文本打包成 JSON，通过 HTTP 请求发送到后端接口。
- 后端拿到文本后先做基础清洗，去掉多余的换行和空格，避免脏数据影响模型判断。
- 清洗后的文本交给情感分析模块，计算出情感得分，并映射成“正面 / 中性 / 负面”三个标签。
- 后端把得分和标签组合成 JSON 返回给前端。
- 前端拿到结果后跳转到结果页，渲染情绪占比和评论文本，展示给用户。
在 Flask 工程里，路由和数据交互的骨架是下面这个样子：
from flask import Flask, request, jsonify, render_template from analyze import predict_sentiment # 情感分析模块 app = Flask(__name__, static_folder="dist", template_folder="dist") @app.route("/") def index(): return render_template("index.html") @app.route("/api/analyze", methods=["POST"]) def analyze(): data = request.get_json() text = data.get("text", "").strip() if not text: return jsonify({"error": "评论内容不能为空"}), 400 result = predict_sentiment(text) return jsonify(result) if __name__ == "__main__": app.run(host="0.0.0.0", port=5000, debug=False)这里有两个参数值得注意。static_folder="dist"和template_folder="dist"是把同一个目录既当作静态资源目录，又当作页面模板目录，Quasar 构建出的dist目录里同时有index.html、result.html和前端资源文件，Flask 这样配置之后才能让根路径/直接渲染首页。port=5000是 Flask 默认端口，后面会在避坑章节详细说它为什么容易踩雷。
接口设计上只开了一个/api/analyze，POST JSON 数据，返回 JSON 结果，这样前端调用和后端调试都很直观。你可以在终端里用 curl 直接验证这个接口，也可以让前端页面去调它。
2.3 index 与 result 双页面设计的答辩价值
很多同学会问，为什么非要用两个页面，在同一个页面里局部刷新不行吗？从功能上讲当然可以，但这份源码选择 index.html 和 result.html 分开是有实际考量的。
index.html 承担的是“输入”职责，它的核心是文本框和提交按钮，用户可以集中注意力输入评论。result.html 承担的是“输出”职责，页面要展示情感得分的可视化图表、正面/负面/中性的对比数据，以及当前评论的分析结果。把输入和结果拆开，最直接的好处是页面逻辑不会互相干扰，你改输入区的样式不会影响结果区的图表布局，这在开发阶段能省不少事。
从答辩演示的角度看，双页面还有一个隐藏优势：你可以先把首页展示给评委看，输入一条精心准备的评论，点击提交之后跳转到结果页，整个“从输入到输出”的演示路径是完整且具有戏剧性的。如果在一个页面里局部刷新，视觉冲击力会弱很多，评委也更容易追问一些边角问题。这个细节虽然听起来有点玄学，但从一线答辩经验看，页面跳转带来的“完成感”确实比局部刷新更强。
3. 情感分析核心：SnowNLP 打分逻辑与阈值怎么设才不翻车
3.1 为什么用 SnowNLP 而不是自建深度学习模型
这是做情感分析类毕业设计绕不开的选型问题。为什么这个项目没有用 BERT、没有用 LSTM，甚至没有自己从头训练一个分类器？答案很简单：旅游景点评论场景下没有充足的人工标注数据集。深度学习模型需要海量带标签语料才能训练得起来，而课设项目的核心目的是跑通业务闭环，不是刷 SOTA 准确率。
SnowNLP 是 Python 生态里最成熟的中文情感分析库之一，它内置了一个基于朴素贝叶斯的文本分类模型，专门面向中文语料做了处理，开箱即用。SnowNLP 的情感打分返回一个 0 到 1 之间的浮点数，越接近 1 代表情绪越正面，越接近 0 代表越负面。它的优势体现在三方面：不需要自己准备训练语料、调用接口简洁、处理速度足够快。对于单条评论级别的分析需求，耗时可以忽略不计。
这里顺带提一个问题：为什么不做多模态情感分析？多模态情感分析通常需要融合文本、语音、表情或图像信息，比如视频场景下要同时判断画面人物表情和字幕文本才能得到更准确的结论。这个项目面向的是旅游景点文字评论，天然没有语音和图像信息输入，所以做文本单模态分析反而是最合理的选择。不要在答辩时主动提“为什么不加入图像分析”这种自己给自己挖坑的问题，除非你已经准备好了基于图文融合的扩展方案。
3.2 打分实现的代码结构：从文本到正面/负面标签
情感分析模块通常会被拆成一个独立的 Python 文件，方便后端主程序 import。核心代码结构是这样的：
from snownlp import SnowNLP def predict_sentiment(text: str) -> dict: # 调用 SnowNLP 计算情感得分，范围在 0~1 之间 s = SnowNLP(text) score = round(float(s.sentiments), 4) # 阈值分档：>= 0.6 正面，<= 0.4 负面，中间是中性 if score >= 0.6: label = "正面" elif score <= 0.4: label = "负面" else: label = "中性" return {"score": score, "label": label}sentiments属性是 SnowNLP 封装好的情感倾向值，round(..., 4)是为了让返回的 JSON 更干净。阈值取 0.6 和 0.4 是实际项目里比较常用的做法，为什么不直接用 0.5 作为分界线？因为 SnowNLP 底层朴素贝叶斯模型对中性和模糊表达会有一定的随机波动，如果死卡 0.5，一条得分在 0.48 到 0.52 之间来回跳的评论，会被反复打成“负面”和“正面”，这在演示阶段非常难看。留出 0.4 到 0.6 的中间区间作为中性缓冲带，能明显减少这种抖动。
3.3 文本预处理：做少了等于喂脏数据
直接拿原始字符串丢给 SnowNLP 不是不行，但你会看到很多奇怪的结果。比如评论里含有大量换行，或者用户随手打的连续空格，这些噪声虽然不至于让模型完全崩溃，却会导致得分不稳定。常规做法是在进入情感分析之前做一次轻量清洗：
import re def clean_text(raw: str) -> str: # 把换行符统一替换成空格，避免句子被硬切断 raw = raw.replace("\r", " ").replace("\n", " ") # 多个连续空白字符收敛成单个空格 raw = re.sub(r"\s+", " ", raw) return raw.strip()这里的参数逻辑不复杂，raw.replace("\r", " ")先处理回车，replace("\n", " ")再处理换行，最后用正则\s+把多个连续空白字符压缩成一个。这个预处理放在后端做还有一个额外的好处：同一份数据无论从哪个前端入口传进来，清洗规则都是一致的。有些同学在前端就把文本 clean 一遍，后端又 clean 一遍，两边逻辑不一致，结果就会跑偏。
另外一个常见的脏数据来源是错别字和网络缩略语，但这一层不必在预处理阶段强行处理，因为 SnowNLP 本身对短文本中的个别错字有一定的容忍度，强行做纠错反而可能引入更多误差。你只需要做好空白字符清理就够了，这属于“少做反而更安全”的典型场景。
4. 把源码跑起来：环境安装、依赖补齐与前端构建
4.1 环境准备：从 Python 安装到虚拟环境
无论你是从 python 官网下载安装包，还是电脑上已经有 Python，建议都用 3.8 或更高版本。网上很多源码跑不起来的翻车现场，一半以上是 Python 版本太低或太高导致的。注意安装时勾选 “Add Python to PATH” 这个选项，否则后面在终端里敲python命令会直接提示未找到。
这一步的标准操作流程如下：
# 创建虚拟环境，在当前目录生成 venv 文件夹 python -m venv venv # Windows 系统激活虚拟环境 venv\Scripts\activate # Linux / macOS 激活虚拟环境 # source venv/bin/activate虚拟环境这一步千万不要跳过。每台电脑的全局 Python 环境里可能已经有各种版本的 Flask、numpy，互相之间版本冲突起来，你会花掉大量时间在排错上。虚拟环境隔离之后，所有依赖只装在这个项目里，怎么折腾都不影响其他项目。
接着安装依赖。如果源码包没有提供requirements.txt，运行下面这条就够了：
pip install flask snownlpflask是 Web 框架，snownlp是情感分析库。有些版本会连带安装numpy、jieba、scikit-learn等依赖，这些都是正常的。安装完之后可以顺手跑一下pip list确认版本信息，避免后面排查问题时两眼一抹黑。
4.2 启动后端与访问页面的完整步骤
依赖配好之后，在项目根目录找到 Python 主入口文件，一般是app.py或main.py。如果你的源码包里没有明确的入口，就按 Flask 标准结构找带有app = Flask(__name__)的那个文件。启动命令很简单：
python app.py终端输出类似Running on http://127.0.0.1:5000就说明服务起来了。打开浏览器访问http://127.0.0.1:5000，应该能看到首页的评论输入框。输入一条类似“风景很美，服务也贴心”的评论，提交后会自动跳到结果页，看到情感得分和正负面标签。如果一切正常，就说明前后端和数据链路已经全部打通。
此时你可以在终端里看到每一次请求的日志记录，包括请求方法是 POST、路径是/api/analyze、返回状态码是 200。这套日志将来排查问题非常有用，建议先跑通一次再继续往下改。
4.3 改了前端源码要怎么构建回 index.html
很多同学会遇到一个很尴尬的情况：项目跑起来了，但想改前端界面文字、颜色或者布局，却发现直接改index.html很别扭，因为它是 Quasar 构建出来的产物，手动改不够规范，下次构建还会被覆盖。
正确做法是：进入前端源码目录，先安装依赖，再修改源码，最后重新构建。
npm install # 启动 Quasar 开发模式，自带热更新，改完源码页面自动刷新 npx quasar dev # 确认 UI 调整没问题后，生成新的 dist 目录 npx quasar buildquasar.conf.js里可以配置devServer的端口号，默认在 8080 左右，这个端口只服务于前端开发模式，跟 Flask 的 5000 端口没有关系。开发模式下前端会直接请求后端 API，因此需要确保 Flask 已经启动。构建完成之后，把新的dist目录内容复制回 Flask 托管的目录，重启app.py就能看到改动后的页面。
这一步是很多课程设计项目不会写进文档的操作，但实际工作中几乎必遇。前端页面不可能一次写对，迭代构建是常态。弄清楚quasar.conf.js里每一项配置的作用，比死记硬背命令重要得多。
5. 避坑排查：跑通这套系统一定会遇到的 5 个问题
5.1 中文乱码：控制台与页面各出现一次
现象：Flask 终端里输出的日志包含乱码，或者页面返回的 JSON 中中文变成了\u98ce这类转义序列。
原因：两种情况性质不同。终端乱码是 Windows 控制台默认编码不是 UTF-8 导致的；JSON 里中文变为\u转义则是 Flask 默认对非 ASCII 字符做了安全转义，严格来说不算错误，但看着很难受。
解决：终端执行chcp 65001切到 UTF-8 代码页；JSON 展示问题可以用 Flask 提供的配置：
app = Flask(__name__) app.config["JSON_AS_ASCII"] = False这条配置的意思是返回 JSON 时不要强制转成 ASCII，中文能直接以明文形式出现在响应体里。注意不同 Flask 版本中JSON_AS_ASCII可能已更名，如果提示配置无效，检查你安装的 Flask 是大版本 2 还是 3，再做对应调整。
5.2 端口被占：5000 端口不是每次都能用
现象：执行python app.py后提示Address already in use，服务根本无法启动。
原因：5000 端口是很多 Web 应用和代理工具的默认端口，Windows 上尤其容易被其他程序占用。如果不检查端口状态就反复重启，你会误以为自己的代码写错了。
解决：先查是谁占用了端口，再决策是换端口还是清理进程。Windows 下用下面的命令查：
netstat -ano | findstr :5000 # 输出里的最后一列是 PID，比如 12345拿到 PID 后可以在任务管理器里找到对应进程结束它，或者更推荐的做法：直接改 Flask 启动端口，避免和现有程序抢位置。比如改成 5001：
app.run(host="0.0.0.0", port=5001, debug=False)注意端口一改，前端页面里请求 API 的地址也得同步改。Quasar 前端如果写死了 5000 端口，就会造成“后端起来了但前端一直报请求失败”的诡异问题。
5.3 分析结果整体偏向正面：SnowNLP 的语料偏见
现象：不管输入什么评论，哪怕是“服务态度极差，再也不来了”，情感得分依然高于 0.6，被判定为正面。
原因：这是 SnowNLP 默认模型最出名的一个坑。它内置的朴素贝叶斯模型主要使用电商购物评论语料训练，对旅游场景下的一些否定表达、口语化吐槽识别不够准确。尤其像“再也不来”“差评”这类表达，在购物语料和旅游语料里的情感权重差异很大，模型很容易给出偏乐观的判断。
解决：先承认这是模型固有问题，然后分两步处理。第一步，把阈值往上调，比如正面阈值从 0.6 提到 0.7，先压制住假阳性；第二步，搜集二三十条典型的旅游好评和差评，标好正负标签，跑一遍看看正确率，再微调阈值。这里透露一个实操细节：不要把所有希望寄托在调阈值上，阈值只能解决边界问题，解决不了模型本身的语料偏差，最彻底的办法是准备少量带标签的景点评论语料微调 SnowNLP，这个进阶操作咱们下一章展开。
5.4 页面白屏且静态资源 404：dist 路径接错
现象：Flask 启动正常，但打开首页时页面完全空白，F12 控制台里全是404报错，找不到.js和.css文件。
原因：Quasar 构建出的dist/index.html里引用的资源路径写的是绝对路径，比如/css/app.xyz.css。如果 Flask 的static_folder没指对目录，这些绝对路径就全变成了指向 Flask 根路径下的资源，自然全部 404。
解决：两种方案任选其一。一是改 Flask 侧配置，确认Flask(__name__, static_folder="dist", template_folder="dist")中的目录路径和你实际放置构建产物的路径一致；二是改 Quasar 构建配置，在quasar.conf.js里把build.publicPath设成相对路径./，这样构建出的 HTML 资源引用会变成相对路径，无论部署到哪个目录都不会丢资源。这两种方案我倾向于第二种，因为它把问题消解在了构建环节，而不是每次部署都去检查后端目录配置。
5.5 改完代码不生效：debug 模式与残留进程
现象：修改了 Python 源码里情感标签的映射逻辑，刷新页面发现结果完全没变化，甚至重启了 Flask 还是老样子。
原因：如果你的启动命令里带了debug=True，Flask 会在代码发生变化时自动重载，但重载行为在某些编辑器组合下并不稳定；如果多个进程同时跑着旧版本的服务，浏览器请求到了旧进程，也会产生“改了等于没改”的错觉。
解决：生产演示阶段把debug=False固定住，每次修改后手动重启服务；重启前先检查有没有残留的 Python 进程。Windows 下可以执行一次：
tasklist | findstr python.exe看到多个同名进程就全部结束，再从干净状态启动。这一招在我自己拆项目时几乎是每次必做的，90% 的“代码改了不生效”最后都查到是进程残留或浏览器缓存，真正代码逻辑问题反而很少。
6. 进阶：用 30 条人工标注样本校准模型阈值
6.1 构建验证样本集与打分对齐脚本
如果你想让这个系统的情感判断更可信，下面的方法可以直接上手。准备 30 条真实景点评论，既包含“景色很美，值得来”这种直白好评，也包含“性价比低，不推荐”这种隐含负面情绪的句子。人工标注好每一条是正面还是负面，然后写一个小脚本对打分结果做对齐：
# 手工标注：1 代表正面，0 代表负面 cases = [ ("景色很美，值得来", 1), ("性价比低，不推荐", 0), ("环境一般，服务还行", 1), ] correct = 0 for text, expected in cases: pred = 1 if predict_sentiment(text)["label"] == "正面" else 0 correct += (pred == expected) print(f"一致率: {correct}/{len(cases)}")这个脚本的核心价值是把模型表现量化。你看一眼正确率就知道当前模型的真实水平，而不是凭感觉觉得“好像还行”。
6.2 按一致率调整正面/负面阈值
脚本跑完之后，如果一致率低于 80%，优先调整阈值而不是改模型。实际操作是打印出每一条评论的原始score值，看那些被误判的样本分数集中在哪个区间。比如大量误判样本的分数集中在 0.45 到 0.6 之间，说明中性区间太长，把正面阈值从 0.6 提至 0.65、负面阈值从 0.4 降至 0.35，往往就能改善。这个操作不需要改模型，只改两个常量，但对演示效果的影响非常明显。
从那以后，我每接手一个情感分析类的源码包，都会强制走一遍这个流程：先建验证样本集，再跑对齐脚本，最后调阈值。这个习惯让我避开了很多“模型没毛病但表现很蠢”的尴尬局面。希望帮到你，拿到这套基于 Python 的旅游景点评论情感分析系统源码后，先从跑通开始，再按这个方法把结果修正到你可以放心演示的程度。
本文还有配套的精品资源，点击获取
