企业官网建设流程全解析

简介：这是一套面向开发者、数据分析人员及中小企业技术团队的开源舆情监测系统源码与配套数据库，适合预算有限但需要本地化部署舆情分析能力的场景。系统覆盖数据采集、清洗处理、深度分析与可视化展示等完整模块，可对新闻、博客、社交媒体等渠道的公众情感与热点话题进行实时监测，帮助用户快速提取品牌声誉、舆论趋势等有价值信息。压缩包共2000个文件，以1757个js脚本、131个css样式、64个html页面为主，另含xml、json配置及少量文档，整体约45.13MB，目录结构清晰，便于二次开发与定制。目前已有724人学习下载。借助完整源码与数据库，读者可掌握舆情系统的架构设计与模块协作方式，理解关系型与非关系型数据库在数据存储和查询效率上的取舍，并在此基础上进行功能扩展或私有化改造，适用于市场研究、公共关系与网络安全等方向。

1. 舆情系统源码拿到手之后：先搞清楚它到底在解决什么问题

很多人搜「开源免费的舆情系统源码+数据库」，脑子里想的是一套能直接跑起来、界面好看、数据自动往里灌的成品。实际拿到源码之后，第一反应往往是懵的——目录一大堆，配置文件散在各处，数据库脚本藏在某个sql文件夹里，README 写得像天书。这不是你水平不行，而是舆情系统本身就是一个「数据采集 + 清洗 + 存储 + 检索 + 分析 + 可视化」的复合体，任何一环没对齐，整套就跑不通。

我见过太多人卡在第一步：源码下载了，数据库也装了，但就是不知道先动哪里。这篇东西就是按我自己的落地顺序写的——从环境选型、数据库建表、采集入库，到检索分析和踩坑排查，每一步都给出可复现的命令和参数。适合手里已经有一份舆情系统源码、想把它真正跑起来并投入使用的后端或数据方向工程师，也适合正在做数据库课程设计、想拿舆情系统当选题的学生。读完你至少能判断：这套源码值不值得改，改哪里收益最大，哪些坑可以提前绕开。

2. 环境选型与数据库落地：别在第一步就把自己埋了

2.1 为什么舆情系统默认选 MySQL 而不是 SQLite

舆情系统的数据模型有一个很明显的特征：写入频繁、读取以时间范围和多条件过滤为主、单条记录不大但总量增长快。采集端可能每分钟往posts表里塞几百上千条，分析端又要按关键词、时间窗口、情感标签做聚合查询。这种读写混合场景下，SQLite 的写锁会成为瓶颈——它同一时刻只允许一个写操作，采集线程一多就开始排队，表现就是「采集日志显示成功，但数据库里查不到最新数据」。

MySQL 的 InnoDB 引擎支持行级锁和并发写，配合连接池能扛住采集端的持续写入。常见做法是采集服务和分析服务用不同的数据库账号，采集账号只给INSERT和UPDATE权限，分析账号只给SELECT，这样即使分析端写了慢查询，也不会把采集端拖死。

选版本的时候，MySQL 5.7 和 8.0 在舆情系统里差别不大，但 8.0 的窗口函数和 CTE 在写情感趋势分析时能省不少子查询。如果源码里的 SQL 用了ROW_NUMBER()这类函数，就必须上 8.0。我一般会先翻一遍源码里的mapper或dao层，看有没有窗口函数，再决定装哪个版本。

2.2 建库建表：从源码的 SQL 文件反推数据模型

拿到源码后，先找数据库脚本。通常在doc/、sql/、db/或resources/下面，文件名可能是init.sql、schema.sql、create_table.sql。找到之后不要直接一把梭执行，先看三件事：字符集、引擎、索引。

