企业官网建设流程全解析

简介：这是一份基于Python与MySQL的网络舆情分析系统毕业论文资料包，主要面向计算机专业学生、毕业设计开发者以及需要开展网络言论管理的相关技术人员。论文从计算机技术对信息传播与言论发布的影响切入，阐明了舆情分析工作的现实需求，并完成了整个系统的设计与实现：系统采用Python语言开发，以MySQL作为数据存储介质，功能覆盖言论分析、言论管理、用户管理等模块，同时支持以城市或地区为关键词进行本地相关负面评论的快速检索与查看，为网络管理部门提供了高效、可落地的监测思路。资源包共1个文件，为docx格式文档，整体大小约1.73MB，文档中除论文正文外，还包含封面、独创性声明、中英文摘要等标准写作模板，便于使用者对照格式要求进行修改和提交。目前已有1262人学习下载，适合正在撰写舆情分析类毕业设计或希望系统了解Python+MySQL开发流程的读者，能够帮助快速搭建论文框架，并理解从数据库设计到业务功能实现的关键环节。

1. 基于python的网络舆情分析系统：一条从采集到预警的数据链路

基于python的网络舆情分析系统，乍看是课程设计或毕设题目，实际是一条从数据采集、清洗入库、文本分析到可视化预警的完整数据链路。它解决的并不是“爬虫能爬到多少数据”，而是“拿到数据之后怎么变成可读的舆情结论”：某事件在哪个平台发酵、负面占比多少、热度峰值出现在几点、源头是哪篇文章。适合三类人：准备做毕设但不想只交 demo 的学生、要给部门搭轻量舆情监控的运维或后端工程师、以及需要给论文补“数据库+算法”完整闭环的研究者。我给你的一个反直觉结论是：这个系统最耗时间的不是算法调优，而是数据采集稳定性和文本清洗，情感模型反而能用词典法先跑通。

2. 数据层设计与采集实现：先把舆情数据存进 MySQL

2.1 数据源与采集方案：先划定边界，再写爬虫

做舆情系统前先想清楚数据源边界。常见做法是优先选三种：新闻门户的滚动列表、公开评论区和搜索引擎的新闻聚合结果，这三类页面结构相对稳定、不需要登录、字段也够用。不要把目标一开始就定成“监控全网”，数据源越泛，清洗规则越难写，后期论文里也没法交代“数据从哪来、覆盖范围是什么”。

采集层我首选 requests + BeautifulSoup，不用一上来就上 Scrapy。原因很简单：小规模舆情系统的采集目标是“每天几千到几万条”，单机多线程请求足够；Scrapy 的中间件、Pipeline 在数据量上去之后才是收益，前期只会增加调试成本。下面这个脚本是一个新闻列表页的最小采集实现：

import requests from bs4 import BeautifulSoup import hashlib, json, time HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Referer": "https://news.sina.com.cn/" } def fetch_news_list(url, timeout=10): resp = requests.get(url, headers=HEADERS, timeout=timeout) # 不要把编码写死成 utf-8，优先用 apparent_encoding 兜底 resp.encoding = resp.apparent_encoding soup = BeautifulSoup(resp.text, "html.parser") items = [] for a in soup.select("a"): href = a.get("href", "").strip() title = a.get_text(strip=True) if not title or len(title) < 8: continue if not href.startswith("http"): continue # 用 md5(url) 作为去重指纹，比直接存 url 做索引快得多 uid = hashlib.md5(href.encode("utf-8")).hexdigest() items.append({"id": uid, "title": title, "url": href}) return items if __name__ == "__main__": base_url = "https://news.sina.com.cn/roll/#page_{}" for page in range(1, 3): data = fetch_news_list(base_url.format(page)) with open(f"news_{page}.json", "w", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2) time.sleep(1) # 限速是礼貌，也是反封的第一步

逻辑说明：resp.encoding 用 apparent_encoding 是为了避免某些页面 gbk 编码导致标题乱码；md5 指纹是为后面 MySQL 去重做准备，url 动辄几百字符，直接建索引会浪费空间。time.sleep(1) 是控制请求频率的最低成本手段，舆情采集不是抢购，不需要高并发。这个脚本只输出 json，还没入库，先看数据长什么样，再决定表结构。

