簡介這套基于JavaEE與MySQL的酒店管理系統(tǒng)畢業(yè)設(shè)計資料包內(nèi)容圍繞完整的客房業(yè)務(wù)場景設(shè)計適合具備一定編程基礎(chǔ)的學(xué)生和開發(fā)者將其作為畢業(yè)設(shè)計、課程設(shè)計或工程實(shí)訓(xùn)的參考項(xiàng)目。壓縮包為ZIP格式整體大小約186.81MB涵蓋完整的JavaEE項(xiàng)目源碼、MySQL數(shù)據(jù)庫初始化腳本、畢業(yè)論文、答辯PPT以及演示視頻等主要文件類型便于從開發(fā)、文檔到答辯全流程使用。項(xiàng)目功能覆蓋客戶管理、客房管理、菜品管理、餐桌預(yù)定和餐飲消費(fèi)管理并給出了JDK與Tomcat以及MySQL環(huán)境下的具體部署方案降低了復(fù)現(xiàn)與二次開發(fā)難度。數(shù)據(jù)庫腳本可獨(dú)立導(dǎo)入MySQL快速搭建可運(yùn)行環(huán)境。已有156人瀏覽學(xué)習(xí)借助源碼、論文和視頻可以掌握酒店管理系統(tǒng)的模塊劃分、數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計與業(yè)務(wù)實(shí)現(xiàn)思路同時適合作為論文寫作和答辯準(zhǔn)備的參考模板。1. 基于javaEEMySQL的酒店管理系統(tǒng)畢設(shè)選題里的老牌剛需選題時最怕的是“聽起來很新做起來沒底”。酒店管理系統(tǒng)在 javaEE 方向里屬于典型的老牌剛需需求不復(fù)雜但房費(fèi)計算、訂單狀態(tài)、會員折扣這些業(yè)務(wù)邏輯能把 CRUD 做出真實(shí)感而且數(shù)據(jù)庫表關(guān)系復(fù)雜度適中拿來當(dāng)畢業(yè)設(shè)計正好。標(biāo)題里那套源碼、數(shù)據(jù)庫 SQL、論文、答辯 PPT 和演示視頻之所以成為經(jīng)典配置是因?yàn)榇蠖鄶?shù)人的痛點(diǎn)不是寫不出代碼而是不知道業(yè)務(wù)鏈路怎么閉環(huán)、答辯怎么講。這篇筆記把主題鎖定在基于 javaEEMySql 酒店管理系統(tǒng)的完整落地路徑上從技術(shù)選型、建庫建表、核心功能實(shí)現(xiàn)到部署排查和答辯亮點(diǎn)按我實(shí)際帶項(xiàng)目的順序?qū)懡o你。適合正在做酒店管理系統(tǒng)畢業(yè)設(shè)計的人也適合想用這個老題目補(bǔ)齊分層架構(gòu)和數(shù)據(jù)庫基本功的初級開發(fā)者。2. 技術(shù)選型與項(xiàng)目骨架javaEEMySQL的組合為什么最穩(wěn)2.1 三種方案的分寸感Servlet/JSP、SSH、SSM到底該選誰拿到這個標(biāo)題第一個要拍板的就是主框架。市面上這類系統(tǒng)的主流做法有三種純 Servlet JSP JDBC、SSHStruts2 Spring Hibernate、SSMSpring SpringMVC MyBatis。不少同學(xué)一看 SSH 是“當(dāng)年企業(yè)標(biāo)配”就撲上去結(jié)果被 Struts2 的攔截器配置和 Hibernate 的懶加載坑到懷疑人生。我的建議很直接論文題目寫的是 javaEE 而不是 SpringBoot說明評審期待的是你能講清分層架構(gòu)和 Java Web 原生運(yùn)行機(jī)制純 Servlet JSP JDBC/連接池反而是最穩(wěn)妥的答案。為什么這么說酒店管理系統(tǒng)的核心是訂單和房態(tài)這類強(qiáng)業(yè)務(wù)邏輯場景里Servlet 負(fù)責(zé)接收請求、調(diào)用 Service、控制頁面跳轉(zhuǎn)JSP 只負(fù)責(zé)渲染這個 MVC 結(jié)構(gòu)在答辯時三句話就能講完。SSH 里的 Hibernate 映射關(guān)系在學(xué)習(xí)成本上占比太高Struts2 的 valueStack 又是個黑匣子一旦頁面取值取不到排查鏈路非常長。SSM 當(dāng)然也可以但 MyBatis 的 XML 映射文件會分散你對業(yè)務(wù)設(shè)計的注意力而且框架版本之間經(jīng)常出現(xiàn) jar 包沖突不少人的畢設(shè)時間就耗在“啟動報錯—搜依賴—換版本”這個循環(huán)里。用原生 Servlet 還有一個隱藏優(yōu)勢它最能體現(xiàn)你理解 HTTP 請求的生命周期。SpringBoot 固然是當(dāng)前主流但如果你在畢業(yè)設(shè)計里用 SpringBoot評委大概率會追問“那 javaEE 的 Servlet、Filter、Listener 你還熟嗎”到時候你如果只能說“框架封裝了”場面會比較被動。我的做法是主鏈路用 Servlet JSP JDBC Druid 連接池把 Spring 的 IoC 思想用在 Service 層的接口與實(shí)現(xiàn)分離上這樣既有原生味道又能體現(xiàn)設(shè)計意識。2.2 從 JDK 到 Tomcat跑通項(xiàng)目前的三個環(huán)境檢查環(huán)境準(zhǔn)備這一步看著基礎(chǔ)但翻車率極高。我見過太多次“代碼沒問題環(huán)境不對”的案例尤其是 MySQL 8 和 Tomcat 版本組合出的幺蛾子。下面這套檢查順序是我每次搭 javaEE 環(huán)境都會走的java -version mysql -u root -p -e status; cd /path/to/tomcat/bin ./catalina.sh run第一條確認(rèn) JDK 版本javaEE 項(xiàng)目用 JDK 8 或 11 最穩(wěn)JDK 17 配老 Tomcat 偶爾會碰到模塊訪問限制。第二條確認(rèn) MySQL 服務(wù)是真的活著而不是只在安裝向?qū)Ю铩翱雌饋硌b好了”。第三條直接前臺啟動 Tomcat能看到完整日志比雙擊 startup.bat 一閃而過強(qiáng)太多。如果你用 VSCode 配 javaEE 語言環(huán)境記得把 Tomcat 的 lib 目錄加進(jìn) referenced libraries否則 Servlet 類會飄紅。Tomcat 版本這里提前打個預(yù)防針如果用 Tomcat 10 或更高Servlet 的包名已經(jīng)從 javax.servlet 換成了 jakarta.servlet很多老源碼直接跑會 ClassNotFound。這篇標(biāo)題對應(yīng)的項(xiàng)目源碼大概率是按 Tomcat 8/9 寫的所以我建議你直接用 Tomcat 9省去一批包名改造工作。項(xiàng)目放對位置也很關(guān)鍵webapps/ROOT還是webapps/你的項(xiàng)目名會影響訪問路徑我習(xí)慣放在webapps/hotel下然后通過http://localhost:8080/hotel訪問這樣后續(xù)部署到云服務(wù)器時路徑不用改。2.3 web.xml 是入口說明書Servlet 映射與全局配置打開 javaEE 老項(xiàng)目的第一件事先看 web.xml。這個文件決定了哪些請求進(jìn)哪個 Servlet、靜態(tài)資源怎么放行、默認(rèn)首頁是誰。下面是我常用的最小配置web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee version3.1 servlet servlet-nameLoginServlet/servlet-name servlet-classcom.hotel.web.LoginServlet/servlet-class /servlet servlet-mapping servlet-nameLoginServlet/servlet-name url-pattern/login.do/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.jsp/welcome-file /welcome-file-list /web-app這里有兩處值得注意。servlet-class必須和源碼里的包名完全一致大小寫都不能錯否則啟動時不報錯訪問時才 404。url-pattern盡量用/login.do這種精確匹配不要圖省事寫/*因?yàn)?*會攔截所有請求包括 JSP 頁面本身的渲染請求造成“所有頁面白屏只有 Servlet 正?！钡脑幃惉F(xiàn)象。Servlet 版本 3.1 對應(yīng) Tomcat 8/9如果你用注解WebServlet(/login.do)替代 web.xml 配置也可以但論文里最好把 web.xml 的寫法也放上去因?yàn)樗?javaEE 規(guī)范的直觀體現(xiàn)。2.4 數(shù)據(jù)庫連接配置Druid 連接池與 jdbc.properties數(shù)據(jù)庫連接這塊最忌諱在 DAO 里DriverManager.getConnection()每次現(xiàn)連。酒店管理系統(tǒng)要扛住前臺高頻查詢連接池是必須的。常見做法是用 Druid配置寫在jdbc.properties里便于替換環(huán)境jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/hotel_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue jdbc.usernameroot jdbc.password123456 jdbc.maxActive10 jdbc.initialSize2URL 里的參數(shù)每一個都是血淚教訓(xùn)。serverTimezoneAsia/Shanghai不寫MySQL 8 會直接報時區(qū)錯誤useSSLfalse是關(guān)掉本地開發(fā)環(huán)境的 SSL 證書校驗(yàn)避免驅(qū)動每次連接都去驗(yàn)證證書allowPublicKeyRetrievaltrue解決 MySQL 8 的 caching_sha2_password 認(rèn)證插件在非安全連接下取公鑰的問題。characterEncodingutf8必須寫在 URL 里不然哪怕數(shù)據(jù)庫和頁面都是 UTF-8JDBC 傳輸過程中也會亂碼。配套的工具類一般是靜態(tài)代碼塊加載配置并創(chuàng)建數(shù)據(jù)源public class DbUtil { private static DruidDataSource ds; static { try { Properties p new Properties(); p.load(DbUtil.class.getClassLoader() .getResourceAsStream(jdbc.properties)); ds (DruidDataSource) DruidDataSourceFactory.createDataSource(p); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public static Connection getConn() throws SQLException { return ds.getConnection(); } }ResourceAsStream的路徑是 classpath 根目錄所以jdbc.properties必須放在 src 根目錄或 resources 目錄下放錯位置會在靜態(tài)塊里拋空指針這種啟動報錯最容易讓人誤判成“包沒導(dǎo)全”。連接池的maxActive不要貪大本地開發(fā) 10 個足夠設(shè)成 50 反而會讓 MySQL 的線程數(shù)飆升拖慢整機(jī)響應(yīng)。3. 數(shù)據(jù)庫設(shè)計先行把酒店業(yè)務(wù)釘進(jìn) MySQL 的 7 張核心表3.1 從業(yè)務(wù)流程到表結(jié)構(gòu)先理清角色和狀態(tài)再建表酒店管理系統(tǒng)的數(shù)據(jù)庫設(shè)計核心是回答四個問題誰在用系統(tǒng)、房間有什么狀態(tài)、訂單怎么流轉(zhuǎn)、退房怎么算錢。我習(xí)慣把角色拆成三類系統(tǒng)管理員管房型和房間信息前臺負(fù)責(zé)預(yù)訂、入住、退房和結(jié)賬經(jīng)理看營業(yè)報表。圍繞這些角色核心表可以收斂為 7 張系統(tǒng)用戶表sys_user、會員表t_member、房型表t_room_type、房間表t_room、預(yù)訂訂單表t_order、入住登記表t_checkin、消費(fèi)明細(xì)表t_consume。房型和房間為什么要拆兩張表因?yàn)椤皟r格”和“房間”是一對多的關(guān)系如果把價格直接寫進(jìn)房間表改一次房價就要 UPDATE 幾十行而且容易漏。下面是一個精簡但完整的建表片段CREATE TABLE t_room_type ( id INT PRIMARY KEY AUTO_INCREMENT, type_name VARCHAR(20) NOT NULL COMMENT 單人間/雙人間/套房, base_price DECIMAL(10,2) NOT NULL COMMENT 基準(zhǔn)價/晚, hourly_price DECIMAL(10,2) DEFAULT 0 COMMENT 鐘點(diǎn)房價/小時, bed_num TINYINT DEFAULT 1 COMMENT 床位數(shù), breakfast TINYINT DEFAULT 0 COMMENT 1含早 0不含早, status TINYINT DEFAULT 1 COMMENT 1啟用 0停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_room ( id INT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(10) NOT NULL UNIQUE COMMENT 門牌號, room_type_id INT NOT NULL, floor_no TINYINT COMMENT 所在樓層, room_status TINYINT DEFAULT 0 COMMENT 0空閑 1已預(yù)訂 2已入住 3維修 4臟房, remark VARCHAR(255), FOREIGN KEY (room_type_id) REFERENCES t_room_type(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;價格字段用DECIMAL(10,2)而不是 FLOAT是因?yàn)楦↑c(diǎn)數(shù)在計算房費(fèi)時會出現(xiàn) 0.10.2 不等于 0.3 的問題金額出錯在酒店這種場景里非常致命。room_status用 TINYINT 存數(shù)字而不是直接存中文是為了后續(xù)狀態(tài)流轉(zhuǎn)時用 int 比較和更新更高效中文狀態(tài)值應(yīng)該由前端字典翻譯。UNIQUE約束加在room_no上防止重復(fù)門牌號。所有表統(tǒng)一ENGINEInnoDB因?yàn)橛唵魏腿胱〉怯浶枰聞?wù)支持MyISAM 不支持行級鎖和事務(wù)回滾。接下來是訂單表它的設(shè)計決定了預(yù)訂、入住、取消這條主鏈路的復(fù)雜度CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 訂單號格式日期隨機(jī)數(shù), room_id INT NOT NULL, cust_name VARCHAR(30) NOT NULL, cust_phone VARCHAR(20), member_id INT COMMENT 會員ID可為空, plan_in_date DATE COMMENT 預(yù)計入住日期, plan_out_date DATE COMMENT 預(yù)計離店日期, hours INT DEFAULT 0 COMMENT 鐘點(diǎn)房小時數(shù), order_status TINYINT DEFAULT 0 COMMENT 0已預(yù)訂 2已入住 3已取消 4已離店, pre_amount DECIMAL(10,2) COMMENT 預(yù)付金額, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_room_status (room_id, order_status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;訂單表里我把預(yù)計入住和預(yù)計離店拆成兩個 DATE 字段而不是一個時間段字段這樣查“明天有哪些房要退”只需WHERE plan_out_date DATE_ADD(CURDATE(), INTERVAL 1 DAY)索引也能用上。order_no不要用自增 ID 直接展示給客戶酒店行業(yè)習(xí)慣看到日期開頭的單號我一般用yyyyMMddHHmmss 三位隨機(jī)數(shù)生成。最后那行INDEX很重要房態(tài)列表頁最頻繁的查詢就是“按房間和時間過濾訂單”沒有這個聯(lián)合索引數(shù)據(jù)量過萬后會明顯變慢。3.2 房態(tài)流轉(zhuǎn)別用字符串裸奔狀態(tài)機(jī)與條件更新房間狀態(tài)是整個系統(tǒng)的命脈。前臺操作的每一步都在改t_room.room_status空閑 → 已預(yù)訂客人下單→ 已入住客人到店→ 臟房退房后保潔→ 空閑。如果代碼里到處直接寫UPDATE t_room SET room_status 2 WHERE id 1不出一個星期就會出現(xiàn)“房間明明被預(yù)訂了另一個前臺還能開出去”的并發(fā)問題。我的做法是在狀態(tài)流轉(zhuǎn)處統(tǒng)一走 Service 方法并且用條件 UPDATE 實(shí)現(xiàn)樂觀鎖START TRANSACTION; UPDATE t_room SET room_status 2 WHERE id #{roomId} AND room_status 1; -- 受影響行數(shù)為 0 說明房間不是“已預(yù)訂”狀態(tài)下單失敗 INSERT INTO t_checkin (order_id, room_id, cust_name, real_in_time) VALUES (#{orderId}, #{roomId}, #{custName}, NOW()); COMMIT;這段 SQL 的精髓在AND room_status 1。如果兩個前臺同時操作同一間房MySQL 的行鎖會讓后到的 UPDATE 等待但等鎖釋放后它的 WHERE 條件已經(jīng)匹配不上最新狀態(tài)受影響行數(shù)為 0代碼里就能捕獲到這個失敗并提示“房間狀態(tài)已變化”。這就是用數(shù)據(jù)庫自身的能力做并發(fā)控制比在 Java 代碼里加 synchronized 靠譜得多也更容易在答辯時講出亮點(diǎn)。另外強(qiáng)調(diào)一個容易忽略的細(xì)節(jié)臟房狀態(tài)一定要有?？腿送朔亢蠓块g需要保潔如果直接置為“空閑”下一個客人入住時發(fā)現(xiàn)房間沒打掃就是事故。我見過不少畢設(shè)把狀態(tài)只做成“已入住/空閑”兩態(tài)業(yè)務(wù)上其實(shí)是不完整的。哪怕你這個系統(tǒng)的保潔模塊只是一個按鈕也要有“一鍵標(biāo)記臟房”和“保潔完成恢復(fù)空閑”這兩個動作這會讓評審覺得你想到了真實(shí)場景。3.3 導(dǎo)入導(dǎo)出 SQL 腳本導(dǎo)入前先建庫外鍵別硬剛源碼包里通常附帶一個hotel.sql或db.sql這是整個項(xiàng)目的數(shù)據(jù)庫資產(chǎn)。拿到手先別急著source我一般按下面這套流程走mysql -u root -p -e CREATE DATABASE IF NOT EXISTS hotel_db DEFAULT CHARACTER SET utf8mb4; mysql -u root -p hotel_db hotel_db.sql第二條命令前必須先建庫因?yàn)槟_本里多數(shù)只包含表和數(shù)據(jù)的 INSERT不會幫你建庫。如果腳本沒有指定USE hotel_db;導(dǎo)入時會一直報“No database selected”。另外很多腳本開頭有DROP TABLE IF EXISTS這本身沒問題但如果表之間有外鍵約束DROP 父表時會失敗。遇到這種情況先執(zhí)行一句SET FOREIGN_KEY_CHECKS0;再導(dǎo)導(dǎo)完再設(shè)回 1。這個坑在 Workbench 里特別常見明明點(diǎn)了 Forward Engineer生成的腳本里 DROP 順序卻是亂的。導(dǎo)出備份時用mysqldump更專業(yè)一些尤其答辯前一定要備份一次mysqldump -u root -p hotel_db hotel_db_backup.sql如果是用 MySQL Workbench 管理表結(jié)構(gòu)注意導(dǎo)出時勾選 “Dump Stored Procedures and Functions” 和 “Dump Events”否則你在 Workbench 里建的存儲過程不會進(jìn)到腳本里。字符集方面建議建庫時一律utf8mb4不要用utf8MySQL 的 utf8 實(shí)際是 utf8mb3存不了 emoji 和部分生僻漢字客人姓名里有生僻字時頁面就會顯示成問號。4. 代碼主線從登錄到退房結(jié)賬的完整鏈路實(shí)現(xiàn)4.1 登錄與權(quán)限一個 Session 撐起的最簡 RBAC登錄是整個系統(tǒng)的大門也是答辯時評委必看的第一段代碼。常見做法是在login.jsp收集用戶名和密碼提交到LoginServlet驗(yàn)證成功后把用戶信息放進(jìn) Session。注意兩點(diǎn)密碼不能明文存庫前端傳過來的密碼要做哈希后比對DAO 層必須用 PreparedStatement 防 SQL 注入。核心代碼如下WebServlet(/login.do) public class LoginServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setCharacterEncoding(UTF-8); String username req.getParameter(username); String password Md5Util.hash(req.getParameter(password)); SysUser user new UserDao().findByNameAndPwd(username, password); if (user ! null) { HttpSession session req.getSession(); session.setAttribute(loginUser, user); session.setAttribute(role, user.getRole()); resp.sendRedirect(req.getContextPath() /index.jsp); } else { req.setAttribute(msg, 賬號或密碼不正確); req.getRequestDispatcher(/login.jsp).forward(req, resp); } } }sendRedirect和forward的區(qū)別要搞清楚登錄成功后重定向是為了避免刷新頁面時重復(fù)提交表單登錄失敗后轉(zhuǎn)發(fā)是為了把msg帶回到登錄頁顯示。DAO 層里的查詢語句務(wù)必用占位符String sql SELECT * FROM sys_user WHERE username? AND password?; try (PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, username); ps.setString(2, password); try (ResultSet rs ps.executeQuery()) { if (rs.next()) { ... } } }為什么不直接String sql SELECT * FROM sys_user WHERE username username 因?yàn)榍芭_在用戶名框里輸入 OR 11就能繞過密碼直接登錄這在答辯現(xiàn)場是致命傷。做了 PreparedStatement 之后評委如果追問安全加固你還可以補(bǔ)一句“我對密碼做了加鹽哈希并對 Session 里的角色做了 Filter 攔截”。4.2 預(yù)訂到入住事務(wù)邊界和房間鎖定的實(shí)戰(zhàn)寫法預(yù)訂到入住這條鏈路是最能體現(xiàn)工程能力的部分。業(yè)務(wù)流程是前臺選擇房型 → 提交訂單 → 系統(tǒng)把房間從“空閑”改為“已預(yù)訂” → 客人到店后“入住登記” → 訂單狀態(tài)從“已預(yù)訂”改為“已入住”。這兩步必須在一個事務(wù)里否則會出現(xiàn)訂單插入成功但房間狀態(tài)沒變或者房間被占但訂單丟失的情況。public boolean createOrder(Order order) { Connection conn null; try { conn DbUtil.getConn(); conn.setAutoCommit(false); RoomDao roomDao new RoomDao(); int rows roomDao.updateStatus(2, 1, order.getRoomId()); if (rows 0) { conn.rollback(); return false; } orderDao.insert(order); conn.commit(); return true; } catch (SQLException e) { if (conn ! null) { try { conn.rollback(); } catch (SQLException ex) { ex.printStackTrace(); } } throw new RuntimeException(預(yù)訂下單失敗, e); } finally { if (conn ! null) { try { conn.setAutoCommit(true); conn.close(); } catch (SQLException e) { } } } }這段代碼里roomDao.updateStatus(2, 1, order.getRoomId())對應(yīng)的是UPDATE t_room SET room_status 2 WHERE id ? AND room_status 1受影響行數(shù)為 0 說明房間狀態(tài)已經(jīng)不是“空閑”直接回滾避免臟數(shù)據(jù)。事務(wù)邊界要覆蓋“改狀態(tài)”和“插訂單”兩個動作少了任何一個都不完整。最后在 finally 里把a(bǔ)utoCommit恢復(fù)成 true 再關(guān)連接是因?yàn)檫B接池里的連接是復(fù)用的如果不重置狀態(tài)下一次拿到這條連接的人會在一個殘留的事務(wù)里執(zhí)行 SQL查不到數(shù)據(jù)時很難排查。4.3 退房結(jié)賬算法統(tǒng)一按自然日計費(fèi)別用浮點(diǎn)數(shù)算錢退房結(jié)賬是酒店管理系統(tǒng)里最有“業(yè)務(wù)含金量”的部分。房費(fèi)怎么算業(yè)界常見做法是“按自然日計費(fèi)”即入住當(dāng)天算一天離店日的中午 12 點(diǎn)前退房不額外收費(fèi)超過 12 點(diǎn)加收半天或一天房費(fèi)。你不需要做得和真實(shí) PMS 一樣復(fù)雜但至少要把“天數(shù) × 房價 消費(fèi) - 折扣”這條公式寫對。public BigDecimal calcAmount(Order order, ListConsumeItem items) { long days ChronoUnit.DAYS.between( order.getPlanInDate(), order.getPlanOutDate()); BigDecimal roomFee order.getBasePrice() .multiply(BigDecimal.valueOf(days)); BigDecimal total roomFee; for (ConsumeItem item : items) { total total.add(item.getAmount()); } if (order.getMember() ! null) { total total.multiply(order.getMember().getDiscount()); } return total.setScale(2, RoundingMode.HALF_UP); }ChronoUnit.DAYS.between計算兩個 LocalDate 之間的天數(shù)注意這個方法返回的是 long如果退房日等于入住日返回 0分鐘房訂單要走單獨(dú)的分支。所有金額運(yùn)算必須用BigDecimal乘法之后調(diào)用setScale(2, RoundingMode.HALF_UP)做四舍五入否則會出現(xiàn) 113.500000001 這種結(jié)果。會員折扣如果存在t_member表里是 0.9 這種小數(shù)做百分比換算時也要用 BigDecimal不能轉(zhuǎn) double 后再回來。這段算法建議單獨(dú)抽一個PriceCalculator類不要寫在 JSP 里面試時把類名報出來會比“我的代碼都寫在 Servlet 里”聽起來專業(yè)得多。5. 避坑清單本地能跑不代表答辯能過5.1 JDBC 連 MySQL 8 報 SSL 與時區(qū)錯誤現(xiàn)象項(xiàng)目啟動后第一次訪問數(shù)據(jù)庫控制臺拋The server time zone value й? is unrecognized或者Establishing SSL connection without servers identity verification is not recommended前端頁面上表現(xiàn)為登錄按鈕點(diǎn)了沒反應(yīng)后臺卻能看到 SQLException。原因MySQL 8 的 JDBC 驅(qū)動com.mysql.cj.jdbc.Driver默認(rèn)要求帶時區(qū)參數(shù)而連接串里沒寫同時驅(qū)動默認(rèn)會去校驗(yàn) SSL 證書本地自建庫沒有合理證書就會報警告甚至連接失敗。解決在jdbc.url后追加useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue。useSSLfalse的意思是本地開發(fā)環(huán)境不走證書驗(yàn)證只要不是公網(wǎng)傳輸敏感數(shù)據(jù)這個參數(shù)沒問題。如果用的是 MySQL 5.7驅(qū)動可以換com.mysql.jdbc.Driver或不加 serverTimezone但為了兼容性我統(tǒng)一按 8 的寫法來。另外確認(rèn)mysql-connector-java的 jar 包版本和 MySQL 服務(wù)端版本不要差太遠(yuǎn)5.x 的驅(qū)動去連 8.x 服務(wù)端會直接報Unable to load authentication plugin caching_sha2_password。5.2 連不上本地 MySQLsocket 文件、端口和認(rèn)證插件三連現(xiàn)象命令行執(zhí)行mysql -u root -p報ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock或者 Java 代碼里報Communications link failure。原因這條報錯的意思是客戶端默認(rèn)通過 unix socket 文件連本地庫但/tmp/mysql.sock不存在最直接的原因是服務(wù)沒啟動其次是 MySQL 的 socket 文件路徑被改過。如果你在 Java 里用localhost連接驅(qū)動也會優(yōu)先走 socket 而不是 TCP。解決先確認(rèn)服務(wù)真的活著systemctl status mysql mysqladmin -u root -p status如果服務(wù)活著但 socket 路徑不對一條路是找到my.cnf里socket的路徑另一條更省事的辦法是在 JDBC URL 里把localhost改成127.0.0.1強(qiáng)制走 TCP 端口繞開 socket 文件。按下葫蘆浮起瓢的情況也有明明 MySQL 起來了端口卻是 3307這種多實(shí)例安裝導(dǎo)致的坑用netstat -tlnp | grep 3306看端口占用就能定位。最后還有一種排查點(diǎn)root 賬號在 MySQL 8 默認(rèn)用caching_sha2_password認(rèn)證老驅(qū)動不支持時可以考慮把賬號改成mysql_native_password這屬于常規(guī)兼容操作。5.3 中文亂碼從過濾器、連接參數(shù)到建表字符集四層排查現(xiàn)象登錄頁面輸入中文用戶名提交后變成“”或數(shù)據(jù)庫表里看中文是亂碼又或者頁面能顯示中文但查詢條件帶中文查不到數(shù)據(jù)。原因亂碼是四層字符集不一致疊加的結(jié)果誰都不能獨(dú)善其身。POST 請求體沒有設(shè)置 UTF-8JSP 頁面本身pageEncoding不對JDBC 連接串里沒帶characterEncodingutf8建表時用了latin1默認(rèn)字符集。任何一層斷了最終表現(xiàn)都是亂碼。解決從上到下一層層堵漏。最省事的做法是加一個全局編碼過濾器覆蓋所有請求WebFilter(/*) public class EncodingFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { req.setCharacterEncoding(UTF-8); resp.setContentType(text/html; charsetUTF-8); chain.doFilter(req, resp); } }有了這個過濾器POST 請求體里的中文基本穩(wěn)了。連接串里的characterEncodingutf8負(fù)責(zé) JDBC 傳輸層建庫時DEFAULT CHARSETutf8mb4負(fù)責(zé)存儲層JSP 頭部的pageEncodingUTF-8負(fù)責(zé)視圖層。四層都對齊后把表里已存在的亂碼數(shù)據(jù) DELETE 掉重新錄入不要想著 UPDATE 能救回來亂碼數(shù)據(jù)通常是不可逆的。5.4 Tomcat 10 換包名導(dǎo)致 404 與 ClassNotFoundjavax 和 jakarta 的分水嶺現(xiàn)象同一套源碼照著教程配 Tomcat 10項(xiàng)目能啟動但訪問 Servlet 路徑時 404后臺報java.lang.NoClassDefFoundError: javax/servlet/ServletException或ClassNotFoundException: javax.servlet.http.HttpServlet。原因Tomcat 10 開始全面遷移到 Jakarta EE 9Servlet API 的包名從javax.servlet改成了jakarta.servlet。老項(xiàng)目源碼里的import javax.servlet.*在 Tomcat 10 的 classpath 里找不到對應(yīng)類但 Tomcat 本身又用了一些兼容機(jī)制所以啟動階段不一定報錯直到真正加載 Servlet 類才炸。解決兩條路。第一直接換回 Tomcat 9這是最不折騰的方案源碼里所有javax.servlet都不用動JDK 8 或 11 都支持。第二堅持用 Tomcat 10 的話用 IDEA 或 VSCode 的全局替換把所有import javax.servlet.改成import jakarta.servlet.同時把 web.xml 里的xmlns命名空間也改成 Jakarta EE 的版本。對畢業(yè)設(shè)計來說我強(qiáng)烈建議選第一條路因?yàn)槟悻F(xiàn)在的時間應(yīng)該花在業(yè)務(wù)和答辯上而不是給 Servlet 包名做遷移。順帶提醒源碼包里提供的readme.txt如果寫了“運(yùn)行環(huán)境Tomcat 8/9”就老老實(shí)實(shí)按它說的配別自己升級到 Tomcat 10 再花兩天排錯。6. 答辯展示與項(xiàng)目進(jìn)化把演示視頻和存儲過程變成加分項(xiàng)6.1 演示視頻也是技術(shù)資產(chǎn)按業(yè)務(wù)劇本錄別錄操作流水賬標(biāo)題里那套視頻資源別只把它當(dāng)作“給老師看一眼的東西”。我的經(jīng)驗(yàn)是越是這種成套交付的畢設(shè)越要自己重錄一版演示視頻因?yàn)閯e人的視頻里項(xiàng)目名可能和你的論文題目不一致。錄制時按“預(yù)訂 → 入住登記 → 消費(fèi)記賬 → 退房結(jié)賬 → 營業(yè)報表”這條業(yè)務(wù)鏈來剪每個步驟 3 到 5 秒的停留即可后臺代碼不用錄進(jìn)去但數(shù)據(jù)庫表要切出來看一眼讓評委知道數(shù)據(jù)是真實(shí)落庫的。視頻里最好單獨(dú)錄一段異常操作比如重復(fù)預(yù)訂同一間房時系統(tǒng)的報錯提示這在答辯時主動講出來比被動回答“并發(fā)怎么辦”更有說服力。6.2 加一個 MySQL 存儲過程做日報匯總馬上拔高項(xiàng)目檔次如果你的代碼包里沒有存儲過程強(qiáng)烈建議加一個。酒店管理系統(tǒng)天然適合用存儲過程做夜間統(tǒng)計因?yàn)榉块g數(shù)有限統(tǒng)計邏輯固定不需要高并發(fā)數(shù)據(jù)庫端跑批量任務(wù)正合適。比如生成每日營業(yè)報表DELIMITER $$ CREATE PROCEDURE proc_daily_report(IN p_date DATE) BEGIN INSERT INTO t_report (report_date, order_count, room_income, consume_income) SELECT p_date, COUNT(DISTINCT order_id), SUM(room_fee), SUM(consume_fee) FROM t_checkin WHERE DATE(create_time) p_date; END$$ DELIMITER ;在答辯時講清楚“我為什么不用 Java 在代碼里統(tǒng)計”因?yàn)閳蟊斫y(tǒng)計要掃大量訂單數(shù)據(jù)放到數(shù)據(jù)庫端執(zhí)行可以減少網(wǎng)絡(luò)傳輸而且可以掛在 MySQL 事件調(diào)度器里每天凌晨自動跑。就這一句話立刻讓你的項(xiàng)目從“CRUD 管理系統(tǒng)”變成“有真實(shí)工程考慮的系統(tǒng)”。另一個低成本亮點(diǎn)是用第四章講的樂觀鎖房態(tài)流轉(zhuǎn)把同一間房并發(fā)預(yù)訂的失敗場景截圖放進(jìn)論文配上行的鎖機(jī)制解釋這是評委最想看的“異常處理”素材。最后說個我做畢設(shè)輔導(dǎo)時的習(xí)慣每次答辯前我會把項(xiàng)目當(dāng)產(chǎn)品重新過一遍專門挑那些“正常人不會點(diǎn)”的操作去試比如在預(yù)訂頁直接改成房號 999看看系統(tǒng)有沒有報錯提示把系統(tǒng)日期改到跨月看看報表統(tǒng)計是否正常。這些不是刁難自己而是提前把黑匣子摸清總比你站在臺上被評委問到啞口無言強(qiáng)。希望這篇筆記能幫你把 javaEEMySQL 這個經(jīng)典組合做成一份經(jīng)得起追問的作品。本文還有配套的精品資源點(diǎn)擊獲取