做毕业设计最怕的不是写代码，而是选题选到一半发现做不下去。电商评论情感分析这个方向，属于典型的“看着热门、做着顺手、答辩好讲”的题目：既有 Django 这种成熟 Web 框架撑起系统界面，又有机器学习模型撑起核心算法，还能挂上大数据的边——数据量一大，清洗和特征工程就有得聊。我这两年接触过不少类似的毕设项目，也帮人调试过源码、改过模型，今天就把这个项目的完整拆解、技术选型、实现流程和避坑经验一次性讲清楚。不管你是准备开题、正在开发，还是拿到一份源码想跑通，这篇内容都能直接用上。
这个项目本质上做的是三件事：把电商平台的用户评论收集起来，用机器学习模型判断每条评论是正向还是负向（有的还带中性），最后把分析结果用图表和关键词统计的方式展示在网页上。整体不算复杂，但对 Django、机器学习、数据处理、前后端协作都有覆盖，非常适合作为一个提前感受“完整项目长什么样”的练手作品。
1. 项目选题与整体功能拆解
1.1 为什么这个选题值得做
毕业设计最忌讳的是“大而空”和“难而上头”。电商评论情感分析刚好卡在中间：复杂度够，但不至于让人头发掉光。它的好处有几个方面，我一条条说。
第一，数据获取门槛低。电商评论数据在很多公开数据集、比赛平台、学术数据共享站里都能找到，也可以自己整理一份脱敏的 Excel 表格，服务端从 CSV 导入就能开始处理。对比目标检测、语音识别这类需要采集和标注大量样本的方向，评论数据的可得性和可控性都强很多。
第二，算法路线清晰。情感分析在中文 NLP 里属于成熟任务，不需要从零造轮子。哪怕只用 jieba 分词 + TF-IDF 特征 + 朴素贝叶斯分类器，也能跑出八九十的正确率。答辩时你讲得清楚原理，老师听得明白逻辑。
第三，展示效果好。Django 页面加上 ECharts 饼图、柱状图、词云，视觉效果拉满，评审老师一眼就能看出系统功能是完整的。比起纯算法调参、输出一个准确率数字，这种“看得见摸得着”的系统更容易拿到好印象。
第四，扩展空间大。如果你后续想升级，可以把朴素贝叶斯换成 LSTM，也可以加时间趋势分析、商品维度对比，甚至做成实时情感监控大屏。毕设题目本身不会限制你的发挥。
1.2 系统核心功能模块划分
我通常会把整个系统拆成五个模块，这样开发的时候思路清晰，答辩的时候也好分块讲：
- 用户模块：登录、注册、会话管理。大多数毕设系统都有这部分，用来体现系统的完整性和权限控制能力。
- 评论管理模块：支持评论数据的导入（CSV/Excel）、手动新增、删除、批量导入，并提供分页查询和关键词筛选。
- 分析引擎模块：这是核心，负责对评论进行预处理、分词、特征提取、模型预测，最终输出每一条评论的情感标签（正面、负面、中性）和置信度。
- 数据统计模块：按商品、按时间段统计情感分布，计算好评率、差评率，生成趋势数据。
- 可视化展示模块：用 ECharts 渲染饼图、柱状图、折线图，用词云展示高频关键词。
这个划分不是拍脑袋想出来的。每个模块都有明确的职责，开发时可以并行开工，调试时出了问题也能快速定位是前端、后端还是算法层的事。实际写代码时，我建议先做分析引擎的模型脚本，再做 Django 的评论管理和可视化，最后补用户模块。因为分析引擎是核心，先跑通它，整个项目心里就有底了。
2. 技术选型：Django 与机器学习如何配合
2.1 为什么选 Django 而不是 Flask 或 Spring Boot
先说结论：做这种毕设项目，Django 在大多数情况下是更省心的选择。Flask 确实更轻，但很多功能（ORM、Admin 后台、表单处理、分页）都要自己找第三方库拼装，开发效率会低一些。Spring Boot 功能强大，但 Java 体系学习成本高，对 Python 生态的机器学习库支持也不好。
Django 最大的优势是“全家桶体验”。它的 ORM 能把数据库操作封装得极其顺手，Django Admin 自带后台管理界面，登录验证有现成框架，CSRF 防护默认开启，安全性上不会被老师挑毛病。更关键的是，Django 和 Python 机器学习生态是无缝衔接的：你用 sklearn 训练好模型，可以直接用 joblib 保存成文件，然后在 Django 视图里加载、调用，不需要额外做接口中转。
有人可能会问，模型怎么能直接跑在 Web 服务里？答案是 Django 本身就是 Python 进程，加载模型文件就是一次内存操作。你把训练好的 model.pkl 放在项目目录下，写一个模型服务类，视图函数调用它的 predict 方法就行。这种“算法脚本 + Web 框架直连”的架构，比 Flask 拆微服务、比 Java 调 Python 服务都简单得多，特别适合毕设的系统规模。
2.2 情感分析模型选型思路
模型选型是整个项目里最值得花时间对比的环节。我给出一个适合毕设的路线：优先做传统机器学习分类，不要一上来就冲深度学习。
具体来说，推荐方案是 jieba 分词 + TF-IDF 向量化 + 朴素贝叶斯或逻辑回归。理由如下：
- 朴素贝叶斯训练快，对小样本数据集非常友好，几千条评论几秒钟就能训练完。
- 逻辑回归可解释性强，权重大的词语能直接当作分析依据，答辩时可以拿来说明“模型学到了什么”。
- TF-IDF 能天然降低“的、了、是”这类停用词的影响，不需要额外做太复杂的过滤。
- 相比 LSTM、BERT，传统机器学习在 CPU 环境就能跑，不需要 GPU，也不需要在答辩现场演示时担心显存或环境问题。
当然，如果你想要一点亮点，可以把模型升级为 BiLSTM 或用预训练模型做微调，但作为毕设来说，传统模型训练快、解释清楚、效果稳定，已经足够了。我在实际调试中见过很多项目强行上 BERT，结果不是训练时间太长就是模型文件太大没法部署，最后还得退回传统方案。所以我的建议是：先把朴素贝叶斯跑通，有余力再往上升级，给自己留一条稳妥的后路。
2.3 数据存储与运行环境搭配
数据存储方面，开发阶段用 SQLite 就够了，零配置，文件型数据库，Django 默认支持。等你要部署给别人演示或需要多人同时访问时，再换 MySQL。评论数据量在几万条以内，SQLite 完全扛得住，查询速度也不会有明显问题。
运行环境的搭配，我列一份我实际用过的组合：
- 操作系统：Windows 10/11 或 Ubuntu 20.04 都可以
- Python 版本：3.8 以上，建议 3.9 或 3.10
- Django 版本：4.2 LTS（稳定且资料多）
- 机器学习库：scikit-learn、jieba、pandas、numpy
- 可视化库：pyecharts 或前端 ECharts + 后端 JSON 数据接口
有一点要特别注意：Django 4.x 对 Python 版本有要求，Python 3.8 以下可能装不上最新版。其次，scikit-learn 和 numpy 的版本也会有兼容性问题，建议用 pip 一次性安装 requirements.txt，避免一个个装最后版本冲突。
3. 数据库设计与评论数据准备
3.1 数据表设计
系统数据表不要设计得太复杂，满足业务逻辑就好。我常用的表结构有三张：
用户表：用 Django 自带的 User 模型就行，扩展一个头像或昵称字段就够了，不需要自己重写认证逻辑。
商品表：字段包括商品名称、商品链接、所属分类、创建时间。这个表主要用来按商品维度统计情感分布。
评论表：这是整个系统的核心表。字段包括评论内容、评论评分、评论时间、所属商品、情感标签（正面/负面/中性）、置信度、是否已分析。
一开始很多同学会把情感标签直接存在评论表里，这没问题，但我要提醒一句：如果以后要支持“不同模型分析结果对比”，最好单独建一张分析记录表，把模型名称、版本、预测结果、预测时间都存下来。这样虽然多了一张表，但系统扩展性会好很多。不过毕设如果不做模型对比，评论表里直接存预测结果也够用，没必要过度设计。
3.2 评论数据的获取与清洗
评论数据从哪里来，这个问题经常让新手卡住。我的建议是分三种情况处理：
第一，用公开数据集。国内一些开源社区、比赛平台有电商评论数据集，比如商品评论 CSV、带情感标注的语料，可以直接下载。这类数据通常已经很规范，字段包含评论文本和情感标签，拿来训练模型最省事。
第二，手工整理一份演示数据。如果你只需要系统跑通和展示，完全可以自己编几千条有代表性的评论，或者从自己真实网购体验里整理并脱敏。虽然没有标注，但可以用评分字段代替情感标签：1-2 星是负面，3 星中性，4-5 星正面。
第三，有条件的可以用电商平台开放接口或自有业务数据，但我不建议在毕设里去爬大型平台的真实评论。一方面有合规风险，另一方面爬下来的数据噪音很大，你需要大量时间做清洗，反而不划算。
数据清洗是决定模型效果的关键步骤。我在做这个项目时总结了几个必做的清洗操作：
- 去除评论中的 HTML 标签、URL、乱码字符
- 去掉重复评论（很多用户会一键复制粘贴）
- 把全角字符转半角
- 处理表情符号，要么删除要么替换成对应文字（比如“开心”）
- 过滤掉评论长度过短的，比如少于 2 个字符的无效评论
清洗后的数据格式统一为 CSV，两列：content（评论内容）和 label（情感标签，0 负面 / 1 正面 / 2 中性）。这是我个人偏好的标准格式，因为 pandas 和 sklearn 都能直接加载，模型训练脚本和 Django 导入脚本可以共用这份文件。
3.3 中文评论预处理细节
中文评论和英文评论最大的区别是没有天然的分隔符，所以分词是必须的一步。我用 jieba 已经三年多了，稳定性非常好，但有几个细节要特别注意：
第一，加载停用词表。停用词建议从网上下载一个通用的中文停用词表，并手动补充电商领域的常见词，比如“商品、东西、感觉、真的、就是”这类对情感判断帮助不大的词。注意不要过度过滤，不要把“不好、太差”里的“不”去掉，否则情感就反了。
第二，自定义词典。如果数据集中在某个领域，比如美妆、数码，可以自定义词典把“性价比”“大牌”“剁手”这类词合到一起，分词会更准确。这个操作非常简单，jieba.load_userdict 一个方法就能搞定。
第三，针对“否定词 + 情感词”的组合，比如“不好”“不行”“不高兴”，如果只做统计特征，朴素贝叶斯也基本能处理，但如果你想提高准确率，可以在预处理阶段把否定词和后面的形容词拼接起来，比如“不_高兴”，让模型更容易学到这种模式。这是老 NLP 玩家常用的 trick，但对新手可能有点抽象，我的建议是：先不分，看效果，如果负面评论误判很多再加。
预处理脚本建议单独放在一个 utils/text_preprocess.py 文件里，不要和 Django 视图混在一起写。因为训练脚本要用它，预测接口也要用它，抽出来复用就不会出现“训练时一套处理、预测时另一套处理”的乌龙。
4. 情感分析模型训练全过程
4.1 TF-IDF 特征构建与模型训练代码
模型训练这一部分，我会按实际代码流程讲一遍。假设你已经有了清洗好的 CSV 文件，训练脚本的完整逻辑是：读取数据、分词、TF-IDF 向量化、划分训练集和测试集、训练模型、评估效果、保存模型。
核心代码大致如下：
import jieba import pandas as pd from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.naive_bayes import MultinomialNB from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report import joblib # 读取清洗后的数据 df = pd.read_csv("comments_clean.csv") X = df["content"].tolist() y = df["label"].tolist() # 中文分词函数 def cut_words(text): return " ".join(jieba.lcut(text)) # 对所有评论分词 X_cut = [cut_words(text) for text in X] # TF-IDF 向量化，max_features 控制特征维度 vectorizer = TfidfVectorizer(max_features=8000) X_vec = vectorizer.fit_transform(X_cut) # 划分训练集和测试集 X_train, X_test, y_train, y_test = train_test_split( X_vec, y, test_size=0.2, random_state=42, stratify=y ) # 训练朴素贝叶斯模型 model = MultinomialNB(alpha=1.0) model.fit(X_train, y_train) # 评估 y_pred = model.predict(X_test) print(classification_report(y_test, y_pred, target_names=["负面", "正面", "中性"])) # 保存模型和向量器 joblib.dump(model, "models/sentiment_model.pkl") joblib.dump(vectorizer, "models/tfidf_vectorizer.pkl")这个脚本我实测过很多次，数据量 5000 条以上、三类标签均衡时，准确率普遍在 85% 以上。如果数据不平衡，比如正面评论特别多、负面评论很少，一定要在 train_test_split 里加 stratify=y，或者用加权参数 class_weight 来平衡，否则模型会偏向多数类，所有评论都预测成正面。
4.2 特征维度与参数调节思路
TF-IDF 里的 max_features 是我建议第一个调节的参数。默认不设置时，特征数量可能是几万甚至十几万，维度太高训练慢而且容易过拟合。设置为 8000 或 10000 是通用经验值。判断是否合适的方法很简单：打印分类报告，如果模型在测试集上的表现明显差于训练集，就说明过拟合了，需要减小 max_features；如果两者都不高，说明特征太少了，加大这个参数或者补充训练数据。
朴素贝叶斯的 alpha 参数是平滑系数，默认 1.0 不用动。你可以试着从 0.1 到 2.0 搜索一遍，看看对准确率的影响，但通常变化不大。
另外一个容易被忽略的问题是 jieba 分词结果的一致性。训练时用的是 jieba.lcut 默认词典，预测时如果用同一个函数处理，一般不会出问题。但如果预测代码里没有加载和使用同一个词典，或分词函数里加了一些额外操作，就可能导致线上预测结果和训练时不一致，准确率明显下降。这是很多源码调不通的隐性原因，我见过好几个项目都是倒在这一步上。解决方法是把 cut_words 这个函数直接复制到 Django 的工具模块里，保证完全一致。
4.3 模型持久化与调用方式
训练好的模型用 joblib.dump 保存成文件，在 Django 项目里如何加载？
我推荐的方式是写一个单例类，模型的加载只做一次，不要每次请求都重复读文件。
import os import joblib class SentimentAnalyzer: _instance = None def __new__(cls): if cls._instance is None: cls._instance = super().__new__(cls) cls._instance._load_models() return cls._instance def _load_models(self): base_dir = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) self.model = joblib.load(os.path.join(base_dir, "models", "sentiment_model.pkl")) self.vectorizer = joblib.load(os.path.join(base_dir, "models", "tfidf_vectorizer.pkl")) def predict(self, text): from utils.text_preprocess import cut_words vec = self.vectorizer.transform([cut_words(text)]) proba = self.model.predict_proba(vec)[0] label = int(self.model.predict(vec)[0]) confidence = float(max(proba)) return label, confidence这个写法的好处是：模型文件路径不会写死成绝对路径，换机器也能跑；模型只加载一次，响应速度不需要每次都去磁盘读文件。predict_proba 返回的是各类别的概率，取最大值作为置信度，这个信息可以存到数据库里，在网页上展示“这条评论是负面，置信度 92%”，会比直接显示一个标签更有说服力。
5. Django 集成与可视化展示
5.1 后端视图与路由设计
Django 的工程结构建议按功能拆 app，不要所有模型写在一个文件里。我常用的拆法是：
- app 名称 users：注册登录
- app 名称 comments：评论管理、数据导入
- app 名称 analysis：模型加载、情感分析调用
- app 名称 dashboard：统计与可视化页面
每个 app 各管各的事，路由分配也很清晰。比如 /comments/list 是评论列表页，/comments/import 是导入数据接口，/dashboard/overview 是统计总览页。这种命名方式答辩时说起来也顺口。
关键的视图逻辑是：用户在页面上选择商品、点击“分析未处理评论”，后台遍历该商品下所有 status 为未分析的评论，调用 SentimentAnalyzer.predict 逐条预测，把结果写回数据库。这里要注意，如果评论量很大，不要在前台请求里同步做全部预测，否则页面会卡很久。简单处理方式是先用小数据量演示，或者把预测放到一个单独的视图里用异步方式触发。毕设场景下，几千条评论同步预测也就几秒钟，可以接受，但一两万条以上就得考虑分批处理了。
5.2 ORM 查询里的性能小坑
Django ORM 用起来方便，但在列表页展示评论时有一个经典坑：N+1 查询。比如评论表关联商品表，你遍历评论去取所属商品名称，Django 默认会对每条评论执行一次商品查询，几千条评论就会产生几千条 SQL，页面加载慢得让人怀疑人生。
解决办法是查询时加 select_related：
comments = Comment.objects.select_related("product").filter(status=2)这一行能让 Django 使用 SQL JOIN 把商品信息一次性查出来，查询次数从几千次变成一次。这个优化虽然小，但答辩时能说出来会显得你确实有生产经验。
分页方面，用 Django 自带的 Paginator 就行。每页 20 条，模板里用页码导航，数据量再大也不怕。切忌一页渲染几千条数据，浏览器直接卡死。
5.3 统计报表与词云展示
可视化部分我建议采用前后端分离的数据接口方式：Django 返回 JSON，ECharts 在前端渲染。
后端写一个统计接口，返回如下格式：
{ "labels": ["正面", "负面", "中性"], "values": [320, 45, 87], "goods_stats": [ {"name": "商品A", "positive": 90, "negative": 5, "neutral": 5} ], "hot_words": [ {"name": "质量", "value": 120} ] }前端用 Ajax 拉取这个 JSON，然后填充到 ECharts 的饼图和柱状图里。词云可以用 echarts-wordcloud 插件，输入热点词及其频次即可。
关于统计 SQL，用 Django ORM 的 aggregate 和 annotate 方法就能实现。按商品统计情感分布，一行代码搞定，不要写原生 SQL：
from django.db.models import Count result = Comment.objects.values("product__name", "sentiment").annotate( count=Count("id") )这段代码会返回每个商品、每个情感标签的数量，前端自己组装成图表数据即可。
6. 实操中的常见问题与排查技巧
6.1 源码跑不起来的经典原因
我在调试定制服务时遇到的第一个高频问题，就是环境不一致导致项目跑不起来。最常见的错误是：项目在 Python 3.6 下开发，你本地装的是 Python 3.10，跑起来报一堆语法错误或版本冲突。解决办法是严格按照 requirements.txt 安装依赖，并检查 Django、sklearn、numpy 的版本是否匹配。如果实在装不上，就新建一个 Python 3.8 的虚拟环境，一劳永逸。
第二个高频问题是模型文件缺失。很多源码里只放了训练脚本，没放训练好的 .pkl 文件，你拿到手之后还得自己训练。训练本身不难，但要记得训练完必须同时保存 model 和 vectorizer，不然预测时调用 transform 会报维度不一致的错误。
第三个问题是数据库结构没迁移。Django 的项目源码里如果带了 models.py，但没有 migrations 记录，或者你在新机器上直接运行，就会报没有表。解决办法是运行基础的三连命令：
python manage.py makemigrations python manage.py migrate如果还提示缺少字段，说明数据库版本和模型不同步，需要清空数据库再重新迁移。开发阶段用 SQLite 的话，直接把 db.sqlite3 删掉重建最快。
6.2 中文乱码与编码处理
电商评论数据里中文乱码是最常见的问题，特别是在 Windows 平台下。根源基本都是 CSV 文件的编码和 pandas 读取时的编码不匹配。CSV 文件是 UTF-8，但 Excel 打开保存后变成了 GBK，然后 pandas 读进来就是一堆乱码。
统一的做法是：在读 CSV 时显式指定编码：
df = pd.read_csv("comments_clean.csv", encoding="utf-8")如果报错 UnicodeDecodeError，就改成：
df = pd.read_csv("comments_clean.csv", encoding="gbk")最稳妥的方式是，把所有数据文件都转换为 UTF-8 编码后再导入数据库。Django 连接 MySQL 时，也要在 settings.py 里设置编码：
DATABASES = { "default": { "ENGINE": "django.db.backends.mysql", "NAME": "sentiment_db", "USER": "root", "PASSWORD": "123456", "HOST": "127.0.0.1", "PORT": "3306", "OPTIONS": {"charset": "utf8mb4"}, } }注意用 utf8mb4 而不是 utf8，因为真正的 utf8 在 MySQL 里不支持四字节字符，遇到表情符号会直接报错。
6.3 情感预测结果与直觉不符怎么办
有时候你人工看一条评论明显是负面的，模型却预测成正面，这是情感分析项目里最容易被老师质疑的场景。处理这类问题我有一套流程：
第一，先看这条评论的置信度。如果置信度只有 0.5 左右，说明模型本来就没把握，属于边界情况，不用太纠结。
第二，检查分词结果。打印出 jieba 分词后的词序列，看是不是把关键的词切错了。比如“不划算”被切成“不划/算”，特征就丢了。
第三，检查停用词表。如果停用词表里误加了“不”这类否定词，或者“太”“很”这类程度副词，模型就失去了判断情感强度的信息。遇到这种情况，把否定词和程度词从停用词表里删掉。
第四，扩展训练样本。收集数据里被误判的评论，人工修正标签后加入训练集重新训练。这是最朴素也最有效的纠错手段，所谓“bad case 回流”，能让模型越用越准，也是生产环境里迭代模型的通用思路。
6.4 页面加载慢与小数据量卡顿
如果统计页面图表加载很慢，先排除网络原因，再看接口返回数据的耗时。一个常见坑是可视化统计时对每条评论的动态渲染做了循环判断，比如模板里写了一大堆 if 条件，导致渲染时间长。解决办法是后端把数据准备好，前端只负责展示，不要在模板里做复杂运算。
还有一个 Qt 相关的问题顺带提一句，有些同学会把表格卡顿优化写成 qtableview 自定义 model，那是桌面端方案，和 Django 没关系。Web 端如果有大数据表格卡顿，优先用后端分页 + 前端页码导航，实在要展示大量行的，再用虚拟滚动方案。毕设场景下，后端分批返回数据就够了。
7. 部署上线与项目扩展建议
7.1 本地开发环境快速搭建
如果你是新手，第一次跑这个项目，我建议按以下顺序操作：
- 安装 Python 3.9，勾选 Add to PATH
- 创建虚拟环境：python -m venv venv
- 激活虚拟环境：Windows 执行 venv\Scripts\activate
- 安装依赖：pip install -r requirements.txt
- 数据库迁移：python manage.py migrate
- 创建管理员账号：python manage.py createsuperuser
- 启动服务：python manage.py runserver
这时浏览器访问 http://127.0.0.1:8000 就能看到系统首页，Django Admin 后台用刚才创建的管理员账号登录。如果页面能正常打开，模型文件也存在，说明整个系统已经跑通了。
7.2 部署到公网演示的简化方案
毕设最终可能需要部署到服务器上给老师演示。我不推荐一上来就折腾 Nginx + uWSGI，因为面试官大概率不会检查你的部署配置，但系统能在线访问确实是加分项。我建议的方式是：买一台最低配的云服务器，装好 Python 环境和项目依赖，直接使用 Django 的开发服务器加上允许外部访问的方式运行：
python manage.py runserver 0.0.0.0:8000 --insecure这种方式只适合演示，不安全，也不能承受并发，但作为毕设演示完全够用。等答辩结束再关掉就行。如果你想正经部署，再用 gunicorn + Nginx，但在毕设场景下，把核心功能做扎实比折腾服务器环境更有价值。
7.3 项目可以继续扩展的方向
如果你做完了基础版本还有时间和精力，我建议考虑以下几个扩展点，每一个都能在答辩时形成亮点：
- 多模型对比：在系统里加入逻辑回归、SVM 或者 LSTM 模型，做一个模型效果对比页面，展示准确率、精确率、召回率。
- 评价维度细分：不止区分正负面，还可以识别“物流快”“质量好”“客服差”这类属性级情感，需要用依存句法或规则匹配，适合能力强的学生挑战。
- 时间趋势分析：按月份统计好评率变化，形成折线图，能发现商品口碑随时间的变化规律。
- 实时分析：接入消息队列或者用 Celery 异步任务，让用户提交评论后实时返回情感结果，交互感更强。
- 数据大屏：把统计结果做成大屏展示，背景、图表、动效都调好，视觉效果极其惊艳，老师看到第一眼就会觉得项目完成度高。
我个人在实际调试这类项目时体会最深的一点是：情感分析项目的瓶颈，往往不在模型本身，而在数据和工程细节。数据干净、特征处理好，朴素贝叶斯也能出很好的效果；数据一团糟，再牛的模型也白搭。做这个毕设，你在数据清洗、模型训练、Web 集成这些环节里积累的完整经验，才是真正比别人值钱的东西。
最后再分享一个实际发生的案例。我帮一个同学调试的时候，发现他所有的负面评论都预测成了正面，排了一整天没找到原因，最后发现是 CSV 文件里 label 列的值写反了：1 是正面，0 是负面，但训练脚本里把 0 映射成了负面，1 映射成了正面，数据本身又是旧的，排查起来特别折磨人。后来我把标签映射和代码逻辑全部对齐，才恢复正常。所以无论你的模型效果多差，先检查数据标注和代码逻辑的一致性，再考虑调参，这个思路能节省你非常多的排查时间。