2.2 MySQL 表设计：舆情主表、热度表、词典表

数据库选型上，MySQL 是舆情系统最稳的起步选择：事务保证写入不丢、SQL 查询方便、千万级数据加索引仍然可查。PostgreSQL 也很好，但如果你要给别人复现，MySQL 的普及度更高。不要在这个阶段引入 MongoDB，舆情数据的核心操作是按时间和来源做聚合，关系型数据库的 GROUP BY 比文档数据库更顺手。

建表时我推荐拆三张表：新闻文章表存原始内容，热度统计表存按小时聚合后的数据，词典表存自定义分词和情感词。拆表的原因是统计任务不应该反复扫全表，聚合结果单独存，报表直接查。下面是第一张表的建表语句：

CREATE DATABASE IF NOT EXISTS yq DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci; USE yq; CREATE TABLE news_article ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, uid CHAR(32) NOT NULL COMMENT 'md5(url) 去重指纹', title VARCHAR(255) NOT NULL, content MEDIUMTEXT, source VARCHAR(64) DEFAULT '', publish_time DATETIME NOT NULL, fetch_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, url VARCHAR(512) DEFAULT '', comment_cnt INT DEFAULT 0, like_cnt INT DEFAULT 0, UNIQUE KEY uk_uid (uid), KEY idx_publish_time (publish_time), KEY idx_source (source) ) ENGINE=InnoDB;

参数说明：uid 用 CHAR(32) 而不是 VARCHAR(512) 存 URL，是索引性能和存储空间的双重考虑；publish_time 上建普通索引，不建联合索引，因为后续查询基本是“某个时间范围 + 某个来源”，两个单索引足够。content 用 MEDIUMTEXT 而不是 TEXT，是给长文留余地。这里最容易踩的坑是：直接在 url 字段上建 UNIQUE KEY，utf8mb4 下 512 字符会超出索引长度限制，所以指纹字段必须单独建。

2.3 数据入库与幂等去重：同一篇新闻重复入库的问题

采集脚本跑起来之后，会遇到第一个实际麻烦：页面刷新后同一篇新闻反复抓到。如果不做去重，news_article 表会膨胀得很快，后面统计出的“舆情数量”全是虚的。解决思路不是查一遍再插，而是用数据库的唯一索引保证幂等。

import pymysql conn = pymysql.connect( host="127.0.0.1", port=3306, user="root", password="123456", database="yq", charset="utf8mb4", autocommit=False ) def save_batch(rows): sql = """ INSERT IGNORE INTO news_article (uid, title, content, source, publish_time, url) VALUES (%s, %s, %s, %s, %s, %s) """ with conn.cursor() as cur: # executemany 批量写入，比逐条 insert 快一个量级 cur.executemany(sql, rows) conn.commit()

逻辑说明：INSERT IGNORE 配合 uk_uid 唯一索引，重复的 uid 会被数据库直接丢弃，不报错、不影响批量导入。这样遇上去重逻辑时，不需要先 SELECT 再 INSERT，减少一次网络往返。常见误区是“我代码里先查一遍再插，不是更稳吗”，但实际上高并发下这种 check-then-insert 存在竞态，两条线程同时查到“不存在”然后同时插入，还是会重复。把去重交给数据库唯一索引，是舆情数据入库最省心的做法。

3. 舆情分析核心实现：分词、情感判定、热点聚类一条链路

3.1 中文分词与关键词提取：为什么 jieba 是默认起点

舆情分析的第一步是分词。中文分词的难点在于歧义和新词：比如“西安交大”可能被切成“西安”和“交大”，“yyds”这种网络热词在默认词典里根本不存在。jieba 虽然是老牌库，但胜在可控：支持自定义词典、支持词性标注、部署成本极低。不要一上来就上 HanLP 或 LTP，它们的模型更大、精度更高，但舆情分析的前期任务是快速建立基线，jieba 足够。