-- 先看建表语句的字符集和引擎，舆情系统必须用 utf8mb4 SHOW CREATE TABLE posts; -- 如果源码里写的是 utf8，中文和 emoji 会出问题，改成 utf8mb4 ALTER TABLE posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 检查关键索引是否存在，没有就补 -- 舆情系统最常用的查询是「按时间范围 + 关键词」 ALTER TABLE posts ADD INDEX idx_pubtime_source (publish_time, source_id); ALTER TABLE posts ADD INDEX idx_keyword_time (keyword_id, publish_time);

逻辑说明：utf8mb4是必须的，因为舆情数据里经常出现 emoji 和生僻字，utf8三字节存不下四字节字符，插入时会报Incorrect string value。索引方面，publish_time和source_id的联合索引能覆盖「某来源最近一周的数据」这类查询，keyword_id和publish_time的联合索引覆盖「某关键词的时间趋势」。这两个索引不加，数据量上到百万级之后，列表页查询会从毫秒级掉到十几秒。

参数说明：CONVERT TO CHARACTER SET会重建表，大表上执行要选低峰期。如果表里已经有数据，先备份。索引不是越多越好，舆情系统写入频繁，每个额外索引都会拖慢INSERT，所以只加真正被WHERE和ORDER BY用到的列。

2.3 数据库连接池配置：采集端和分析端要分开调

源码里通常有一个application.yml或datasource.properties，里面配了连接池。很多人直接默认值跑，采集一上量就报Connection timeout。原因是采集端和分析端共用一个池，分析端的慢查询把连接占满了，采集端拿不到连接。

# 采集端数据源，连接数给足，超时设短 spring: datasource: collector: url: jdbc:mysql://127.0.0.1:3306/opinion?useUnicode=true&characterEncoding=utf8mb4 username: collector password: collector_pwd hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 3000 idle-timeout: 60000 max-lifetime: 1800000 analyzer: url: jdbc:mysql://127.0.0.1:3306/opinion?useUnicode=true&characterEncoding=utf8mb4 username: analyzer password: analyzer_pwd hikari: maximum-pool-size: 10 minimum-idle: 2 connection-timeout: 5000 idle-timeout: 300000

逻辑说明：采集端maximum-pool-size给 20，因为采集是短事务、高并发，连接周转快；connection-timeout设 3000 毫秒，拿不到连接快速失败，避免线程堆积。分析端给 10 个连接，idle-timeout设长一点，因为分析查询间隔可能几十秒，频繁创建销毁连接反而浪费。

参数说明：max-lifetime要小于 MySQL 的wait_timeout，否则连接被服务端断开后，客户端还拿着死连接去查，报Communications link failure。MySQL 默认wait_timeout是 28800 秒，设 1800000 毫秒（30 分钟）是安全的。useUnicode和characterEncoding必须带，否则中文乱码。

3. 采集入库与数据清洗：让数据真正流起来

3.1 采集模块的入口在哪，怎么判断它能不能跑

舆情系统的采集模块一般分两种：一种是基于 HTTP 接口的定向采集，源码里会有spider、crawler、collector这类包；另一种是基于 RSS 或开放数据源的订阅式采集。拿到源码后，先找main方法或@Scheduled注解，那是采集的触发点。

# 找采集入口，先看有没有定时任务 grep -rn "@Scheduled" --include="*.java" . # 找 HTTP 采集的起始 URL 配置 grep -rn "startUrl\|seedUrl\|baseUrl" --include="*.yml" --include="*.properties" .

逻辑说明：@Scheduled标注的方法就是定时采集的入口，看它的cron表达式能知道采集频率。startUrl这类配置是采集的种子地址，如果源码里写的是示例域名，你需要替换成实际要采集的站点。这一步不做，采集模块跑起来也是空转。

参数说明：cron表达式常见的是0 0/5 * * * ?，表示每 5 分钟一次。如果源码里设的是0 0/1 * * * ?，每分钟一次，对目标站点压力大，容易被封 IP，建议改成 5 到 10 分钟。采集频率不是越高越好，舆情系统要的是趋势，不是实时流。

