簡介這份基于Python的網(wǎng)絡(luò)輿情分析系統(tǒng)以完整前后端與MySQL數(shù)據(jù)庫呈現(xiàn)面向輿情監(jiān)控管理人員以及畢業(yè)設(shè)計、課程設(shè)計開發(fā)者。系統(tǒng)支持多用戶并行使用管理員可管理用戶與言論數(shù)據(jù)通過對各類網(wǎng)絡(luò)平臺言論的情感分析以餅狀統(tǒng)計圖等方式直觀展示輿論分布同時提供密碼和個人信息維護(hù)功能。壓縮包共二百八十九個文件包含四十二個Python源碼文件、三十四個JavaScript腳本、十五個CSS樣式表以及HTML頁面、SQL數(shù)據(jù)庫腳本、說明文檔和演示動圖等整體大小八十三點三九MB文件類型覆蓋系統(tǒng)實現(xiàn)與部署所需的全部環(huán)節(jié)便于按目錄模塊對照學(xué)習(xí)。項目還附帶環(huán)境配置、數(shù)據(jù)庫搭建、前后端部署等詳細(xì)文檔并給出LW說明文檔有助于快速復(fù)現(xiàn)系統(tǒng)邏輯與運行流程為二次開發(fā)或課設(shè)答辯提供扎實參考。已有一百人學(xué)習(xí)下載適合需要完整項目范例的中高級學(xué)習(xí)者。1. 基于Python的網(wǎng)絡(luò)輿情分析系統(tǒng)源碼包前后端MySQL的課設(shè)項目能直接跑通嗎“網(wǎng)絡(luò)輿情分析系統(tǒng)”聽起來是個很龐大的課題但我拆完這套源碼之后的第一感受是它的架構(gòu)非?？酥普每ㄔ诋厴I(yè)設(shè)計和課程設(shè)計最需要的那個復(fù)雜度上。后端Python接收言論數(shù)據(jù)、做基礎(chǔ)的情感傾向判斷和數(shù)據(jù)統(tǒng)計MySQL存用戶與言論數(shù)據(jù)前端基于layui的admin模板做展示登錄、注冊、言論管理、餅狀統(tǒng)計圖一條線串下來功能完整但不過度設(shè)計。適合三類人正在做Python畢設(shè)或課設(shè)的學(xué)生想在公司內(nèi)網(wǎng)搭一套簡易輿情監(jiān)測原型的產(chǎn)品或運維人員以及想搞明白前后端分離項目里MySQL數(shù)據(jù)怎么流動的初學(xué)者。從解壓目錄看你可能會被一堆CSS文件名勸退——layui.css、admin.css、layer.css、laydate.css、login.css。這些其實都是layui后臺模板的靜態(tài)資源真正要琢磨的是它們對應(yīng)的頁面和后端接口。系統(tǒng)限定了多用戶共用、但管理員只有一人的結(jié)構(gòu)普通用戶負(fù)責(zé)提交言論、查看統(tǒng)計圖表和維護(hù)個人密碼管理員額外擁有用戶增刪改權(quán)限。這就是我們拆權(quán)限表和接口時的主線也是復(fù)現(xiàn)這套系統(tǒng)的鑰匙。2. 系統(tǒng)拆解輿情數(shù)據(jù)從采集到餅狀圖展示的核心鏈路2.1 訪問一條言論前后端到底是怎么分工的這套源碼是典型的前后端分離結(jié)構(gòu)。前端頁面部署在靜態(tài)目錄下瀏覽器加載HTML和JS用戶操作觸發(fā)Ajax請求后端Python框架負(fù)責(zé)接收HTTP請求、處理業(yè)務(wù)邏輯、讀寫MySQL最后把JSON數(shù)據(jù)返回給前端渲染。我習(xí)慣先從前端的網(wǎng)絡(luò)請求反向看后端因為源碼里CSS文件太顯眼容易讓人忽略真正的邏輯都在后端接口里。以發(fā)表言論為例用戶在頁面上輸入一段文字前端把內(nèi)容通過POST請求送到后端接口。后端校驗用戶身份后把這條言論連同當(dāng)前用戶ID、時間戳寫入MySQL的言論表與此同時后端還會調(diào)用一個簡單的分詞與情感判斷函數(shù)給這條言論打上一個“正面/負(fù)面/中性”的標(biāo)簽。這個標(biāo)簽就是后面餅狀統(tǒng)計圖的數(shù)據(jù)來源。這里有一個容易被忽略的點輿情分析系統(tǒng)的核心不是頁面多好看而是“用戶提交的實時言論能不能快速落庫并且打上可統(tǒng)計的標(biāo)簽”。LayUI只是把這一過程包裝成了表格和圖表真正決定系統(tǒng)可用的是接口設(shè)計得夠不夠清晰。常見做法是后端每個接口返回統(tǒng)一的JSON結(jié)構(gòu)比如{code: 0, msg: success, data: {...}}前端拿到這個結(jié)構(gòu)再做渲染前后端各改各的互不干擾。2.2 MySQL表結(jié)構(gòu)與權(quán)限模型多用戶輿情系統(tǒng)的底層設(shè)計這個系統(tǒng)能實現(xiàn)“多用戶使用、但只有一個管理員”本質(zhì)上是數(shù)據(jù)庫表結(jié)構(gòu)在設(shè)計上做了角色字段。我從源碼包里的SQL文件能推斷出三類核心表用戶表、言論表、統(tǒng)計相關(guān)表。用戶表是主表言論表是業(yè)務(wù)表統(tǒng)計表或視圖服務(wù)于餅狀圖。用戶表一般長這樣id主鍵自增username唯一索引password存MD5加密值role字段用整數(shù)區(qū)分管理員和普通用戶create_time記錄創(chuàng)建時間。管理員只有一個的限制通常通過兩種方式實現(xiàn)一種是在初始化SQL里只插入一條管理員數(shù)據(jù)另一種是注冊接口判斷當(dāng)前用戶表里管理員數(shù)量超過一就拒絕創(chuàng)建。我在實際跑這套源碼時觀察到的是前者簡單直接符合課設(shè)項目的定位。言論表的設(shè)計則更體現(xiàn)輿情分析的特性。每條言論至少要有「內(nèi)容、發(fā)布人、情感標(biāo)簽、發(fā)布時間」四個字段。情感標(biāo)簽字段很關(guān)鍵因為餅狀圖統(tǒng)計的本質(zhì)是GROUP BY sentiment如果沒有這個字段前端圖表就拿不到分組數(shù)據(jù)。有些版本的源碼還會加一個來源字段比如“微博、論壇、評論區(qū)”用來做多來源對比但核心表結(jié)構(gòu)不會變。這里我要提醒一個細(xì)節(jié)很多畢設(shè)項目的MySQL表名和字段名是英文注釋也是英文或拼音但源碼包里的SQL文件往往直接帶中文注釋。導(dǎo)入數(shù)據(jù)庫時如果字符集不對這些注釋全都會變成亂碼連帶導(dǎo)致運行時查詢異常。這個問題我會在后面避坑章節(jié)單獨展開但你現(xiàn)在就得知道MySQL 5.7下建庫時選對字符集比選對字段類型更容易被忽略。2.3 前端LayUI組件與后端JSON接口的對應(yīng)關(guān)系從前端靜態(tài)文件能看出這套源碼用的是LayUI的后臺管理模板。admin.css對應(yīng)后臺整體框架login.css對應(yīng)登錄頁laydate.css是日期選擇器。前端頁面和后端接口的對應(yīng)關(guān)系我建議你按照“頁面 → 接口 → 功能”三個維度去做一張映射表比逐個文件翻要高效得多。我整理這套源碼時是這樣對應(yīng)起來的登錄頁面調(diào)/api/login做身份校驗主頁的輿情總覽調(diào)/api/dashboard拿用戶數(shù)和言論總量言論管理列表調(diào)/api/comment/list分頁拉取數(shù)據(jù)餅狀統(tǒng)計圖調(diào)/api/statistics獲取各情感標(biāo)簽的數(shù)量分布。用戶管理模塊則調(diào)/api/user/list、/api/user/add、/api/user/delete對應(yīng)增刪改查。接口路徑請求方式前端對應(yīng)頁面主要功能/api/loginPOSTlogin.html用戶登錄與角色識別/api/registerPOSTregister.html注冊普通用戶/api/comment/listGET/POST輿情言論頁分頁展示言論列表/api/comment/addPOST發(fā)布言論入口錄入新言論并觸發(fā)情感分析/api/statisticsGET餅狀統(tǒng)計圖頁匯總情感標(biāo)簽分布/api/user/managePOST用戶管理頁管理員增刪改用戶3. 部署跑通指南Python 3.6.8與MySQL 5.7下把系統(tǒng)拉起來3.1 環(huán)境準(zhǔn)備為什么源碼包鎖死這個版本組合源碼包的說明文檔里寫得很明確Python 3.6.8、MySQL 5.7、Navicat 11、PyCharm。這套組合看起來老舊但它踩過了那個年代所有能踩的坑反而是最容易在本地復(fù)現(xiàn)的配置。Python 3.6.8是3.6系列的穩(wěn)定版很多經(jīng)典第三方庫在這版下兼容性最好MySQL 5.7則是性能與安裝便利性的平衡點比5.5多了更好的JSON支持和utf8mb4默認(rèn)排序規(guī)則又比8.0省去了認(rèn)證插件變更帶來的驅(qū)動兼容問題。我考慮到很多讀者用的是Windows就按Windows環(huán)境來寫。安裝Python時記得在安裝向?qū)У谝豁摴催x“Add Python 3.6 to PATH”這一步如果漏掉后面命令行里敲python會提示找不到命令這個屬于新手最常見翻車點。MySQL 5.7建議選自定義安裝端口保持默認(rèn)的3306字符集在配置向?qū)Ю镞xutf8mb4這能省掉后面一大半的亂碼問題。Navicat 11在這里的角色是純粹的圖形化客戶端負(fù)責(zé)把源碼包里的SQL文件導(dǎo)入MySQL。如果你手頭只有新版本的Navicat導(dǎo)入操作完全兼容不必刻意找舊版本。PyCharm則只負(fù)責(zé)打開項目文件、運行后端入口你不需要安裝任何額外插件項目自帶依賴通常在requirements.txt里。3.2 數(shù)據(jù)庫導(dǎo)入Navicat建庫、導(dǎo)入SQL與連接參數(shù)配置數(shù)據(jù)庫是整套系統(tǒng)復(fù)現(xiàn)的第一步因為后端啟動時第一件事就是連接數(shù)據(jù)庫連不上就直接白屏或者報錯。我用Navicat導(dǎo)入這套源碼的流程是新建連接填127.0.0.1:3306用戶名root密碼填安裝MySQL時設(shè)置的那個然后新建數(shù)據(jù)庫庫名隨意但最好和源碼配置文件保持一致最后在新建的庫上右鍵“運行SQL文件”選擇源碼包中的SQL文件等待執(zhí)行完成。-- 核心表初始化語句示例源碼包SQL文件中的典型結(jié)構(gòu) CREATE DATABASE IF NOT EXISTS yuqing_db DEFAULT CHARACTER SET utf8mb4; USE yuqing_db; CREATE TABLE sys_user ( id INT NOT NULL AUTO_INCREMENT COMMENT 用戶ID, username VARCHAR(50) NOT NULL COMMENT 登錄賬號, password VARCHAR(64) NOT NULL COMMENT MD5加密后的密碼, role INT DEFAULT 1 COMMENT 角色0管理員1普通用戶, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB COMMENT用戶表; CREATE TABLE comment_info ( id INT NOT NULL AUTO_INCREMENT COMMENT 言論ID, user_id INT NOT NULL COMMENT 發(fā)布用戶ID, content TEXT COMMENT 言論內(nèi)容, sentiment VARCHAR(10) DEFAULT neutral COMMENT 情感標(biāo)簽, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_sentiment (sentiment) ) ENGINEInnoDB COMMENT言論表;這段建表語句里的關(guān)鍵參數(shù)值得多說兩句。DEFAULT CHARACTER SET utf8mb4決定整個庫的字符集utf8mb4理論上兼容所有中文和emoji我的建議是建庫時必須保留。role字段用0和1區(qū)分管理員和普通用戶業(yè)務(wù)代碼里做權(quán)限判斷時只認(rèn)數(shù)字不認(rèn)字符串。idx_sentiment這個索引是為餅狀圖的GROUP BY sentiment查詢準(zhǔn)備的沒有這個索引數(shù)據(jù)量一大就會慢課設(shè)階段雖然感知不明顯但它是這個表設(shè)計里體現(xiàn)工程素養(yǎng)的地方。導(dǎo)入完成后打開源碼包里的數(shù)據(jù)庫配置文件常見命名有config.py、db.py、settings.py確認(rèn)連接參數(shù)和你的本地環(huán)境一致# config.py - 數(shù)據(jù)庫連接配置改為你自己的本地參數(shù) DB_HOST 127.0.0.1 # 本機數(shù)據(jù)庫地址不要改成localhost部分版本會走IPv6解析 DB_PORT 3306 # MySQL 5.7默認(rèn)端口 DB_USER root DB_PASSWORD 123456 # 安裝MySQL時設(shè)置的密碼必改 DB_NAME yuqing_db # 與Navicat里新建的庫名保持一致 DB_CHARSET utf8mb4 # 連接字符集亂碼問題百分之八十出在這里3.3 后端啟動虛擬環(huán)境、依賴安裝與入口文件后端項目拿到手第一步永遠(yuǎn)是裝依賴而不是直接運行。源碼包如果在設(shè)計時規(guī)范就會帶一個requirements.txt里面列出了Flask/Django、PyMySQL、jieba等第三方庫。建議在項目根目錄先創(chuàng)建虛擬環(huán)境把依賴隔離在項目內(nèi)部避免和你機器上其他Python項目互相污染。# Windows命令行cd到項目根目錄后執(zhí)行 python -m venv venv venv\Scripts\activate python -m pip install --upgrade pip -i https://pypi.tuna.tsinghua.edu.cn/simple pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple python app.py這段命令每行都有講究。python -m venv venv創(chuàng)建虛擬環(huán)境第一個venv是模塊名第二個是文件夾名你可以改成別的但別用中文。激活后命令行前面會出現(xiàn)(venv)前綴說明現(xiàn)在裝的包都進(jìn)虛擬環(huán)境了。-i參數(shù)指定清華鏡像源如果在國內(nèi)不指定這個裝jieba這種包也可能卡很久。最后的python app.py是啟動后端看到類似Running on http://127.0.0.1:5000的輸出就說明成功了如果報錯提示缺module回到上一步把依賴重新裝一遍注意看是哪個包沒裝上。3.4 功能驗證從注冊到輿情統(tǒng)計的完整路徑系統(tǒng)跑起來之后我建議不要直接點餅狀圖而是走一條最完整的業(yè)務(wù)路徑來驗證它真的正常工作。先注冊一個新用戶觀察注冊接口是否把數(shù)據(jù)寫進(jìn)sys_user表用新用戶登錄在頁面上發(fā)布幾條言論然后回言論列表看能否查詢到最后看統(tǒng)計頁餅狀圖是否產(chǎn)生分組數(shù)據(jù)。這條路徑里的每一步都對應(yīng)前面說的接口注冊對應(yīng)/api/register登錄對應(yīng)/api/login發(fā)布言論對應(yīng)/api/comment/add餅圖對應(yīng)/api/statistics。如果某個環(huán)節(jié)空白優(yōu)先去后端的運行日志里找錯誤而不是猜前端代碼。日志里最常見的報錯是數(shù)據(jù)庫連接失敗、SQL語法錯誤、JSON序列化出錯這三類每類都對應(yīng)明確的位置。4. 輿情分析核心代碼走讀情感判斷與餅狀統(tǒng)計圖的實現(xiàn)思路4.1 言論入庫接口前端傳一句話后端接住并落庫輿情系統(tǒng)最基礎(chǔ)的動作是把用戶言論收集起來。前端拿到用戶輸入的文本打包成JSON發(fā)到后端后端的接口函數(shù)接住JSON完成入庫。我拆的這套源碼里核心接口的寫法是這樣# app.py - 言論發(fā)布與自動分析接口 from flask import Flask, request, jsonify import pymysql, datetime, jieba app Flask(__name__) def get_db(): # 每次請求獨立連接用完即關(guān)避免長連接被MySQL踢掉 conn pymysql.connect(host127.0.0.1, port3306, userroot, password123456, databaseyuqing_db, charsetutf8mb4) return conn app.route(/api/comment/add, methods[POST]) def add_comment(): user_id request.json.get(user_id) content request.json.get(content, ).strip() if not content: return jsonify({code: 1, msg: 言論內(nèi)容不能為空}) sentiment analyze_sentiment(content) # 調(diào)用情感分析函數(shù) conn get_db() cur conn.cursor() sql INSERT INTO comment_info (user_id, content, sentiment, create_time) VALUES (%s, %s, %s, %s) cur.execute(sql, (user_id, content, sentiment, datetime.datetime.now())) conn.commit() cur.close() conn.close() return jsonify({code: 0, msg: 發(fā)布成功, data: {sentiment: sentiment}})這個接口值得一看的是pymysql.connect的寫法。charsetutf8mb4同時出現(xiàn)在建表和連接兩層缺掉任何一層都可能出現(xiàn)寫入正常、讀出亂碼的詭異現(xiàn)象。SQL用%s占位符而不是字符串拼接是為了防SQL注入這也是我建議你在二次開發(fā)時沿用這個習(xí)慣的原因。analyze_sentiment函數(shù)被埋在執(zhí)行SQL之前也就是說每條言論入庫前就已經(jīng)被打好了情感標(biāo)簽這個設(shè)計讓統(tǒng)計接口不需要在查詢時現(xiàn)算。4.2 情感傾向判斷比想象中簡單的分詞加詞典方案輿情分析在課設(shè)項目里不可能上BERT或者深度學(xué)習(xí)合理做法是結(jié)巴分詞加情感詞典。源碼包如果在目錄里帶了dict/positive.txt和dict/negative.txt就說明用的是這個路線。原理不復(fù)雜先對文本分詞把分詞結(jié)果分別跟正面詞表、負(fù)面詞表做匹配命中的詞語數(shù)量之差決定方向沒有命中就是中性。# sentiment.py - 基于詞典的情感傾向判斷 import jieba def load_words(path): # 讀取情感詞典每行一個詞忽略空行 with open(path, encodingutf-8) as f: return {line.strip() for line in f if line.strip()} POS load_words(dict/positive.txt) # 正面詞典 NEG load_words(dict/negative.txt) # 負(fù)面詞典 def analyze_sentiment(text): words [w for w in jieba.lcut(text) if len(w.strip()) 1] pos_count sum(1 for w in words if w in POS) neg_count sum(1 for w in words if w in NEG) if pos_count neg_count: return positive elif neg_count pos_count: return negative return neutral這個函數(shù)的核心參數(shù)有兩個。一個是詞典文件的編碼這里強制用utf-8讀取如果詞典文件本身是GBK編碼這里會直接拋異常你需要改成encodinggbk或者用轉(zhuǎn)換工具把詞典改成UTF-8格式。另一個是len(w.strip()) 1這個過濾條件它把單個字過濾掉因為單個字比如“好”“壞”沒有足夠的語境信息容易誤判但代價是“厲害”這類雙字褒義詞會進(jìn)入判斷。對課設(shè)系統(tǒng)來說這個精度損失可以接受。4.3 餅狀圖數(shù)據(jù)聚合一個接口、一條SQL、一次分組餅狀統(tǒng)計圖的本質(zhì)是數(shù)據(jù)匯總。前端要畫餅圖時后端給出的數(shù)據(jù)應(yīng)該是一個數(shù)組每個元素是一個情感類型和它對應(yīng)的數(shù)量。這個接口的實現(xiàn)是整個系統(tǒng)里最簡潔的部分因為它完全切中了MySQL的分組統(tǒng)計能力。app.route(/api/statistics, methods[GET]) def get_statistics(): conn get_db() cur conn.cursor() sql SELECT sentiment, COUNT(*) AS cnt FROM comment_info GROUP BY sentiment cur.execute(sql) rows cur.fetchall() data [{name: r[0], value: r[1]} for r in rows] cur.close() conn.close() return jsonify({code: 0, data: data})這里有一個很多新手會忽略的技術(shù)點GROUP BY sentiment返回的行如果某類情感在言論表里一條都沒有那它不會出現(xiàn)在結(jié)果里。這意味著你剛部署完系統(tǒng)言論表為空時/api/statistics返回的數(shù)組長度是0前端餅圖表現(xiàn)為空白。這不是Bug是數(shù)據(jù)還沒喂進(jìn)去。驗證這個接口最直接的辦法是用Navicat往comment_info表里手動插入幾條不同sentiment的數(shù)據(jù)再刷新統(tǒng)計頁餅圖應(yīng)該立刻變化。前端拿到這個數(shù)組后用ECharts或者LayUI自帶的圖表模塊渲染餅圖。圖表部分在源碼里通常是一個獨立的JS文件里面調(diào)用了上面這個接口把返回數(shù)據(jù)映射到ECharts的series.data字段。這里要留意前后端字段名的一致性后端返回的是name和value前端圖表組件默認(rèn)認(rèn)識的也是這兩個字段名如果后端改成label和num前端不修改映射邏輯就畫不出來。5. 避坑指南這套源碼部署與二次開發(fā)中的五個典型問題5.1 現(xiàn)象Python 3.6裝依賴時大量報錯pymysql安裝失敗原因新版pymysql在較新的PyPI源里可能要求Python 3.7以上直接pip install會觸發(fā)版本校驗失敗。這類問題在Python 3.6.8上特別典型因為很多庫的較新版本已經(jīng)開始放棄對3.6的支持。解決不要盲目升級庫版本。最穩(wěn)的路徑是以源碼包自帶的requirements.txt為準(zhǔn)安裝時指定版本號比如pip install pymysql0.9.3。如果源碼包沒給版本號就選一個發(fā)布時間和Python 3.6.8接近的舊版本。PyPI源的-i參數(shù)用清華鏡像能避免部分源服務(wù)器對舊版包的CDN支持不完整帶來的下載失敗。5.2 現(xiàn)象數(shù)據(jù)庫導(dǎo)入成功但頁面上的中文全是亂碼原因MySQL 5.7的建庫語句沒有指定utf8mb4或者Navicat導(dǎo)入SQL文件時選擇的編碼格式與文件實際編碼不一致。Windows下國產(chǎn)編輯器默認(rèn)可能把SQL文件存成GBK而數(shù)據(jù)庫用的是UTF-8導(dǎo)入時Navicat按UTF-8解讀GBK文件亂碼就產(chǎn)生了。解決用Navicat連接數(shù)據(jù)庫后右鍵連接屬性把數(shù)據(jù)庫連接編碼改為UTF-8導(dǎo)入SQL前先觀察SQL文件的編碼用記事本打開看中文注釋是否正常如果不正常就用VS Code等工具轉(zhuǎn)換為UTF-8再導(dǎo)入。建庫語句里必須保留DEFAULT CHARACTER SET utf8mb4這是四層編碼里最底層的一層。5.3 現(xiàn)象后端啟動正常但頁面CSS和JS全部加載不出來瀏覽器控制臺報404原因LayUI模板的靜態(tài)資源是用相對路徑引用的比如./layui/css/layui.css。如果前端頁面文件和靜態(tài)資源目錄的相對層級被調(diào)整過或者后端Flask沒有正確掛載static目錄請求路徑對不上就會出現(xiàn)HTML渲染正常、樣式全部丟失的白板頁面。解決打開后端代碼里靜態(tài)文件注冊的配置確認(rèn)Flask把static文件夾掛在了根路徑下并且前端HTML里引用的路徑和后端實際暴露的路徑一致。我常用的排查方式是直接復(fù)制瀏覽器控制臺里報404的完整URL在后端項目目錄里找這個路徑對應(yīng)的真實文件如果找不到就是路徑錯位改前端引用路徑比改后端掛載更省事。5.4 現(xiàn)象系統(tǒng)跑一段時間后突然報數(shù)據(jù)庫連接錯誤重啟后端又恢復(fù)正常原因MySQL 5.7默認(rèn)的wait_timeout是8小時數(shù)據(jù)庫長時間沒有請求時會把空閑連接斷掉。源碼如果用的是每次請求新建連接的方式影響還不大但很多版本為了效率用了連接池池里的舊連接沒被檢測出來下一次請求拿去用就拋異常。解決如果源碼用的是短連接模式報連接錯誤時檢查是不是有人手動在MySQL里執(zhí)行過FLUSH PRIVILEGES或改了密碼權(quán)限。如果是長連接模式建議在后端框架的ORM層開啟連接池的預(yù)檢機制或者在每次請求前測試連接可用性。我在本地跑這套源碼時直接把wait_timeout調(diào)成了86400順手解決了但生產(chǎn)環(huán)境不建議這么干。5.5 現(xiàn)象管理員修改用戶信息后前端列表不刷新必須手動重新登錄原因用戶管理接口更新成功但前端列表沒有重新加載本質(zhì)上是前端沒有在后端操作成功后調(diào)用列表查詢接口。很多畢設(shè)源碼的增刪改操作是獨立接口頁面上操作完了沒有自動刷新列表數(shù)據(jù)的邏輯。解決打開用戶管理頁對應(yīng)的JS文件找到刪除或修改成功的回調(diào)函數(shù)在回調(diào)里加上一行重新請求列表接口的代碼。這也是一個通用的二次開發(fā)習(xí)慣后端接口只管寫庫前端Controller負(fù)責(zé)數(shù)據(jù)同步更新這兩者的同步機制如果沒想清楚幾乎所有管理頁面都會出現(xiàn)“操作成功但界面不變”的錯覺。6. 二次開發(fā)進(jìn)階把課設(shè)輿情系統(tǒng)改成能用的內(nèi)部監(jiān)測工具如果只是為了交畢設(shè)系統(tǒng)跑通就可以收工了。但如果你要把它改造成一個公司內(nèi)部能用的簡易輿情監(jiān)測工具有一個改造我認(rèn)為優(yōu)先級最高把“用戶手動輸入言論”改成“批量導(dǎo)入外部評論”。課設(shè)版本的數(shù)據(jù)完全是用戶自己登進(jìn)去打的真實業(yè)務(wù)里輿情數(shù)據(jù)來自公開平臺的大量評論文本這個差異直接決定系統(tǒng)能不能用。批量導(dǎo)入的思路是加一個Excel或CSV導(dǎo)入接口文件里每一行是一條評論后端逐行執(zhí)行跟手動發(fā)布一樣的入庫流程。關(guān)鍵參數(shù)有兩個一是表頭校驗比如CSV必須包含content列否則直接拒絕導(dǎo)入二是重復(fù)數(shù)據(jù)去重可以用評論內(nèi)容哈希值建一個唯一索引避免同一個文件被重復(fù)導(dǎo)入后餅狀圖數(shù)據(jù)翻倍。驗證方法也比想象中簡單。準(zhǔn)備一百條帶標(biāo)準(zhǔn)情感標(biāo)簽的測試評論導(dǎo)入后用代碼把系統(tǒng)打標(biāo)結(jié)果和標(biāo)準(zhǔn)標(biāo)簽對比統(tǒng)計一致的比例。詞典方案做到60%到70%的準(zhǔn)確率是正常的如果低于這個水平優(yōu)先檢查分詞后是否過濾了單字詞以及情感詞典里是否缺少你測試數(shù)據(jù)所在領(lǐng)域的常見詞。提升準(zhǔn)確率的投入產(chǎn)出比最高的動作就是往詞典里加領(lǐng)域詞而不是換更復(fù)雜的模型。這套源碼的邊界我也提醒一句它對言論的處理是實時的、輕量的沒有定時采集任務(wù)沒有外部平臺數(shù)據(jù)接入也沒有時間序列趨勢圖。如果你所在的場景確實需要這些能力你還要繼續(xù)在此基礎(chǔ)上加定時調(diào)度和爬蟲模塊那已經(jīng)是另一個量級的活了。但作為畢業(yè)設(shè)計、課設(shè)復(fù)現(xiàn)或者作為理解輿情系統(tǒng)如何用PythonMySQL落地的樣本這個項目在“能跑、能拆、能改”上都做到了。我那次拿到手的第一天踩了字符集的坑后來強制給自己定了個習(xí)慣不管哪套源碼解壓后第一件事就是查配置文件的編碼和數(shù)據(jù)庫連接字符集這兩項確認(rèn)沒問題再啟動。從那以后部署這套系統(tǒng)的速度至少快了一倍希望幫到你。本文還有配套的精品資源點擊獲取