import jieba import jieba.analyse # 自定义词必须优先加载，否则品牌词会被切开 jieba.load_userdict("custom_dict.txt") text = "某手机品牌发布了新款旗舰机，但网友对该机型的续航表现吐槽较多" # 精确模式分词，适合做关键词提取和情感判定 words = jieba.lcut(text) print(words) # 基于 TF-IDF 提取 Top5 关键词，用于后续热点聚类 keywords = jieba.analyse.extract_tags(text, topK=5, withWeight=True) print(keywords)

参数说明：lcut 走的是精确模式，不会把“手机品牌”继续切成“手机”和“品牌”，对情感分析更友好。extract_tags 的 topK 控制每个文本保留几个关键词，我一般设 5，设太多会把“的”“了”这类停用词带回结果。custom_dict.txt 里每行格式是“词 词频 词性”，比如“某手机品牌 100 n”，这个词频不是必须准确，但给一个较大的数能提高词被合并的概率。如果发现舆情文案里品牌词总被切开，优先检查自定义词典，而不是换分词库。

3.2 情感分析：基于情感词典的正面、负面、中性判定

情感分析在舆情系统里是核心模块。可以用 Snownlp 直接跑，但我更推荐自写一个词典打分器：原因是词典法可解释性强，论文里能画清楚流程图；调阈值、加否定词都直观；后期数据量够了想换成深度学习，词典法还能作为标注基线。Snownlp 的问题是模型是通用的，对“某品牌降价”这种语境会误判为纯负面，而实际上消费者可能是在夸性价比。

import jieba POS_DICT = {"好评": 2, "稳定": 1, "流畅": 1, "性价比": 1} NEG_DICT = {"翻车": -2, "卡顿": -1, "续航崩": -2, "吐槽": -1} DEGREE_DICT = {"非常": 1.5, "很": 1.2, "有点": 0.8} NEG_WORDS = {"不", "没", "无"} def sentiment_score(text): words = jieba.lcut(text) score = 0.0 degree = 1.0 # 程度副词权重 neg = 1.0 # 否定词权重 for w in words: if w in NEG_WORDS: neg = -1.0 elif w in DEGREE_DICT: degree = DEGREE_DICT[w] elif w in POS_DICT: score += degree * neg * POS_DICT[w] degree, neg = 1.0, 1.0 elif w in NEG_DICT: score += degree * neg * NEG_DICT[w] degree, neg = 1.0, 1.0 return score print(sentiment_score("这款手机续航非常稳定")) # 正分 print(sentiment_score("续航一点都不稳定")) # 负分

逻辑说明：这个打分器的核心是“程度副词 + 否定词”的窗口机制。读到“非常”把 degree 置为 1.5，读到“不”把 neg 置为 -1，当下一个情感词出现时，把两者乘进去。词打分乘以负权重后，整体方向反转，这就是为什么“一点都不稳定”能被打成负分。参数说明：POS_DICT 和 NEG_DICT 的权重绝对值代表情感强度，建议范围 1~3，不要给太大，否则几条极端词就能淹没整篇文章的判断。这个简易版的问题在于多个否定词叠加（如“不是不好”）会被误判，实际项目中我加了连续否定词窗口，读到连续两个否定词就重置为正向。

3.3 热点聚类与话题追踪：用 TF-IDF 向量化再做聚类

舆情系统除了看单篇文章情感，还要回答“当前大家在讨论什么”。常见做法是把一段时间内的标题向量化，再做聚类。TF-IDF 向量化是为了把文本转成数字，KMeans 聚类是为了把相似话题归到同一组。为什么不直接用关键词匹配？因为同一个话题的表达方式太多，“某品牌手机发布会”和“某某旗舰机发布”在字面上不重叠，但向量空间里距离很近。

from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.cluster import KMeans import numpy as np titles = [ "某品牌发布新款旗舰机，售价大幅下调", "旗舰机价格战开打，某厂商跟进", "某品牌手机续航测试结果出炉", "发布会现场体验：新机手感轻薄", ] # ngram_range=(1,2) 保留词组；min_df=2 过滤只出现一次的词 vectorizer = TfidfVectorizer(max_features=10000, ngram_range=(1, 2), min_df=2) X = vectorizer.fit_transform(titles) km = KMeans(n_clusters=2, random_state=42, n_init=10) labels = km.fit_predict(X) # 每个聚类取 TF-IDF 权重最高的词作为话题标签 feature_names = vectorizer.get_feature_names_out() for i in range(km.n_clusters): centroid_idx = km.cluster_centers_[i].argsort()[::-1][:5] words = [feature_names[j] for j in centroid_idx] print(f"Cluster {i}: {', '.join(words)}")