3.2 数据清洗：去重、去噪、字段映射

采集回来的原始数据不能直接入库，里面混着重复内容、HTML 标签、广告文本。清洗模块通常叫cleaner、processor、etl。核心逻辑就三件事：去重、去标签、字段对齐。

import re import hashlib def clean_post(raw): # 去 HTML 标签 text = re.sub(r'<[^>]+>', '', raw['content']) # 去多余空白 text = re.sub(r'\s+', ' ', text).strip() # 去重指纹：标题 + 正文前 200 字做 MD5 fingerprint = hashlib.md5( (raw['title'] + text[:200]).encode('utf-8') ).hexdigest() return { 'title': raw['title'].strip(), 'content': text, 'publish_time': raw['publish_time'], 'source_id': raw['source_id'], 'fingerprint': fingerprint, 'keyword_id': raw.get('keyword_id', 0) }

逻辑说明：re.sub(r'<[^>]+>', '', ...)去掉所有 HTML 标签，舆情数据里经常混着<p>、<br>、<a>这些。fingerprint用标题加正文前 200 字做 MD5，是因为同一篇文章可能被多个来源转载，标题相同但正文有细微差异，取前 200 字既能区分不同文章，又能容忍转载时的尾部改动。入库时对fingerprint建唯一索引，重复数据直接INSERT IGNORE。

参数说明：text[:200]的 200 是经验值，太短容易误判不同文章为重复，太长则转载时尾部改动会导致指纹不同。keyword_id默认 0 表示未匹配到关键词，后续分析模块会补上。

3.3 批量入库：单条插入是性能杀手

清洗完的数据如果一条一条INSERT，采集一千条就要一千次数据库往返，延迟高得离谱。正确做法是攒一批，用INSERT INTO ... VALUES (...), (...), ...批量写。

-- 批量插入，每批 500 条 INSERT IGNORE INTO posts (title, content, publish_time, source_id, fingerprint, keyword_id) VALUES (?, ?, ?, ?, ?, ?), (?, ?, ?, ?, ?, ?), -- ... 重复到 500 组 ;

逻辑说明：INSERT IGNORE配合fingerprint的唯一索引，重复数据自动跳过，不用先查再插。每批 500 条是权衡结果：太小则往返次数多，太大则单条 SQL 过长，超过max_allowed_packet会报错。MySQL 默认max_allowed_packet是 4MB，500 条舆情记录通常不到 1MB，安全。

参数说明：批量大小可以通过配置文件调整，我一般设batch.size=500。如果单条记录特别长（比如全文超过 5000 字），降到 200。入库失败时看日志里的SQLException，如果是PacketTooBigException，就是批量太大。

4. 检索分析与可视化：让数据产生判断价值

4.1 关键词检索：LIKE 不够用，得上全文索引

舆情系统最核心的功能就是按关键词搜。很多人直接用LIKE '%关键词%'，数据量小的时候没问题，上到十万条之后，每次查询都是全表扫描，CPU 直接拉满。

-- 先看表里有没有全文索引 SHOW INDEX FROM posts WHERE Key_name = 'ft_content'; -- 没有就建，注意 ngram 分词器对中文的支持 ALTER TABLE posts ADD FULLTEXT INDEX ft_content (title, content) WITH PARSER ngram; -- 用全文索引查询，替代 LIKE SELECT id, title, publish_time FROM posts WHERE MATCH(title, content) AGAINST('关键词' IN BOOLEAN MODE) AND publish_time BETWEEN '2025-01-01' AND '2025-01-31' ORDER BY publish_time DESC LIMIT 20;

逻辑说明：MySQL 5.7 之后内置了ngram分词器，专门处理中文。MATCH ... AGAINST走全文索引，比LIKE快一个数量级。IN BOOLEAN MODE支持+关键词（必须包含）、-关键词（必须不包含）这种操作符，做舆情过滤很实用。

