簡介針對(duì)JavaWeb方向?qū)W習(xí)與畢業(yè)設(shè)計(jì)人群這份運(yùn)動(dòng)與健康管理系統(tǒng)完整源代碼與數(shù)據(jù)庫資源可用于快速掌握用戶管理、運(yùn)動(dòng)記錄、健康監(jiān)測、數(shù)據(jù)分析等典型模塊的開發(fā)流程也可作為課程設(shè)計(jì)的起始模板。壓縮包共707個(gè)文件約9.59MB整體以jsp頁面與java類承載后端業(yè)務(wù)邏輯js與css負(fù)責(zé)前端交互與樣式gif、jpg提供界面演示素材sql為數(shù)據(jù)庫初始化腳本jar為依賴庫另有html、xml等輔助配置目錄結(jié)構(gòu)清晰便于按模塊對(duì)照學(xué)習(xí)。已有2019人學(xué)習(xí)查看適用于需要參考完整項(xiàng)目實(shí)現(xiàn)、理解表結(jié)構(gòu)設(shè)計(jì)與Servlet/JSP開發(fā)思路的讀者。通過源碼可看到用戶表、運(yùn)動(dòng)記錄表、健康指標(biāo)表的關(guān)聯(lián)方式同時(shí)附帶的項(xiàng)目配置與靜態(tài)資源能幫助還原運(yùn)行環(huán)境是JavaWeb綜合項(xiàng)目實(shí)踐的一份實(shí)用參考資料。1. JavaWeb 運(yùn)動(dòng)與健康管理系統(tǒng)為什么值得下載并且跑通它如果你搜過「javawe 運(yùn)動(dòng)與健康管理系統(tǒng) 源代碼」——沒錯(cuò)后綴少個(gè) b 是常見拼寫——大概率看到一大排壓縮包鏈接。我拆過好幾套之后有個(gè)反直覺的結(jié)論這類系統(tǒng)真正值錢的不是「能登錄、能打卡」的 CRUD 殼子而是數(shù)據(jù)庫表結(jié)構(gòu)和后端分層寫法能不能經(jīng)得起你往里面加需求。這套基于 JSP Servlet MySQL 的經(jīng)典 JavaWeb 架構(gòu)幾乎覆蓋了課設(shè)和畢業(yè)設(shè)計(jì)里所有要求用戶端運(yùn)動(dòng)打卡、個(gè)人健康檔案、管理員后臺(tái)、數(shù)據(jù)統(tǒng)計(jì)預(yù)覽外加完整數(shù)據(jù)庫腳本。適合正在做 JavaWeb 課設(shè)的學(xué)生、想練手 Servlet 全流程的開發(fā)者也想用現(xiàn)成源碼二次改造成內(nèi)部健康管理小工具的人。下面我按拆包順序講先立住數(shù)據(jù)模型再講功能實(shí)現(xiàn)然后把部署時(shí)最容易翻車的三個(gè)坎鋪開說。2. 從 ER 圖到建表腳本運(yùn)動(dòng)打卡數(shù)據(jù)怎么存才不返工2.1 四張核心表用戶、運(yùn)動(dòng)記錄、健康指標(biāo)、管理員拆開數(shù)據(jù)庫腳本一般是一個(gè).sql文件項(xiàng)目解壓后通常放在db/或sql/目錄第一件事不是雙擊導(dǎo)入而是先打開看建表結(jié)構(gòu)。這套系統(tǒng)的核心表有四個(gè)用戶表、運(yùn)動(dòng)記錄表、健康指標(biāo)表、管理員表。健康指標(biāo)表是很多人做設(shè)計(jì)時(shí)候遺漏的一張表——如果沒有它「個(gè)人健康檔案」頁面里的體重、心率、睡眠時(shí)長根本沒有獨(dú)立的數(shù)據(jù)載體最后會(huì)塞進(jìn)用戶表變成一堆冗余字段。四張表的核心字段如下表名核心字段關(guān)鍵設(shè)計(jì)t_userid、username、password、age、gender、height、weight、create_time密碼建議 MD5 處理身高體重冗余存儲(chǔ)方便首頁直接讀t_exercise_recordid、user_id、exercise_type、duration_minutes、calories、record_date、create_time日期用 DATE 類型熱量允許小數(shù)t_health_metricid、user_id、weight、heart_rate、sleep_hours、metric_date、create_time同一天可有多次記錄但預(yù)警統(tǒng)計(jì)時(shí)取最新一條t_adminid、username、password、real_name、role與業(yè)務(wù)表完全解耦登錄入口獨(dú)立為什么運(yùn)動(dòng)記錄表要單獨(dú)拆出來而不是合并進(jìn)用戶表因?yàn)椤高\(yùn)動(dòng)打卡」在業(yè)務(wù)上天然是一對(duì)多的一個(gè)用戶一天可以打卡多次一次跑步一次拉伸是兩條記錄。如果把這些塞進(jìn)用戶表后面寫統(tǒng)計(jì) SQL 時(shí)每查一次運(yùn)動(dòng)時(shí)長都要做字符串切割那才是真正的返工地獄。健康指標(biāo)表同理體重和心率是會(huì)變化的量必須按日期累積不然趨勢圖沒數(shù)據(jù)可畫。2.2 建表腳本主鍵、時(shí)間戳、唯一索引缺一不可不要直接在 Navicat 里手動(dòng)畫表把 SQL 文件拖進(jìn)命令行或客戶端執(zhí)行一遍更穩(wěn)妥。這套系統(tǒng)的核心建表語句大概是這樣的結(jié)構(gòu)CREATE TABLE t_exercise_record ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT 主鍵, user_id INT NOT NULL COMMENT 關(guān)聯(lián) t_user.id, exercise_type VARCHAR(32) NOT NULL COMMENT 運(yùn)動(dòng)類型跑步/游泳/騎行/拉伸, duration_minutes INT NOT NULL COMMENT 運(yùn)動(dòng)時(shí)長單位分鐘, calories DECIMAL(8,2) DEFAULT 0 COMMENT 預(yù)估消耗熱量單位千卡, record_date DATE NOT NULL COMMENT 打卡日期, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 記錄創(chuàng)建時(shí)間, UNIQUE KEY uk_user_date (user_id, record_date, exercise_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT運(yùn)動(dòng)打卡記錄表;這段腳本里值得留意三個(gè)細(xì)節(jié)。第一AUTO_INCREMENT主鍵是常規(guī)選擇刪除記錄后主鍵不會(huì)復(fù)用統(tǒng)計(jì)口徑不會(huì)被過往數(shù)據(jù)污染。第二UNIQUE KEY uk_user_date是我拆這套系統(tǒng)時(shí)最想夸的地方——它防止了「同一天同一種運(yùn)動(dòng)重復(fù)打卡」這個(gè)約束放在應(yīng)用層做要多寫一堆查詢放在數(shù)據(jù)庫層一行就堵死了。第三DECIMAL(8,2)而不是FLOAT熱量計(jì)算要的是精確兩位小數(shù)浮點(diǎn)數(shù)在累計(jì)求和時(shí)會(huì)抖出 0.0000001 的誤差雖然肉眼看不出來但報(bào)表對(duì)不上時(shí)會(huì)讓人懷疑人生。2.3 數(shù)據(jù)類型選型為什么熱量和體重都用 DECIMAL建表腳本里另一個(gè)值得說的是類型選型邏輯。duration_minutes用 INT因?yàn)檫\(yùn)動(dòng)時(shí)長是整數(shù)分鐘calories用 DECIMAL(8,2)因?yàn)闊崃坑?jì)算涉及運(yùn)動(dòng)系數(shù)結(jié)果可能是小數(shù)gmt_create這類時(shí)間字段統(tǒng)一 DATETIME不要用 TIMESTAMP因?yàn)?TIMESTAMP 的范圍只到 2038 年而且受時(shí)區(qū)影響DATETIME 更省心。這里有個(gè)真實(shí)發(fā)生過的教訓(xùn)某開發(fā)者在二次開發(fā)時(shí)把體重字段改成了DOUBLE理由是「JSP 頁面上顯示體重后端接個(gè)字符串就轉(zhuǎn)了無所謂」。后面做月度體重曲線圖時(shí)發(fā)現(xiàn)AVG(weight)出來一串 60.00000000001前端圖表點(diǎn)尾數(shù)全是 1。從那以后我對(duì)建表腳本的原則就是凡是展示給用戶看、參與計(jì)算或者聚合的數(shù)值一律 DECIMALFLOAT/DOUBLE只允許出現(xiàn)在科學(xué)計(jì)算這種不追求精確的場景。3. 用戶端四個(gè)功能模塊登錄、打卡、報(bào)表、個(gè)人中心的后端實(shí)現(xiàn)3.1 從 JSP 到 Servlet 的請(qǐng)求流轉(zhuǎn)一次打卡請(qǐng)求怎么走完整條鏈路這套系統(tǒng)是典型的 MVC 結(jié)構(gòu)JSP 負(fù)責(zé)渲染Servlet 負(fù)責(zé)接請(qǐng)求調(diào)業(yè)務(wù)DAO 負(fù)責(zé)和數(shù)據(jù)庫打交道。很多新手把 JSP 直接寫上 Java 代碼頁面里塞一堆%那不是不能跑但后面改需求時(shí)會(huì)變得沒法看。這套系統(tǒng)的分層拆得比較干凈——雖然代碼不是最新式框架但「JSP 只負(fù)責(zé)收參數(shù)、Servlet 只負(fù)責(zé)轉(zhuǎn)方向、DAO 只負(fù)責(zé)數(shù)據(jù)庫」這條線是清楚的。登錄請(qǐng)求的流轉(zhuǎn)大概是這樣的用戶在login.jsp輸入用戶名密碼表單methodpost提交到LoginServlet。Servlet 調(diào)用UserDao.findByUsernameAndPassword()查到了就把user對(duì)象放進(jìn) Session跳轉(zhuǎn)index.jsp查不到就request.setAttribute(error, 用戶名或密碼錯(cuò)誤)轉(zhuǎn)發(fā)回登錄頁。核心代碼是這樣WebServlet(/login) public class LoginServlet extends HttpServlet { private UserDao userDao new UserDao(); Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding(UTF-8); String username request.getParameter(username); String password request.getParameter(password); User user userDao.findByUsernameAndPassword(username, password); if (user ! null) { HttpSession session request.getSession(); session.setAttribute(loginUser, user); response.sendRedirect(request.getContextPath() /index.jsp); } else { request.setAttribute(error, 用戶名或密碼錯(cuò)誤); request.getRequestDispatcher(/login.jsp).forward(request, response); } } }這里有個(gè)關(guān)鍵參數(shù)容易被忽略request.setCharacterEncoding(UTF-8)必須放在getParameter()調(diào)用之前。如果這一行漏了或放后面中文用戶名和密碼會(huì)亂碼查庫直接失敗下次登錄會(huì)顯示「用戶名或密碼錯(cuò)誤」而實(shí)際上密碼是對(duì)的——這個(gè)坑后面避坑章還會(huì)詳細(xì)說。getParameter拿到的全是字符串DAO 層做密碼校驗(yàn)后返回User對(duì)象或null這只是項(xiàng)目里最常見的寫法不是唯一寫法。3.2 打卡核心DAO 層插入前先做「重復(fù)判斷」運(yùn)動(dòng)打卡是用戶端最核心的操作。前端表單收集運(yùn)動(dòng)類型、時(shí)長、日期提交到AddExerciseServletServlet 調(diào)ExerciseRecordDao.insert(). 真正寫代碼時(shí)要處理的業(yè)務(wù)邏輯是同一天同一種運(yùn)動(dòng)不能重復(fù)打卡。數(shù)據(jù)庫那層UNIQUE KEY是兜底但在應(yīng)用層最好也先查一次因?yàn)閿?shù)據(jù)庫報(bào)DuplicateKeyException時(shí)異常不夠友好頁面直接白屏。public boolean insert(ExerciseRecord record) { String checkSql SELECT id FROM t_exercise_record WHERE user_id ? AND record_date ? AND exercise_type ?; String insertSql INSERT INTO t_exercise_record (user_id, exercise_type, duration_minutes, calories, record_date) VALUES (?, ?, ?, ?, ?); try (Connection conn DBUtil.getConnection(); PreparedStatement checkPs conn.prepareStatement(checkSql); PreparedStatement insertPs conn.prepareStatement(insertSql)) { checkPs.setInt(1, record.getUserId()); checkPs.setDate(2, new java.sql.Date(record.getRecordDate().getTime())); checkPs.setString(3, record.getExerciseType()); ResultSet rs checkPs.executeQuery(); if (rs.next()) { return false; // 當(dāng)天同類型已存在返回 false 由 Servlet 提示用戶 } insertPs.setInt(1, record.getUserId()); insertPs.setString(2, record.getExerciseType()); insertPs.setInt(3, record.getDurationMinutes()); insertPs.setBigDecimal(4, record.getCalories()); insertPs.setDate(5, new java.sql.Date(record.getRecordDate().getTime())); return insertPs.executeUpdate() 0; } catch (SQLException e) { e.printStackTrace(); return false; } }這段代碼用了三重嵌套的try-with-resources連接和語句都會(huì)自動(dòng)關(guān)閉這在 JDK 7 之后的支持很好課設(shè)代碼里常見老式finally手動(dòng)關(guān)連接但那樣一旦中間某個(gè)語句異常連接就泄漏了。PreparedStatement用占位符?傳參避免拼接 SQL 導(dǎo)致注入——這是這類項(xiàng)目必須做扎實(shí)的點(diǎn)因?yàn)檫\(yùn)動(dòng)健康系統(tǒng)涉及用戶隱私數(shù)據(jù)登錄接口如果用拼接字符串被注入一次就全表淪陷。3.3 個(gè)人中心把體重、心率、睡眠聚合成一張數(shù)據(jù)卡個(gè)人中心頁面展示用戶最近一次體重、心率以及近 7 天運(yùn)動(dòng)匯總。頁面組裝的 SQL 邏輯比 Java 循環(huán)聚合方便得多。近 7 天匯總的典型寫法是在 SQL 層按日期分組SELECT record_date, SUM(duration_minutes) AS total_minutes, SUM(calories) AS total_calories FROM t_exercise_record WHERE user_id ? AND record_date DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY record_date ORDER BY record_date ASC;這段 SQL 里DATE_SUB(CURDATE(), INTERVAL 7 DAY)是計(jì)算「7 天前」的日期CURDATE()只取當(dāng)前日期不取時(shí)間避免當(dāng)天凌晨打卡被日期邊界問題干擾。用GROUP BY record_date按天聚合返回的結(jié)果直接就是前端圖表想要的數(shù)據(jù)結(jié)構(gòu)Java 層只需要while(rs.next())循環(huán)塞進(jìn) List不需要在內(nèi)存里做二次求和。這里不要用SELECT *再在 Java 里算總和——數(shù)據(jù)庫做聚合比 Java 循環(huán)快得多而且代碼量少一半。這套系統(tǒng)里所有涉及「按時(shí)間統(tǒng)計(jì)」的地方基本都是這個(gè)套路理解了這一條后面管理后臺(tái)的統(tǒng)計(jì)圖表你基本也能看懂。4. 管理后臺(tái)與統(tǒng)計(jì)視圖讓運(yùn)動(dòng)數(shù)據(jù)變成健康畫像4.1 用戶管理不靠「刪除」靠「狀態(tài)位」管理后臺(tái)的用戶管理模塊常見的課設(shè)實(shí)現(xiàn)是「點(diǎn)刪除直接 DELETE FROM t_user」這套系統(tǒng)用的是軟刪除t_user表里有一個(gè)status字段0正常、1禁用。管理員點(diǎn)擊「禁用」時(shí)執(zhí)行的 SQL 不是刪除而是更新狀態(tài)位UPDATE t_user SET status 1 WHERE id ?為什么這樣做因?yàn)橛脩舻倪\(yùn)動(dòng)記錄表t_exercise_record.user_id關(guān)聯(lián)了用戶表主鍵如果直接物理刪除用戶記錄表里的歷史數(shù)據(jù)就成了孤行——統(tǒng)計(jì)報(bào)表會(huì)出現(xiàn)「查不到用戶名只有一串?dāng)?shù)字」的臟數(shù)據(jù)。軟刪除之后登錄校驗(yàn)會(huì)自動(dòng)加一個(gè)status 0的條件被禁用的用戶雖然還在表里但登錄不進(jìn)去歷史數(shù)據(jù)仍然可以被后臺(tái)統(tǒng)計(jì)。這里有兩點(diǎn)補(bǔ)充。第一刪運(yùn)動(dòng)記錄和刪用戶是兩回事如果只是為了騰空間刪的是記錄表數(shù)據(jù)如果是封號(hào)動(dòng)的是用戶表狀態(tài)位。第二如果你在二次開發(fā)時(shí)要同時(shí)干凈清除某個(gè)用戶的所有數(shù)據(jù)那要先把t_exercise_record、t_health_metric里的關(guān)聯(lián)記錄刪掉最后再刪t_user順序反過來外鍵會(huì)報(bào)錯(cuò)。4.2 健康預(yù)警一條 SQL 揪出「久坐高危用戶」這套系統(tǒng)后臺(tái)有個(gè)健康預(yù)警模塊邏輯很簡單最近 7 天運(yùn)動(dòng)總時(shí)長低于 30 分鐘的用戶會(huì)被標(biāo)為「運(yùn)動(dòng)不足」。這個(gè)模塊的價(jià)值不在算法多高級(jí)而在 SQL 怎么寫——只用一條關(guān)聯(lián)子查詢就能掃出全表高危用戶。SELECT u.id, u.username, IFNULL(SUM(e.duration_minutes), 0) AS total_minutes FROM t_user u LEFT JOIN t_exercise_record e ON e.user_id u.id AND e.record_date DATE_SUB(CURDATE(), INTERVAL 7 DAY) WHERE u.status 0 GROUP BY u.id HAVING total_minutes 30;注意這里用的是LEFT JOIN而不是INNER JOIN因?yàn)橐粋€(gè)用戶如果在過去 7 天壓根沒運(yùn)動(dòng)他不會(huì)有任何記錄行用 INNER JOIN 會(huì)把他漏掉LEFT JOIN保證每個(gè)用戶都出現(xiàn)在結(jié)果集里IFNULL(SUM(...), 0)把沒有記錄的用戶的匯總值填補(bǔ)成 0。最后HAVING total_minutes 30是在分組后過濾WHERE做不到這一點(diǎn)——這是新手寫統(tǒng)計(jì) SQL 最常見的翻車點(diǎn)WHERE在分組前執(zhí)行它不認(rèn)識(shí)聚合列加上HAVING才能對(duì)分組后的聚合結(jié)果過濾。4.3 統(tǒng)計(jì)圖表的數(shù)據(jù)接口聚合查詢怎么寫才不難看管理后臺(tái)的首頁通常有「運(yùn)動(dòng)類型占比」「每日活躍用戶數(shù)」等圖表。這套系統(tǒng)的圖表數(shù)據(jù)走的是 JSON 接口由一個(gè)StatisticServlet返回。典型的查詢是統(tǒng)計(jì)每種運(yùn)動(dòng)類型的累計(jì)時(shí)長 TOP5SELECT exercise_type, SUM(duration_minutes) AS total_minutes FROM t_exercise_record WHERE record_date DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY exercise_type ORDER BY total_minutes DESC LIMIT 5;執(zhí)行完這個(gè)查詢后后臺(tái)把每行結(jié)果轉(zhuǎn)成 JSON 數(shù)組格式大概是[[跑步, 320], [騎行, 180]]前端圖表庫直接拿數(shù)組渲染餅圖或柱狀圖。這個(gè)數(shù)據(jù)接口有兩個(gè)常見問題一是LIMIT 5會(huì)截?cái)鄶?shù)據(jù)餅圖的「其他」類別需要 Java 層手動(dòng)把第 6 名以后的數(shù)據(jù)合并成一行「其他」二是日期范圍 30 天是常量如果想讓管理員在頁面上自定義日期范圍把這個(gè)常量替換成參數(shù)即可——StatisticServlet里加一個(gè)receiveParam(days)默認(rèn) 30接口就變通用了。圖表聯(lián)動(dòng)這塊這套系統(tǒng)的實(shí)現(xiàn)不算復(fù)雜但架構(gòu)是通的前端定時(shí)請(qǐng)求/statistic/recent拿到上次時(shí)間戳之后的新增打卡記錄直接更新圖表數(shù)據(jù)點(diǎn)。如果你要把它改成實(shí)時(shí)大屏追加推送通道就行不用動(dòng)后端查詢接口。5. 部署避坑實(shí)錄JDK 版本、字符集、連接池這幾個(gè)坎最常翻車5.1 JDK 版本與 MySQL 驅(qū)動(dòng)不匹配ClassNotFoundException 不是驅(qū)動(dòng)沒放現(xiàn)象Tomcat 啟動(dòng)后訪問登錄頁一切正常一提交表單直接白屏控制臺(tái)拋ClassNotFoundException: com.mysql.cj.jdbc.Driver。很多人第一反應(yīng)是「缺 jar」把驅(qū)動(dòng)包反復(fù)拷進(jìn)WEB-INF/lib還是報(bào)錯(cuò)。原因這個(gè)項(xiàng)目如果數(shù)據(jù)庫腳本是用 MySQL 5.x 寫的而本機(jī)裝的是 MySQL 8.x舊版驅(qū)動(dòng)com.mysql.jdbc.Driver在 MySQL 8 連接串下已經(jīng)不適用了。更隱蔽的是如果本機(jī)用的是 JDK 8 但驅(qū)動(dòng)包是新版也會(huì)因?yàn)榫幾g版本問題拋UnsupportedClassVersionError。解決先確認(rèn) MySQL 版本。MySQL 5.x 用com.mysql.jdbc.DriverMySQL 8.x 用com.mysql.cj.jdbc.Driver同時(shí)要把連接串加參數(shù)serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingUTF-8。改完之后重啟 Tomcat如果還拋Public Key Retrieval is not allowed再在連接串加allowPublicKeyRetrievaltrue。這三個(gè)參數(shù)是這類項(xiàng)目里最常見的「差一個(gè)就死」配置。5.2 中文亂碼三個(gè)地方字符集不一致表單提交就變問號(hào)現(xiàn)象登錄頁中文用戶名輸入「張三」點(diǎn)擊登錄后提示「用戶名或密碼錯(cuò)誤」打開數(shù)據(jù)庫查到username存的值是????。頁面顯示正常一寫庫就亂。原因字符集有三層任何一層不一致都會(huì)翻車——JSP 頁面編碼、Servlet 接收請(qǐng)求的編碼、MySQL 表結(jié)構(gòu)的編碼。很多時(shí)候建表腳本用的utf8實(shí)際是 MySQL 的 utf8mb3而 JDBC 連接串沒帶characterEncodingUTF-8數(shù)據(jù)庫層就把 Java 傳來的字符串按默認(rèn)字符集轉(zhuǎn)換中文全部變成問號(hào)。解決逐層核對(duì)。把建表腳本的DEFAULT CHARSETutf8mb4統(tǒng)一寫死JDBC 連接串帶useUnicodetruecharacterEncodingUTF-8每個(gè) Servlet 的doPost第一行加request.setCharacterEncoding(UTF-8)如果頁面是動(dòng)態(tài)渲染還要檢查 JSP 頂部contentTypetext/html; charsetUTF-8是否漏了。這一套走完中文亂碼基本根治。5.3 數(shù)據(jù)庫連不上本地能跑換臺(tái)機(jī)器就報(bào) Connection refused現(xiàn)象源碼在自己電腦上跑得好好的發(fā)給某同事或換了一臺(tái)電腦啟動(dòng)后訪問列表頁直接報(bào)Communications link failure或者Access denied for user。原因這類項(xiàng)目的數(shù)據(jù)庫配置通常寫在src/jdbc.properties或db.properties里常見寫法是jdbc.urljdbc:mysql://localhost:3306/health。換機(jī)器后如果目標(biāo)機(jī)器的 MySQL 沒建同名數(shù)據(jù)庫、用戶名密碼不一致或者本機(jī) MySQL 端口不是 3306直接連不上是必然的。更隱蔽的是配置里用了絕對(duì)路徑加載配置文件導(dǎo)致別人那邊資源加載失敗。解決拆包后第一件事就是打開jdbc.properties或DBUtil.java里的連接常量確認(rèn)庫名、用戶名、密碼和當(dāng)前環(huán)境一致。導(dǎo)入數(shù)據(jù)庫前先確認(rèn)庫是否建好、腳本是否完整跑完、navicat 里能否用同樣的賬號(hào)密碼直接連上。如果jdbc.properties路徑有問題建議把配置文件直接放到src根目錄用類路徑加載避免FileNotFoundException。5.4 Tomcat 9 下 EL 表達(dá)式不生效頁面輸出 ${user.username}現(xiàn)象JSP 頁面里寫了${user.username}出來不是值而是原樣顯示字符串“${user.username}”。頁面不上數(shù)據(jù)也不報(bào)錯(cuò)數(shù)據(jù)在 Servlet 端明明查到了。原因Tomcat 對(duì) JSP 的 EL 支持默認(rèn)分版本Servlet 3.0 / JSP 2.2 以上才默認(rèn)開啟 EL但項(xiàng)目如果用了老的 web.xml 頭聲明比如web-app版本是 2.3 或 2.4EL 會(huì)被當(dāng)成普通文本。很多課設(shè)項(xiàng)目的 web.xml 是多年前從網(wǎng)上抄的頭聲明版本過低就等于關(guān)閉了 EL 求值。解決把web.xml頭改成 Servlet 3.1Tomcat 8/9 都支持或者干脆把web-app根元素版本聲明升級(jí)到 3.0 以上。如果不想動(dòng) web.xml更省事的做法是把${user.username}改成% ((User)request.getSession().getAttribute(loginUser)).getUsername() %先跑通功能再回頭收拾版本號(hào)。6. 把課設(shè)升級(jí)成真實(shí)項(xiàng)目的第一步把 JDBC 直連接成 Druid 連接池6.1 為什么第一步要換連接池高并發(fā)只是順帶的穩(wěn)定才是剛需課設(shè)代碼里的DBUtil.getConnection()常見寫法是DriverManager.getConnection(url, user, password)每次請(qǐng)求都新建物理連接。單機(jī)演示沒問題一旦頁面里多個(gè)圖表接口同時(shí)請(qǐng)求MySQL 的連接數(shù)會(huì)被打滿報(bào)Too many connections。Druid 連接池的核心價(jià)值不是「變快」而是「連接復(fù)用 自動(dòng)回收」讓應(yīng)用負(fù)載上來時(shí)不會(huì)瞬間把數(shù)據(jù)庫壓垮。這個(gè)改造的復(fù)雜度并不高因?yàn)樗粍?dòng)DBUtil一個(gè)類。6.2 改造步驟DruidUtil 替換 DriverManager在src目錄加一個(gè)druid.propertiesdriverClassNamecom.mysql.cj.jdbc.Driver urljdbc:mysql://localhost:3306/health?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/Shanghai usernameroot password123456 initialSize5 maxActive20 maxWait10000 testWhileIdletrue validationQuerySELECT 1然后新建一個(gè)DruidUtil.javapublic class DruidUtil { private static DataSource dataSource; static { try (InputStream in DruidUtil.class.getClassLoader() .getResourceAsStream(druid.properties)) { Properties props new Properties(); props.load(in); dataSource DruidDataSourceFactory.createDataSource(props); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } }改完之后原來調(diào)DBUtil.getConnection()的地方只需要把類名換成DruidUtilDAO 代碼一行都不用動(dòng)。initialSize5是啟動(dòng)時(shí)預(yù)先創(chuàng)建 5 個(gè)連接maxActive20是連接池上限超過這個(gè)數(shù)新請(qǐng)求會(huì)進(jìn)入maxWait等待隊(duì)列testWhileIdletrue會(huì)在連接閑置時(shí)用SELECT 1探活避免拿到已被數(shù)據(jù)庫掐斷的死連接。這幾個(gè)參數(shù)里validationQuerySELECT 1是這套系統(tǒng)最值得折騰的一行——MySQL 8 默認(rèn)連接超時(shí)是 8 小時(shí)如果晚上掛服務(wù)器第二天早上訪問報(bào)連接斷十有八九是沒加探活語句。6.3 驗(yàn)證改造有沒有生效改完后用如下方式自查正常啟動(dòng)項(xiàng)目多刷新幾個(gè)圖表頁然后打開 MySQL 命令行執(zhí)行SHOW STATUS LIKE Threads_connected;。如果連接池生效這個(gè)值應(yīng)該穩(wěn)定在個(gè)位數(shù)而不是隨著訪問量增長連續(xù)刷新 50 次頁面后再看連接數(shù)不會(huì)猛增。如果報(bào)Too many connections八成是maxActive配得太高而 MySQL 的max_connections默認(rèn)才 151把maxActive調(diào)到 20 以下基本不會(huì)再碰到。從那以后我每次拿到新源碼不管是課設(shè)還是畢設(shè)第一件事就是先打開數(shù)據(jù)庫配置文件和連接工具類配合當(dāng)前環(huán)境把連接池、字符集、驅(qū)動(dòng)版本一次配齊再啟動(dòng)項(xiàng)目。這套運(yùn)動(dòng)健康系統(tǒng)斷斷續(xù)續(xù)解剖了幾天數(shù)據(jù)庫腳本從頭到尾過了一遍該藏的坑基本都翻出來了。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取