参数说明：n_clusters=2 是基于“4 条标题最多两个话题”的人为假设，真实场景里需要用轮廓系数或手肘法确定；min_df=2 是把只出现一次的词过滤掉，避免单个文本的独特词影响聚类；n_init=10 是让 KMeans 多跑几次取最优，避免随机初始化带来的结果抖动。热点聚类的时效性要注意：舆情系统的聚类窗口我一般设 4 小时或 24 小时，窗口太短样本不够，太长话题已经变了好几轮。这个方案适合论文里的定性分析，如果要实时追踪热点演变，就得换增量聚类算法，但那是后话。

4. 可视化看板与预警规则：让舆情结果能看懂、能报警

4.1 用 Flask + ECharts 搭建最小舆情看板

舆情分析的结果最终要给两类人看：一类是技术负责人，关心数据量和模型准确率；另一类是业务或领导，只看趋势图和预警消息。给业务看的东西必须可读，我的做法是 Flask 提供 JSON 接口，前端用 ECharts 渲染，前后端分离但放在同一个项目里，省去跨域配置的麻烦。

from flask import Flask, jsonify import pymysql, json app = Flask(__name__) @app.route("/api/trend") def trend(): """返回最近 24 小时舆情数量趋势""" conn = pymysql.connect(host="127.0.0.1", user="root", password="123456", database="yq", charset="utf8mb4") with conn.cursor() as cur: cur.execute(""" SELECT DATE_FORMAT(publish_time, '%Y-%m-%d %H:00') AS hour, COUNT(*) AS cnt FROM news_article WHERE publish_time >= NOW() - INTERVAL 24 HOUR GROUP BY DATE_FORMAT(publish_time, '%Y-%m-%d %H:00') ORDER BY hour """) rows = cur.fetchall() conn.close() return jsonify([{"hour": r[0], "cnt": r[1]} for r in rows]) if __name__ == "__main__": app.run(host="0.0.0.0", port=5000, debug=False)

逻辑说明：这个接口的参数设计值得讲一下——DATE_FORMAT 按小时粒度聚合，把时间戳变成整点字符串，前端 ECharts 的 x 轴可以直接用；用 NOW() - INTERVAL 24 HOUR 而不是在 Python 里算时间，是为了让时间判断完全交给数据库，避免应用服务器与数据库服务器时区不一致导致“少一小时数据”的诡异问题。这也是舆情系统里很常见的一种“玄学 bug”，最后查出来是时区没对齐。接口只返回 JSON，图表渲染交给前端，ECharts 的折线图配置网上有很多模板，重点是数据接口稳定。

4.2 舆情预警规则：阈值、速率、突发敏感词三种触发

有了趋势数据，下一步是预警。舆情预警不能只做一个“超过 100 条就报警”的静态阈值，那样不是预警是噪音。我一般设计三层规则：第一层是数量阈值，比如单个时间窗舆情总数超过历史均值 1.5 倍；第二层是负面占比，比如一小时内负面情感占比超过 30%；第三层是敏感词突发，比如自定义敏感词在十分钟内出现次数超过日常均值 5 倍。这三层规则从“量变”到“质变”到“具体事件”，覆盖了大部分舆情场景。

def check_alert(total_now, total_hist, neg_rate_now, neg_th=0.3, rate_th=1.5): alerts = [] # 规则1：总量突增 if total_hist > 0 and total_now / total_hist > rate_th: alerts.append("总量突增") # 规则2：负面占比超阈值 if neg_rate_now > neg_th: alerts.append("负面占比过高") return alerts