参数说明：ngram_token_size默认是 2，表示按两个字分词。如果关键词多是单字（比如人名里的姓），需要改成 1，但要改 MySQL 配置并重建索引。全文索引会占额外存储，大概是原表数据的 30% 到 50%，建之前确认磁盘够。

4.2 情感分析与趋势聚合：别自己训模型，先用规则跑通

很多开源舆情系统带情感分析模块，但模型文件可能没给全，或者依赖的 Python 环境版本对不上。我的建议是先用规则跑通流程，再考虑换模型。

# 基于情感词典的简易情感打分 POSITIVE_WORDS = {'好', '优秀', '满意', '支持', '赞'} NEGATIVE_WORDS = {'差', '糟糕', '不满', '反对', '投诉'} def sentiment_score(text): pos = sum(1 for w in POSITIVE_WORDS if w in text) neg = sum(1 for w in NEGATIVE_WORDS if w in text) if pos > neg: return 1 # 正面 elif neg > pos: return -1 # 负面 return 0 # 中性

逻辑说明：这个函数对每条帖子打一个 -1、0、1 的标签，存到posts.sentiment字段。趋势聚合就是按天分组统计正面和负面的数量。

SELECT DATE(publish_time) AS day, SUM(CASE WHEN sentiment = 1 THEN 1 ELSE 0 END) AS positive, SUM(CASE WHEN sentiment = -1 THEN 1 ELSE 0 END) AS negative FROM posts WHERE keyword_id = ? GROUP BY DATE(publish_time) ORDER BY day;

参数说明：情感词典可以放在数据库表里，方便运营人员增删词。规则法的准确率大概 70% 左右，但对趋势判断够用了——舆情要的是「负面是不是在涨」，不是「这条到底多负面」。等流程跑通、数据攒够，再换 BERT 这类模型做细粒度分类。

4.3 可视化：ECharts 接后端接口的最小闭环

前端可视化通常用 ECharts，后端提供一个返回 JSON 的接口。源码里如果带了前端，直接看它请求的 URL；如果没带，自己写一个。

// 前端请求趋势数据并渲染 fetch('/api/trend?keywordId=1&days=7') .then(res => res.json()) .then(data => { const chart = echarts.init(document.getElementById('trend')); chart.setOption({ xAxis: { type: 'category', data: data.days }, yAxis: { type: 'value' }, series: [ { name: '正面', type: 'line', data: data.positive }, { name: '负面', type: 'line', data: data.negative } ] }); });

逻辑说明：后端/api/trend接口执行 4.2 里的聚合 SQL，把结果转成{days: [], positive: [], negative: []}的格式。前端拿到后直接喂给 ECharts。这个闭环跑通，整套舆情系统就算能用了。

参数说明：days=7控制时间窗口，可以改成 30 看月度趋势。ECharts 的type可以换成bar做柱状对比，换成pie做占比。接口返回的数据量不大，不用分页。

5. 避坑与排查：那些让我加班到凌晨的坑

5.1 采集正常但数据库没数据：先看事务和字符集

现象：采集日志显示「成功入库 200 条」，但SELECT COUNT(*)还是 0。

原因：最常见的是事务没提交。源码里如果用了@Transactional，但方法内部捕获了异常没往外抛，Spring 不会回滚也不会提交，数据就悬在那里。另一个原因是字符集不匹配，插入时抛了异常但被吞了。

解决：先看日志里有没有Incorrect string value或Data too long。如果有，改字符集和字段长度。如果没有，检查@Transactional的传播行为，确保采集方法没有自己try-catch掉异常。临时排查可以在INSERT后加一句SELECT LAST_INSERT_ID()，看有没有返回值。

5.2 查询越来越慢：索引没建对，或者建多了

现象：系统刚上线时列表页秒开，一个月后要转十几秒。

原因：数据量涨了，但索引没跟上。或者反过来，索引建了太多，写入时维护索引的开销把采集拖慢了。

