简介：开源免费的舆情系统源码与数据库，面向需要快速搭建网络舆情监测平台的企业、组织及开发者个人，帮助用户采集新闻、博客、社交平台等公开信息，并结合情感分析与可视化图表识别热点、评估品牌声誉。压缩包共二千个文件，体积约四十五兆，其中以脚本、样式表、网页和配置数据为主，构成完整的前端展示与数据交互框架，支持本地化部署、界面定制。另有少量说明文档和辅助脚本，可降低部署门槛。目前已有七百二十六人浏览学习。凭借清晰的目录结构和开源特性，用户能直接修改源码、替换数据库参数，在自己的服务器或云平台上搭建一套可用的舆论分析平台；系统涵盖数据采集、处理、分析与展示等环节，借助图表组件和处理流程，可帮助理解舆情系统的模块划分与工作原理。
1. 开源免费的舆情系统源码不难找，难的是数据库设计能不能扛住真实业务
开源免费的舆情系统源码在社区里其实不少，但很多人下载一个"源码+数据库"的完整包，按 README 装完，采集端也跑起来，页面里也出了数据，结果一上真实业务就翻车：关键词加了十几个后面板变慢，想查几天前的负面舆情时搜索直接卡死，跑了一周数据库膨胀到几个 G。这个笔记想讲清楚一条从选型到上线的落地路径：先怎么看源码里的数据库脚本，再怎么做最小部署，然后怎么把表结构设计成能长期用的样子，以及那些文档里不写但一定会踩的坑。适合准备自己搭舆情监测、又不想从零写采集和分析的团队或个人。
2. 拿到源码先别急着跑：舆情系统选型与最小部署路径
2.1 开源舆情系统的三种形态：先看数据量再选型
开源舆情系统按数据链路来分，基本是三种形态。第一种是单机版，由采集爬虫、MySQL 和一套后台管理界面组成，适合每天几万条数据的量级，部署最简单，改代码也方便。第二种是分布式版，采集端多机部署，中间加消息队列，存储用 MySQL 配合独立检索引擎，适合千万级数据和全文检索场景，但运维成本不是小团队能随便背的。第三种是半开源版，只把采集和前后端开源，核心的情感分析模块需要单独授权，这类项目先看清楚你买的是完整链条还是半条链。
选型的核心依据是关键词数量、采集源数量和日报表复杂度。如果你只有 20 个关键词、50 个新闻源，每天数据量几千条，上分布式完全没有必要；很多团队一上来就搬大数据架构，最后变成每天维护消息队列，不是在跑舆情系统。我一般会按数据量倒推：假设每天采集 2 万条文章，每条正文 2KB，一个月也就 1.2GB，MySQL 完全扛得住，不需要额外引入搜索服务。只有当你要对正文做全文检索、搜索响应要求低于 200ms 时，才需要在 MySQL 里加全文索引或者独立部署一个搜索引擎。
还有一个容易被忽略的点就是标题强调的"数据库"。有些仓库的 SQL 脚本只是建了三四张演示表，没有评论表、没有关键词命中表、没有预警配置表，甚至在 README 里说"数据库文件过大，请自行联系作者"，这种项目就算源码写得再好，落地时你也要自己补一堆表结构。打开源码里的 sql 或 database 目录，先看有没有三样东西：用户权限表、内容主表、采集配置表。缺了后面两个，二次开发的成本会非常痛。
2.2 最小部署路径：依赖、配置、启动三步走
拿到源码第一步，我建议用虚拟环境在裸机上跑通，而不是直接上 Docker。因为源码是你二开的基础，裸机跑更容易改代码、看日志、调试依赖问题，先别追求环境一致性。
cd /opt/yuqing python3 -m venv venv source venv/bin/activate pip install -r requirements.txt -i https://mirrors.cloud.tencent.com/pypi/simple cp config.example.ini config.ini vim config.ini逻辑说明：虚拟环境隔离 Python 依赖，避免把系统环境弄乱；requirements.txt 是源码自带的依赖清单，不要直接往系统 Python 里装。这里用国内镜像源只是提速，如果源码里依赖了私有包，镜像源里没有，pip 会报找不到包，这时候先看报错的是哪个包，再决定是否把源切回默认官方源。config.ini 是核心配置文件，至少要核对数据库连接串、Redis 连接串、采集线程数和日志级别这几段。
参数说明：很多开源系统把关键词列表、采集间隔（秒）、启动采集的开关都放在配置里。部署第一步就检查 DEBUG 选项，不少 demo 项目为了演示方便把 DEBUG 设成 True，但在公网服务器上这等于把程序运行细节全部暴露出去，一定要改成 False。
接下来初始化数据库和后台：
mysql -uroot -p -e "CREATE DATABASE yuqing DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci;" mysql -uroot -p yuqing < sql/init.sql python manage.py migrate逻辑说明：有的 init.sql 自己带了 CREATE DATABASE 语句，如果你先手动建库再执行，会重复建库报错。正确做法是先用head看一下 init.sql 开头，有 CREATE DATABASE 就直接mysql -uroot -p < sql/init.sql，省掉前面的手动建库。migrate 是后端框架的迁移命令，如果 init.sql 已经建好了所有表，migrate 会扫描并跳过，不会冲突。
参数说明：数据库字符集必须用 utf8mb4，因为舆情数据里会混入 emoji、繁体字和部分生僻字，utf8 根本存不下。数据库账号这里注意，生产环境别给 root，应该单独建一个 yuqing 用户，只授予 yuqing 库的权限。
启动后台和采集端：
python manage.py createsuperuser python manage.py runserver 0.0.0.0:8000 cd collector && python run.py --threads 4 --interval 300createsuperuser 会交互式让你输入用户名和密码，这是管理后台的登录入口，不要用默认的 admin/admin123，被扫描器扫到是分分钟的事。runserver 是后端开发服务器，只适合调试，正式跑的时候换 gunicorn 之类的多进程服务器，后面讲。采集参数这里，threads 是并发线程数，interval 是两轮采集间隔的秒数，一开始先 threads 4、interval 300 保守一点，跑一小时看日志再调。如果目标网站响应快，可以加到 8；日志里大量超时，立刻退回 4，别跟连接数硬刚。
2.3 跑通后先验证链路：查库、看日志、搜索命中
看到终端在刷日志，并不代表链路真的通了。我一般按三个步骤做自检。
tail -f collector/collector.log | grep "ERROR" | head -20 mysql -uyuqing -p yuqing -e "SELECT COUNT(*) AS cnt, DATE(crawl_datetime) AS d FROM article GROUP BY d ORDER BY d DESC LIMIT 3;"第一条命令看错误日志，第二条看入库量。如果采集日志显示 HTTP 200，但数据库 COUNT 一直是 0，问题大概率出在解析规则：页面结构改版了，或者正文选择器没有匹配到。这种问题不要干等下一轮采集，应该把爬虫里的解析函数单独拿出来，用 requests 抓一个真实 URL，把返回的 HTML 打印出来检查选择器。
再登录后台，用一条刚采集到的标题去搜索。很多开源后台的搜索实现是LIKE '%关键词%'，如果搜不到，先看数据的入库链路：是直接写 MySQL，还是先写 Redis 再由异步任务写 MySQL。有的系统搜索模块和采集模块连的是不同的表，两边数据不一致，页面就会显示"没有结果"，看起来像 bug，其实是没同步完成。
2.4 别急着上 Docker：什么时候用 Compose 更好
如果源码带了 docker-compose.yml，先别高兴太早。它适合用来"试用"，但不太适合"二开"。我的判断标准很简单：只是想快速看效果，用docker-compose up -d省得本机装一堆服务；想长期改业务，先裸机跑通，再决定要不要写自己的 Dockerfile。
Docker 部署的坑主要在数据和镜像标签。compose 文件里如果没把 MySQL 数据目录挂出来，重启容器数据可能直接没，这是最没有后悔药的场景。正确做法是显式挂载到宿主机：
volumes: - ./data/mysql:/var/lib/mysql镜像版本也不要写 latest，因为基础镜像一升级，MySQL 8 和旧版 Python 驱动可能不兼容，采集端连接数据库直接报认证协议错误。我一般会把镜像锁到具体的次版本，例如 MySQL:8.0。另外，docker-compose 里默认的数据库密码、Redis 密码都是源码公开的，公网部署前一定要改掉，否则别人扫到 3306 端口，用默认密码就能进库。
3. 数据库设计直接决定舆情系统能用多久：表结构、索引与初始化脚本
3.1 核心表结构：把新闻、微博、微信文章统一进一张大表
舆情系统的数据来源很多，新闻、微博、微信、论坛、视频评论，字段差异很大。但落到存储上，都要有标题、正文、作者、链接、发布时间、采集时间、平台来源这几样。所以我会把所有平台的内容放到一张 article 表里，平台用字段区分，而不是给每个平台单独建表。这样列表页搜索、报表统计、情感分析都对同一张表操作，不需要跨表合并。
CREATE TABLE article ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, platform VARCHAR(20) NOT NULL COMMENT 'news/weibo/weixin', title VARCHAR(500) NOT NULL, content MEDIUMTEXT COMMENT '清洗后的正文文本', author VARCHAR(120), source_url VARCHAR(1000) NOT NULL, source_name VARCHAR(120), pub_datetime DATETIME NOT NULL, crawl_datetime DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, keyword_hit VARCHAR(500) COMMENT '命中的关键词，逗号分隔', sentiment TINYINT NOT NULL DEFAULT 0 COMMENT '-1负面 0中性 1正面', status TINYINT NOT NULL DEFAULT 0 COMMENT '0未审核 1已审核', extra JSON, UNIQUE KEY uk_source_url (source_url(191)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;逻辑说明：platform 用短字符串比 TINYINT 可读性好，数据量不大时不差这点存储。source_url 加唯一索引做去重，但 URL 往往很长，InnoDB 索引对 utf8mb4 列的长度有限制，所以这里用前缀索引，191 在 MySQL 5.7 是常用的上限。extra 用 JSON 类型，MySQL 5.7 以上支持，可以放微博的转赞评、微信的阅读数这类平台特有字段，不用频繁 ALTER TABLE。
参数说明：MEDIUMTEXT 最大 16MB，存普通文章够用。content 存的一定是清洗后的纯文本，如果连 HTML 标签一起存进去，后期做全文搜索时会把样式代码都搜出来，统计字数也不准。采集端入库前要先做去标签、去空白、繁体转简体这些基本清洗。
评论表单独拿出来，是因为舆情分析里评论的情感往往比正文更关键，一条负面新闻能不能发酵，评论区表态很重要。
CREATE TABLE comment ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, article_id BIGINT UNSIGNED NOT NULL, user_name VARCHAR(120), content TEXT, comment_time DATETIME, like_count INT DEFAULT 0, UNIQUE KEY uk_article_comment_time (article_id, comment_time, content(32)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;逻辑说明：唯一索引选 article_id、comment_time、content 前 32 个字符，是拿来做评论粗粒度去重的，防止采集端重复抓同一条评论。如果评论内容太短，前 32 个字符可能撞车，所以它只是辅助去重，不能完全依赖。
3.2 关键词与情感分析结果怎么落库：冗余字段还是关联表
关键词命中是舆情系统最核心的查询入口。社区里的老做法有两种，各有利弊。第一种是在 article 表里加一个 keyword_hit 字段，用逗号分隔所有命中的关键词。优点是好写、查询快、列表页直接展示，缺点是没法做关键词维度的统计，比如"昨天哪个关键词命中最多"。第二种是单独建一张 article_keyword 关联表，每篇文章命中几个关键词就写几行，查询时 JOIN，统计时 GROUP BY。
CREATE TABLE article_keyword ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, article_id BIGINT UNSIGNED NOT NULL, keyword_id INT UNSIGNED NOT NULL, hit_count INT DEFAULT 0, UNIQUE KEY uk_article_keyword (article_id, keyword_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;逻辑说明：这张表能回答"关键词 A 在最近 24 小时命中多少篇文章"这类问题，响应很快。但坏处是写入量翻倍，每篇文章入库时要额外做 INSERT，采集端成为瓶颈。
我一般用混合策略：普通关键词只写入 article.keyword_hit 字段，用于列表展示；重点关键词（比如竞品词、高优先级的负面词）在采集端并行写到 article_keyword 表，用于日报和趋势分析。这样既保证写入性能，又保留统计能力。代码里只需要多一个判断，成本很低。
情感分析结果不要把所有模型输出都塞进主表。模型跑出来的分数、版本号这些属于过程数据，单独记一张日志表，主表只保存最终结论。这样以后换模型或者调参数时，能用日志表里的旧结果做对比评估。
CREATE TABLE sentiment_log ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, article_id BIGINT UNSIGNED NOT NULL, label TINYINT NOT NULL, score DECIMAL(5,4) NOT NULL, model_version VARCHAR(50), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;逻辑说明：主表的 sentiment 字段选 TINYINT，范围 -1、0、1，列表页筛选非常快。sentiment_log.score 用 DECIMAL(5,4)，可表示 0 到 9.9999，模型置信度一般不超过 1，完全够用。model_version 单独存，避免线上模型更新后，历史数据的含义对不上。
3.3 初始化脚本里除了建表还要写什么：配置、词库和默认账户
标题里说"源码+数据库"，很多人理解成只要把建表语句导入就行了，其实不够。一个能直接跑起来的数据库初始化脚本，至少包含四段内容：建表、系统配置、词库、采集源配置。否则你启动后台会发现字典表是空的，预警功能没有数据，采集任务不知道抓哪些网站。
INSERT INTO sys_config (config_key, config_value, update_time) VALUES ('collect.interval', '300', NOW()), ('alert.max_per_day', '50', NOW()); INSERT INTO sensitive_word (word, level) VALUES ('投诉','high'), ('退货','medium'), ('客服失联','high'); INSERT INTO crawl_source (platform, source_name, url, parse_type, status) VALUES ('news', '某新闻网', 'https://example.com/rss', 'rss', 'enabled');逻辑说明：系统配置的 key 要和代码里读取逻辑完全对应，不能自己发明，否则代码读不到。敏感词表的 level 字段决定预警优先级：high 级别的词命中后立刻触发通知，medium 级别只记录不通知。采集源配置里的 parse_type 也很重要，写 rss 就走 RSS 解析，写 xpath 就走页面解析，两类解析在代码里是不同分支。
参数说明：这些 INSERT 语句在 init.sql 里要放在建表语句之后，并且整个初始化脚本用事务包住，任何一个 INSERT 失败就整体回滚，避免出现库表建了但配置缺失的半成品状态。默认账户也会在脚本里写入，但密码一定要生成强密码，源码自带的初始密码几乎都是公开的，跑通后第一件事就是改掉。
3.4 数据膨胀与归档：舆情库的两级存储策略
舆情数据时效性很强，但直接删不安全，因为后续可能还要做事件回溯。常见做法是分两级：近期数据放主表，历史数据放归档表。用 MySQL 的定时事件每天执行迁移。
CREATE EVENT archive_old_article ON SCHEDULE EVERY 1 DAY DO BEGIN INSERT INTO archive.article SELECT * FROM yuqing.article WHERE pub_datetime < DATE_SUB(NOW(), INTERVAL 60 DAY); DELETE FROM yuqing.article WHERE pub_datetime < DATE_SUB(NOW(), INTERVAL 60 DAY); END;逻辑说明：INSERT SELECT 先把符合条件的旧数据复制到归档库，然后从原表删除。但这句话有个大坑：如果 article_keyword 或 comment 表存在关联 article.id 的外键或业务关联，直接 DELETE article 会失败或者造成悬空数据。正确的执行顺序是，先处理关联表，再删主表。如果关联表数据量也大，可以按 article_id 分批次删除，不要把一条大 DELETE 提交到线上。
参数说明：60 天是一个常见调节项。如果业务只关注近 30 天舆情，就改成 30 天；如果要做年度报告，就改成 90 天。归档表的结构要和主表完全一致，查询时用 UNION 或者做报表时直接查归档库。定时事件安排在凌晨低峰期执行，避开白天采集入库高峰。
4. 舆情系统跑起来后最容易踩的 5 个坑：现象、根因、修复
4.1 采集端跑一会儿就卡死，线程数加到 6 反而更慢
现象：采集日志停在某个 URL 上不动，SSH 能连进去，但进程 CPU 长期 100%，重启后能恢复，再过几小时又卡住。
原因：很多开源采集器用的是 requests 同步请求，代码里没有超时参数，遇到响应慢的网站，线程就占在连接上不放。多线程又共享同一个 Session，连接池一旦被慢请求占满，新请求全部排队，整个采集端看起来就像死掉。
解决：给每个请求加明确的超时，连接 5 秒、读 10 秒；给每个线程创建独立的 Session，不要共享；还要加重试和退避，不要立刻重试。
for attempt in range(3): try: resp = session.get(url, timeout=(5, 10)) break except requests.Timeout: time.sleep(attempt * 5)逻辑说明：重试间隔用线性退避，第一次失败等 5 秒，第二次等 10 秒，避免对目标网站造成压力。这个问题的根子不是 IP 被限制，而是没有超时和重试策略。调线程数只能暂时缓解，超时参数才是解药。
4.2 中文乱码：建库建表都对，写入还是问号
现象：后台列表页标题显示成???，用数据库客户端手工插入中文却正常。
原因：库表字符集虽然是 utf8mb4，但源码里数据库连接 URL 少了字符集参数，Python 驱动默认用 latin1 去解码中文，写入前就已经变成乱码。这个问题和数据库服务器端配置没关系，是连接层的问题。
解决：把配置文件里的连接串改成带 charset 的形式：
mysql://yuqing:password@127.0.0.1:3306/yuqing?charset=utf8mb4然后检查 init.sql 里所有建表语句是不是都用了 utf8mb4。已经写进去的乱码数据，用转换语句修复：
ALTER DATABASE yuqing CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE article CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;注意：CONVERT 只改已有列的字符集，如果连接层还是错的，新写入的数据照样乱码，所以先改连接串，再改数据表。跑完转换后抽查几条记录，确认不是二次的乱码。
4.3 URL 去重失效：同一条新闻正文更新了却采不进来
现象：某网站的文章修正了一个数据，后台却一直保留老版本，重新采集也进不来。
原因：主表在 source_url 上建了唯一索引，同一 URL 第二次插入会被 Duplicate entry 直接跳过。但新闻网站经常有"更正""更新"，URL 不变，正文变了，传统去重策略会把更新错过。
解决：给 article 表加一个 content_hash 字段，先按 URL 判断，如果 URL 存在，再比较正文的哈希值，不一致就更新原记录。
ALTER TABLE article ADD COLUMN content_hash CHAR(32) DEFAULT '' AFTER content, ADD INDEX idx_content_hash (content_hash);采插入语句改用 MySQL 的 ON DUPLICATE KEY UPDATE：
INSERT INTO article (title, content, content_hash, source_url, pub_datetime, ...) VALUES (...) ON DUPLICATE KEY UPDATE content_hash = VALUES(content_hash), content = VALUES(content);逻辑说明：这里触发唯一索引的前提是 source_url 已经建了唯一键，冲突说明是同一条 URL，那就用新内容覆盖旧内容。MD5 会有碰撞概率，但对去重场景完全够用，不是安全校验。加了哈希后，列表页会增加一个字段，报表统计时注意别把更新次数当成新文章数。
4.4 关键词一多，搜索慢成黑匣子
现象：后台按关键词筛选，数据量到 20 万条时，一次查询卡 3 秒以上。
原因：代码里写的是WHERE keyword_hit LIKE '%关键词%'，前导通配符让 MySQL 完全没法用索引，只能全表扫描。关键词数量越多，每次扫描成本越高，而且这个慢会直接影响后台页面，连列表页都打不开。
解决：先判断量级。20 万条以内，可以给 keyword_hit 建全文索引，用 MySQL 自带的 ngram 分词：
ALTER TABLE article ADD FULLTEXT INDEX ft_keyword (keyword_hit) WITH PARSER ngram;查询改成全文索引语法：
SELECT * FROM article WHERE MATCH(keyword_hit) AGAINST ('"某个关键词"' IN BOOLEAN MODE);逻辑说明：ngram 默认分词长度为 2，中文效果一般，但能支撑基本搜索，资源占用小，适合单机部署。如果数据量到百万级，或者要做相关度排序，这个方案会吃力，要尽早规划独立的搜索服务，把 keyword_hit 同步过去。最忌讳的是表里已经堆了几十万条数据后，才从 LIKE 改到搜索服务，那一步的数据迁移非常痛苦。
4.5 统计报表差了 8 小时：时区问题，不是数据没采到
现象：每天上午看"昨日舆情总数"，数量比实际少，凌晨的数据都被算到了前一天，或者直接少了几个小时。
原因：采集端代码用了 UTC 时间写入，存进 DATETIME 字段的是 UTC 时间；后台展示的时候按东八区过滤，差 8 小时。这类问题最隐蔽，因为看单条数据看不出异常，只有汇总统计才对不上。
解决：全链路统一时间标准。采集端写入本地时间：
from datetime import datetime now = datetime.now()不要用datetime.utcnow()。后台框架里把时区设置成东八区对应的值。已经乱掉的数据，按偏移修复，但先确认数据是真的 UTC，否则会把正常数据多加 8 小时：
UPDATE article SET pub_datetime = DATE_ADD(pub_datetime, INTERVAL 8 HOUR) WHERE pub_datetime BETWEEN DATE_SUB(NOW(), INTERVAL 7 DAY) AND NOW();我的血泪经验是：永远不要假设别人代码里用的是 utcnow 还是 now，先查一条数据的 pub_datetime，对比采集日志里的时间，确认差几小时再动手。这个坑排查起来不难，但特别容易在部署初期被漏掉，等报表数据错了半个月才发现。
5. 上线之前做三个验证，再加一个动态预警技巧
5.1 用真实历史数据回放，验证关键词命中率
部署完成后，拿最近一个月的真实文本列表，跑一遍采集代码里的关键词匹配逻辑，人工抽 100 条，计算命中率和准确率。一个 3 字品牌词，全库命中率低于 90%，大多是正文清洗不到位，HTML 标签没去掉或者繁体没转简体。这一步要在正式采集前做，不能等系统跑了两周再回头看数据质量。
5.2 压测采集与入库，不要用线程数试探
准备一批测试 URL，模拟 1000 次请求，重点观察三个指标：队列积压数是否一直增长、入库平均耗时、数据库连接数峰值。入库耗时超过 200ms，先查慢查询日志，大概率是索引缺失；连接数飙到 300，把数据库连接池上限调小，并发降一点，整体反而更稳。压测时最好用独立的测试库，别把生产初始化的数据污染掉。
5.3 加分技巧：动态预警阈值，而不是拍脑袋固定值
舆情预警最烦误报。昨天有 10 条正常讨论，今天来了 15 条就告警，操作员很快就会关掉通知。常见做法是固定阈值，这在节假日和突发事件下完全不适用。我会用前 30 天同一时间段的平均值和标准差来计算每天的预警阈值：
SELECT AVG(cnt) + 2 * STDDEV(cnt) AS alert_threshold FROM ( SELECT DATE(pub_datetime) AS d, COUNT(*) AS cnt FROM article WHERE sentiment = -1 AND pub_datetime >= DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY DATE(pub_datetime) ) t;把这个阈值写进预警配置，每天自动重算。2 倍标准差意味着只有数据明显偏离历史规律时才触发，比固定阈值能减少七成无效告警。这也是我在模拟项目 X 的舆情模块上最满意的一个改动。
我最早在某图像处理 Demo 的舆情功能上，也干过跑一次 ALTER TABLE 把整列数据弄丢的事，从那以后，每次改动表结构或初始化脚本之前都先 mysqldump 备份一次。这个习惯救了我不止一次。希望帮到你。
本文还有配套的精品资源，点击获取