参数说明：rate_th=1.5 意味着当前时间窗舆情数比历史同期多 50% 才报警。这个值不能拍脑袋定死，需要观察一周数据再调：如果每天都有几个时段误报，就调高到 2.0；如果该报警没报（漏报），就调低到 1.3。neg_th=0.3 是负面占比阈值，这个值受数据源影响很大：如果是采集新闻源，负面占比天然低，0.3 就偏高；如果是采集社交公开数据，负面情绪本就多，0.5 都不一定报警。所以预警规则一定要做成配置项，放数据库或配置文件里，不要硬编码在代码里。

4.3 日报导出：把数据库查询结果落成 Excel 文件

舆情系统的最终交付物往往是一份日报或周报：今天总舆情量、负面量、Top 热点话题、预警事件列表。用 pandas 加 openpyxl 直接导出 Excel 是最稳妥的交付方式，业务方可以在 Excel 里二次筛选，领导也能直接看。除了 pandas，还要装 openpyxl，光 pandas 只能写 csv，Excel 格式的导出需要这个库。

import pandas as pd from sqlalchemy import create_engine engine = create_engine("mysql+pymysql://root:123456@127.0.0.1:3306/yq?charset=utf8mb4") df = pd.read_sql(""" SELECT DATE(publish_time) AS day, COUNT(*) AS total_cnt, SUM(CASE WHEN sentiment = -1 THEN 1 ELSE 0 END) AS neg_cnt FROM news_article WHERE publish_time >= CURDATE() - INTERVAL 7 DAY GROUP BY DATE(publish_time) """, engine) df["neg_ratio"] = (df["neg_cnt"] / df["total_cnt"]).round(4) df.to_excel("舆情日报.xlsx", index=False, sheet_name="7日舆情趋势")

逻辑说明：这里用的 SQLAlchemy 连接串代替了之前的 pymysql 直连，主要是让 pandas 的 read_sql 能直接拿 DataFrame，省去逐行转换。CASE WHEN 在 SQL 里做条件计数，比先把全表查回来再在 Python 里 groupby 更省内存。注意 to_excel 的 sheet_name 参数，如果你不指定，默认叫 Sheet1，日报交付时最好把 sheet 名字改成业务能看懂的内容。Excel 导出是舆情系统里“做了没人夸、漏了被人骂”的功能，但它恰恰是论文里“系统应用”章节最好写的部分。

5. 舆情系统落地避坑记录：5 条压测才暴露的数据库与调度问题

5.1 采集端被限制或返回乱码：现象、成因与处理

现象：采集脚本跑了十几分钟后，返回的页面从正常列表变成验证页，或者标题全是乱码。第一次遇到时我以为是反爬，查了半天才发现是编码问题。成因有两类：一是没有带 Referer 或 User-Agent，被服务器识别为脚本；二是页面本身是 gbk 编码，代码里 resp.encoding 固定写成 utf-8，导致标题乱码。解决：头部信息至少带真实浏览器的 UA，Referer 填首页地址；编码不要写死，用 resp.apparent_encoding。采集频率用限速控制，不做并发轰炸，大多数新闻站的容忍度比想象中高，问题出在频率不稳定，时快时慢才容易被限制。

5.2 数据库连接池被打满与慢查询：另一个隐蔽坑

现象：多线程采集开起来后，程序报 “Too many connections”；第二天看数据库，统计接口响应时间从 50ms 涨到 3 秒。原因：代码里每个线程每次写入都新建 pymysql 连接，用完后只 close 了游标没有关连接；聚合查询 group by publish_time 时没有索引。解决：全局维护一个连接池，用 pymysql 的 connections 模块或直接改用 SQLAlchemy 的连接池；给 publish_time 和 source 建普通索引。这个问题的隐蔽性在于单线程时一切正常，一旦并发上去连接数翻倍，MySQL 默认 max_connections 是 151，很快就会被耗尽。

5.3 情感词典翻车：语境迁移时准确率骤降