解决：用EXPLAIN看慢查询的执行计划。如果type是ALL，说明全表扫描，需要加索引。如果key是NULL，说明索引没被用上，可能是字段类型不匹配（比如字符串字段用数字查）。索引不是越多越好，SHOW INDEX FROM posts看一遍，把从没被EXPLAIN用到的索引删掉。

5.3 情感分析结果全是中性：词典没加载或者分词没生效

现象：跑完情感分析，sentiment字段全是 0。

原因：词典文件路径写的是绝对路径，换台机器就找不到；或者中文分词没配好，text里全是连在一起的字符串，词典里的词匹配不上。

解决：把词典路径改成相对路径或配置项，启动时打印一下加载了多少个词。分词方面，如果用jieba，确认jieba.initialize()被调用了。临时验证可以手动传一条明显正面的文本，看返回是不是 1。

5.4 数据库连接池耗尽：慢查询把连接占死了

现象：采集端报Connection is not available, request timed out，但数据库本身没挂。

原因：分析端的某个查询跑了太久，连接一直不释放，池子被占满。

解决：给分析端的连接池设connection-timeout，拿不到连接快速失败，不要无限等。同时在 MySQL 里开慢查询日志，long_query_time=2，找出超过 2 秒的 SQL 优化掉。采集端和分析端用不同的数据库账号和连接池，这是最有效的隔离手段。

5.5 定时任务重复执行：多实例部署没加锁

现象：采集任务在日志里出现两次，数据重复入库。

原因：服务部署了两个实例，@Scheduled在每个实例上都跑。

解决：用数据库悲观锁或 Redis 分布式锁，确保同一时间只有一个实例执行采集。简单做法是在任务开始时INSERT一条锁记录，唯一索引冲突就跳过。或者用 Quartz 的集群模式，它自带锁机制。

6. 进阶技巧：用分区表把历史数据管起来

舆情系统的数据是只增不减的，一年下来posts表可能上千万行。全表查询越来越慢，备份也越来越久。这时候可以考虑分区表，按月份把数据切开。

-- 按 publish_time 月份分区 ALTER TABLE posts PARTITION BY RANGE (TO_DAYS(publish_time)) ( PARTITION p202501 VALUES LESS THAN (TO_DAYS('2025-02-01')), PARTITION p202502 VALUES LESS THAN (TO_DAYS('2025-03-01')), PARTITION p202503 VALUES LESS THAN (TO_DAYS('2025-04-01')), PARTITION p_max VALUES LESS THAN MAXVALUE );

逻辑说明：分区后，查询「2025 年 1 月的数据」时，MySQL 只扫描p202501分区，不用扫全表。删除历史数据也变成ALTER TABLE posts DROP PARTITION p202501，秒级完成，不用DELETE慢慢删。

参数说明：分区键必须是主键的一部分，如果posts的主键是id，需要改成联合主键(id, publish_time)。MAXVALUE分区兜底，防止插入超出范围的数据时报错。分区不是银弹，如果查询条件不带publish_time，还是会扫所有分区。

另一个实用技巧是给fingerprint加唯一索引后，用INSERT IGNORE做去重，但要注意INSERT IGNORE会忽略所有错误，包括字段超长。更稳妥的是INSERT ... ON DUPLICATE KEY UPDATE，只处理唯一键冲突，其他错误照常抛出。

INSERT INTO posts (title, content, publish_time, source_id, fingerprint, keyword_id) VALUES (?, ?, ?, ?, ?, ?) ON DUPLICATE KEY UPDATE content = VALUES(content), publish_time = VALUES(publish_time);

这样重复数据会更新而不是跳过，适合采集端需要修正已入库数据的场景。

我自己维护这套东西最大的教训是：别急着改源码里的业务逻辑，先把数据库和采集链路跑通。很多看起来是代码 bug 的问题，其实是索引没建、连接池没调、字符集不对。把这三样弄好，开源舆情系统跑起来并不难。希望帮到你。

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