现象：情感分析模型在测试集上准确率 78%，上线后发现“某品牌续航翻车”被判成中性。原因是词典里没收录“翻车”这个词，或者“翻车”被 jieba 切成了“翻”和“车”。解决：把业务场景里出现的高频词人工加入词典和情感词表，比如数码领域要加“续航、快充、发热、掉电”，食品领域要加“卫生、口感、配料”。我后来养成的习惯是：每周从数据库里随机抽 50 条新舆情，人工标注后对比模型结果，把误判的词补进词典。这一步是纯人工活，但却是词典法准确率的直接上限。

5.4 预警规则太灵敏导致的告警疲劳

现象：预警功能上线第一天，钉钉群被刷了 40 条消息，第二天没人看，真出事时反而被忽略。原因是阈值设得太低，加上没有做同源合并——同一个事件被多个新闻站转载，每个站点都触发一次预警。解决：预警规则里加静默期，同一事件 30 分钟内只推送一次；阈值要从历史数据的分位数算，而不是拍脑袋定。比如统计过去 30 天每天同时段的舆情量，取 95 分位数作为阈值基线，远比你拍一个“100 条”靠谱。告警疲劳是舆情系统最常见的“看起来做了很多、实际没人用”的原因。

5.5 文本清洗的疏漏：HTML 标签和表情符号污染情感分数

现象：有几天负面率异常偏高，抽了几条数据发现内容是“续航真不错😡”，这明显是矛盾表达，但情感打分器把“不错”算成正向，表情符号又被清洗逻辑删掉。原因：表情符号其实携带很强的情感信息，不能简单只按文本词典打分，需要单独提取表情符号做二次修正。解决：清洗时把 HTML 实体和标签去掉，但把表情符号单独存一列，后续作为情感分析的一个附加特征；对“文字正向 + 表情负向”的组合，给一个负向偏移。这类问题不靠算法解决，靠的是你在清洗阶段多留一个心眼。

6. 评估舆情系统到底准不准：从留存语料到冷启动调参

6.1 用 200 条标注语料跑一套半小时的留存评估

舆情系统上线前，我建议先留出 200 条已经人工标注的舆情文本，永远不要用这些数据去调情感词典——它们只用来评估。评估指标看三个：准确率、召回率、F1，尤其要看负向样本的召回率。舆情场景里负面事件漏报的代价远大于误报，所以我不只看总体准确率，而是单独算“负向 F1”。

def evaluate(y_true, y_pred): # y_true/y_pred 都是 list，元素为 1 或 0，1 表示负面 tp = sum(1 for t, p in zip(y_true, y_pred) if t == 1 and p == 1) fp = sum(1 for t, p in zip(y_true, y_pred) if t == 0 and p == 1) fn = sum(1 for t, p in zip(y_true, y_pred) if t == 1 and p == 0) precision = tp / (tp + fp + 1e-9) recall = tp / (tp + fn + 1e-9) f1 = 2 * precision * recall / (precision + recall + 1e-9) return precision, recall, f1

逻辑说明：我加 1e-9 只是防除零，实际数据里这个分母几乎不会为零。加这一行的真实原因是之前有一次评估线上舆情数据，某个时段全是正向样本，tp+fp 等于 0，直接 ZeroDivisionError，日志里留下一堆报错。负向样本在真实舆情里占比通常只有 10% 左右，所以只看总体准确率没有意义——模型全预测正向也能有 90% 准确率，但舆情系统等于废了。

6.2 两小时冷启动调参：从词典到阈值的一轮循环

冷启动阶段没有标注数据怎么调？我的习惯是先用词典法跑通全流程，把系统输出的每条结果人工抽检 50 条，记录错误类型；如果是词典缺词，补词典；如果是阈值不合理，调整阈值；如果是“不”“没”这类否定词处理不对，检查否定词窗口。这一轮循环下来，情感分析的负向 F1 能从 0.3 涨到 0.7 左右，已经达到舆情系统可用基线。还有一个重要习惯：任何模型改动，都必须先跑一遍 6.1 的留存语料对比新旧结果，再上生产。这个习惯帮我挡过不少“改了个词典，全站预警刷屏”的翻车事故。舆情系统的效果不是靠一个模型撑起来的，而是靠数据链路每一环的细节堆出来的，一步步把每个环节做扎实，结果自然会说服人。希望帮到你。

本文还有配套的精品资源，点击获取