簡介這是一套基于Java技術(shù)棧的家政服務(wù)平臺完整項目采用SpringBoot搭建后端適合作為計算機相關(guān)專業(yè)畢業(yè)設(shè)計、課程設(shè)計或工程實訓(xùn)的參考模板。資源涵蓋全套源碼、數(shù)據(jù)庫SQL腳本及論文文檔能夠幫助學(xué)習(xí)者快速搭建可運行的系統(tǒng)并理解前后端交互、權(quán)限管理、訂單流轉(zhuǎn)等典型業(yè)務(wù)模塊的實現(xiàn)思路。壓縮包內(nèi)共949個文件以java、js、vue、html等前端與后端代碼文件為主同時包含svg、gif、jpg等靜態(tài)資源以及sql數(shù)據(jù)庫文件、配置文件和說明文檔整體體積僅17.71MB便于下載傳閱。目前已有87人學(xué)習(xí)使用項目經(jīng)過測試可直接運行適合不同起點的學(xué)習(xí)者按需取用。除了直接復(fù)刻功能外還可以基于現(xiàn)有代碼擴展預(yù)約服務(wù)、評價管理或數(shù)據(jù)可視化等模塊既滿足畢設(shè)驗收要求也為后續(xù)深入開發(fā)提供了清晰的技術(shù)骨架。1. 為什么“基于Java的家務(wù)服務(wù)平臺”是高分畢設(shè)項目的常青樹畢設(shè)季一到各種“高分項目”資源包就開始流通。這類“基于Java的家務(wù)服務(wù)平臺的系統(tǒng)包含全套源碼 數(shù)據(jù)庫sql 論文.rar”是其中最典型的一種Java 寫的完整工程、能直接導(dǎo)入的數(shù)據(jù)庫腳本、一篇配套論文三者打包成一個壓縮包。它背后是一個完整的業(yè)務(wù)閉環(huán)——用戶預(yù)約保潔、阿姨接單、管理員管上下架和派單比傳統(tǒng)圖書管理系統(tǒng)多出訂單狀態(tài)流轉(zhuǎn)、時間沖突檢查、評價結(jié)算這些能拿上臺面的內(nèi)容。適合正在找 Java 畢設(shè)或課設(shè)參考的人也適合想從純 CRUD 走向業(yè)務(wù)閉環(huán)的初學(xué)者。但解壓只是開始“解壓成功、啟動失敗”才是這類資源最常見的歸宿。Java 環(huán)境、數(shù)據(jù)庫版本、端口沖突、依賴缺失任何一環(huán)都能讓一個看起來完美的項目卡死在控制臺。下面按我實際做這類家政平臺的路徑把打開壓縮包到能演示、能答辯的全過程拆開講。2. 壓縮包背后是一套什么系統(tǒng)技術(shù)棧選型與模塊邊界2.1 為什么是 Spring Boot MyBatis MySQL這套技術(shù)棧好在哪標題里只寫了“基于 Java”但家政服務(wù)平臺在畢設(shè)圈里的主力組合其實非常固定Spring Boot 負責把配置瑣事處理掉MyBatis 負責寫關(guān)聯(lián)查詢和動態(tài) SQLMySQL 存數(shù)據(jù)前端用 JSP Bootstrap 或 Thymeleaf 渲染頁面。選這套不是因為它新而是它在“代碼量可控”和“能講清楚”之間最平衡。Spring Boot 的核心價值是自動配置和起步依賴。一個家政平臺最常用到的無非 web、mybatis、mysql 驅(qū)動這幾個 starterpom.xml 里依賴不沖突IDE 一刷新就能拉完。這對新手很友好不需要像 SSH 時代那樣手動拼一堆 XML 配置。MyBatis 的優(yōu)勢在于預(yù)約這類業(yè)務(wù)有大量“按條件查詢”的場景查某阿姨某天有沒有空、查某用戶所有狀態(tài)的訂單、按時間區(qū)間統(tǒng)計營收。MyBatis 的 XML 里寫動態(tài) SQL比 JPA 的派生方法更直觀也更容易讓答辯評委看懂。說白了它把 SQL 從黑匣子重新變成了你手里的籌碼。MySQL 則是 Java 畢設(shè)中的默認選項免費、資料多、圖形客戶端多。搭配 Navicat 或 DBeaver 就能完成建庫、導(dǎo)數(shù)據(jù)、看表結(jié)構(gòu)的全部操作。壓縮包里的“數(shù)據(jù)庫sql”絕大多數(shù)也是針對 MySQL 寫的拿到手先確認腳本頭部的建庫語句別一上來就往 SQL Server 或 PostgreSQL 里塞。2.2 三個角色、四個模塊先看業(yè)務(wù)邊界再去看代碼拿到這類壓縮包第一件事不是解壓后盲目 import而是在腦子里建立系統(tǒng)邊界。家政平臺再花哨也逃不出三個角色管理員、雇主用戶、服務(wù)人員阿姨。圍繞這三個角色業(yè)務(wù)上一般拆成四個模塊用戶與權(quán)限、服務(wù)目錄、預(yù)約與訂單、評價與結(jié)算。角色典型功能用戶注冊登錄、瀏覽服務(wù)項目、填寫上門時間與地址、下單支付、查看訂單、評價服務(wù)人員查看分配給我的單、開始服務(wù)、完成服務(wù)、查看收入記錄管理員服務(wù)項目上架/下架、阿姨信息維護、訂單查看與派單、統(tǒng)計報表理解這個邊界有什么用第一是有目的地讀源碼先找 controller 層看路由前綴就知道每個模塊落在哪個包。第二是被問到“為什么這樣設(shè)計”時有話可答訂單不直接掛在用戶表下而是獨立成表因為訂單是核心實體它同時關(guān)聯(lián)用戶、服務(wù)人員、服務(wù)項目和時間。配套論文通常會把系統(tǒng)設(shè)計放一整章里面有 ER 圖、用例圖。我一般建議先看論文里的 ER 圖把它抄到草稿紙上再對著去找表。從數(shù)據(jù)庫入手讀一個未知項目比從 controller 一層層往下摸快得多也更容易在論文答辯時講出“我對這個系統(tǒng)有整體把握”的感覺。2.3 改好 application.yml 里這幾行項目才有機會啟動解壓后的第一道門檻是 Java 版本與 Maven 能否對上。常見的是 JDK 8 配 Spring Boot 2.x這類項目多半能在 JDK 8 上跑。進 IDEA 后先等 Maven 把依賴下完再改配置文件。要改的第一個文件幾乎必然是 src/main/resources/application.yml 或 application.properties。spring: datasource: url: jdbc:mysql://localhost:3306/housekeeping?useSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/ShanghaicharacterEncodingutf8 username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mvc: view: prefix: /WEB-INF/jsp/ suffix: .jsp mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.housekeeping.entity configuration: map-underscore-to-camel-case: true這段配置里最值得解釋的是 URL 上的三個參數(shù)serverTimezone 不設(shè)MySQL 8 會報時區(qū)錯誤allowPublicKeyRetrievaltrue 不設(shè)連接時會報 Public Key Retrieval is not allowedcharacterEncodingutf8 不設(shè)中文會變成問號。驅(qū)動類名也分版本MySQL 8 對應(yīng) com.mysql.cj.jdbc.Driver5.x 是 com.mysql.jdbc.Driver寫錯就直接 ClassNotFound。MyBatis 部分有個容易被忽視的開關(guān)map-underscore-to-camel-case。表字段 create_time 要自動映射到實體類的 createTime靠的就是它。不打開查詢結(jié)果里這些字段全是 null訂單時間顯示為空排查起來非常像玄學(xué)問題。如果原來是手寫 resultMap 的項目這一行開不開都行但大多數(shù)畢設(shè)項目都依賴這個自動映射。注意這里的 password 要改成你自己本機的 MySQL 密碼庫名 housekeeping 要和第三章導(dǎo)入的庫名一致。如果項目用了 JSP 視圖mvc.view 里的 prefix 和 suffix 決定了控制器返回的字符串如何對應(yīng)到 jsp 文件路徑配錯的表現(xiàn)是“頁面 404 但接口正常”。3. 初始化家政平臺數(shù)據(jù)庫SQL 腳本導(dǎo)入與關(guān)鍵表結(jié)構(gòu)拆解壓縮包名字里“數(shù)據(jù)庫sql”占了三個字但很多人恰恰在這一步翻車。腳本本身可能沒問題問題出在導(dǎo)入方式、字符集選擇以及 MySQL 版本差異上。3.1 用命令行導(dǎo)入 SQL 的正確姿勢拿到 .sql 文件后我一般不用圖形客戶端去“運行 SQL 文件”一個大文件整體執(zhí)行因為一旦中間某條語句報錯后半段全部作廢出錯信息還容易被界面吞掉。更穩(wěn)妥的方式是命令行分步做先建庫再選庫最后 source。mysql -uroot -p # 進入 MySQL 命令行后逐條執(zhí)行 CREATE DATABASE IF NOT EXISTS housekeeping DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE housekeeping; SET NAMES utf8mb4; SOURCE /path/to/housekeeping.sql;如果不想進交互式命令行也可以直接用一行命令完成建庫和導(dǎo)入mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS housekeeping DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; mysql -uroot -p housekeeping --default-character-setutf8mb4 housekeeping.sql這里建庫必須用 utf8mb4 而不是 utf8。家政平臺的服務(wù)名稱、地址、評價內(nèi)容里都可能出現(xiàn)生僻字或表情符號utf8mb4 是 MySQL 里真正能存下四字節(jié)字符的字符集utf8 在某些版本下只能存三字節(jié)一旦插入含表情的內(nèi)容就報錯。COLLATE 選 utf8mb4_unicode_ci 是為了排序和比較行為更符合常規(guī)預(yù)期。導(dǎo)入后立刻驗證表數(shù)量和數(shù)據(jù)量別急著啟動項目USE housekeeping; SHOW TABLES; SELECT COUNT(*) FROM appointment;如果表數(shù)量對不上多半是腳本執(zhí)行到一半中斷。此時不要盲目重跑整個文件先看第一次報錯停在哪張表修復(fù)后再重來。重復(fù)執(zhí)行完整腳本通常是無害的因為建表語句前面往往有 DROP TABLE IF EXISTS但前提是你已經(jīng)知道這個約定。3.2 六張核心表搞懂它們才敢說“這個系統(tǒng)拿下了”家政平臺的表數(shù)量一般在十幾張上下但核心不出下面這六張。先把它們的職責和關(guān)聯(lián)關(guān)系理清再去看具體的 CREATE TABLE效率會高很多。表名作用關(guān)鍵字段user三個角色共用一張用戶表id, username, password, role, phoneservice_category服務(wù)分類如日常保潔、深度清潔id, name, sortservice_item具體的服務(wù)項目掛在分類下id, category_id, name, price, detailappointment預(yù)約/訂單主表全系統(tǒng)的心臟id, order_no, user_id, worker_id, status, service_date, slot_start, slot_endevaluation用戶的評價記錄id, order_id, user_id, score, contentadmin_log管理員操作日志答辯加分項id, admin_id, action, create_time以訂單主表為例一個典型的建表語句長這樣CREATE TABLE appointment ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT 訂單號支付回調(diào)的唯一依據(jù), user_id INT NOT NULL COMMENT 下單用戶, worker_id INT NOT NULL COMMENT 服務(wù)人員ID, service_item_id INT NOT NULL COMMENT 服務(wù)項目ID, service_date DATE NOT NULL COMMENT 服務(wù)日期, slot_start TIME NOT NULL COMMENT 預(yù)約開始時間, slot_end TIME NOT NULL COMMENT 預(yù)約結(jié)束時間, address VARCHAR(255) NOT NULL COMMENT 上門地址, amount DECIMAL(10,2) NOT NULL COMMENT 訂單金額, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待付款 1待服務(wù) 2服務(wù)中 3待確認 4已完成 5已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_worker_date (worker_id, service_date), KEY idx_user_status (user_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT家政預(yù)約訂單表;這個表的結(jié)構(gòu)信息量很大。order_no 必須有唯一索引它是支付回調(diào)時的冪等依據(jù)后面第四章會展開。status 用 TINYINT 而不是字符串省空間、查詢快代價是代碼里必須有一一對應(yīng)的枚舉否則狀態(tài)含義全靠猜。復(fù)合索引 idx_worker_date 直接支撐“查阿姨某天有沒有單”這個高頻查詢?nèi)绻┙ㄓ唵瘟恳簧先ナ醉摬榭臻e阿姨的接口就會明顯變慢。3.3 字段冗余和索引設(shè)計評委最愛追問的兩個細節(jié)家政平臺的訂單表特別適合做字段冗余。什么是冗余就是把 service_item 里的服務(wù)名稱、單價以及 user 表里的阿姨姓名在下單那一刻直接復(fù)制一份存到訂單表里而不是下單后每次都去關(guān)聯(lián)查詢。原因很簡單服務(wù)項目的價格和名稱會變阿姨也可能改名。如果訂單表只存 service_item_id三個月后改一次價歷史訂單的金額就對不上了。冗余之后訂單表自帶“當時的服務(wù)叫什么、多少錢、誰來做”審計和售后都有依據(jù)。答辯時把這個點講出來評委通常會認可你有真實業(yè)務(wù)意識。索引方面除了 order_no 唯一索引和 worker_id service_date 復(fù)合索引還建議給 status 加普通索引。管理端列表頁最常見的就是“按狀態(tài)查訂單”和“按用戶查訂單”這兩個查詢在數(shù)據(jù)量上來之前看不出差別但索引的成本很低順手加上不吃虧。有一點要提醒別迷信外鍵。常見做法是表與表之間只靠邏輯關(guān)聯(lián)不建物理外鍵。物理外鍵在導(dǎo)入 SQL 時對執(zhí)行順序有要求刪除數(shù)據(jù)時也容易受阻對畢設(shè)項目的演示和答辯反而是一種負擔。用代碼保證數(shù)據(jù)一致性外鍵只畫在論文的 ER 圖里這是這個體量下的務(wù)實選擇。4. 預(yù)約到結(jié)算的完整閉環(huán)訂單狀態(tài)機與時間沖突家政平臺和電商系統(tǒng)的本質(zhì)區(qū)別在于商品是標準化的服務(wù)是發(fā)生在特定時間、特定地點的。因此訂單狀態(tài)機和時間沖突檢查是這個系統(tǒng)真正值錢的地方。4.1 訂單狀態(tài)從 0 到 5狀態(tài)機怎么設(shè)計操作邊界在哪一個家政訂單從創(chuàng)建到結(jié)束通常會經(jīng)歷六個狀態(tài)。狀態(tài)用數(shù)字存庫但代碼里必須用枚舉管住不能讓業(yè)務(wù)代碼隨便 setStatus。public enum OrderStatus { PENDING_PAY(0, 待付款), PAID(1, 待服務(wù)), SERVING(2, 服務(wù)中), CONFIRM(3, 待確認), FINISHED(4, 已完成), CANCELLED(5, 已取消); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code code; this.desc desc; } public static boolean canChange(int from, int to) { switch (from) { case 0: return to 1 || to 5; // 待付款可支付或取消 case 1: return to 2 || to 5; // 待服務(wù)可開始服務(wù)或取消 case 2: return to 3; // 服務(wù)中只能進入待確認 case 3: return to 4 || to 5; // 待確認可完成或取消 default: return false; // 已完成/已取消是終態(tài) } } }這個枚舉的價值是讓“非法跳轉(zhuǎn)”在代碼層面就沒有入口。比如從“服務(wù)中”跳到“已完成”繞過用戶確認這一步系統(tǒng)就不允許。演示時如果有人從數(shù)據(jù)庫手工改狀態(tài)或者接口被重復(fù)調(diào)用狀態(tài)機能把異常狀態(tài)攔在業(yè)務(wù)邏輯之外。每個狀態(tài)變化的操作者是誰也要明確待付款→待服務(wù)是用戶點擊支付后觸發(fā)待服務(wù)→服務(wù)中是阿姨點擊“開始服務(wù)”服務(wù)中→待確認是阿姨點擊“完成服務(wù)”待確認→已完成是用戶點擊“確認并評價”。管理員可以查看所有訂單但不應(yīng)該能隨意改狀態(tài)頂多在異常情況下做人工取消和退款操作。這里強烈建議再加一張 order_status_log 表記錄每次狀態(tài)的 from、to、操作人、操作時間。它本身不復(fù)雜但能讓你在答辯時回答“訂單從下單到完成經(jīng)歷了哪些步驟”這個問題時拿出真實數(shù)據(jù)展示而不是空口描述。4.2 阿姨同一時段被搶兩次單沖突檢查 SQL 怎么寫家政平臺最容易出現(xiàn)、也最容易被忽略的業(yè)務(wù) bug就是同一阿姨在同一時段被預(yù)約兩次。很多初版代碼的做法是下單時查一下當天有沒有訂單沒有就插入。這個邏輯在單用戶測試時沒問題但系統(tǒng)一開放給多人使用立刻就會翻車。正確做法是在插入訂單前做一次真正的時間重疊檢查SELECT COUNT(*) FROM appointment WHERE worker_id #{workerId} AND status IN (1, 2, 3) -- 待服務(wù)、服務(wù)中、待確認這些單占用了阿姨的時間 AND service_date #{serviceDate} AND slot_start #{slotEnd} -- 新時段開始時間 已有預(yù)約結(jié)束時間 AND slot_end #{slotStart}; -- 已有預(yù)約開始時間 新時段結(jié)束時間這個 SQL 的核心是后面兩個重疊條件。直觀理解新預(yù)約 [09:00, 10:00) 和已有預(yù)約 [09:30, 10:30) 是否沖突要看新開始時間是否早于已有結(jié)束時間并且已有開始時間是否早于新結(jié)束時間。兩個條件同時滿足說明兩個區(qū)間確實有交集。為什么要用這種寫法而不是“分別在開始和結(jié)束時刻各查一次”因為那兩種寫法都存在漏判。比如已有預(yù)約是 09:00 到 11:00新預(yù)約是 10:00 到 10:30只查開始時刻會認為 10:00 沒單但如果查結(jié)束時刻 10:30 落在別人區(qū)間里就能攔住。反向同理。用區(qū)間重疊判斷才是無死角的。status IN (1, 2, 3) 的過濾也很講究。待付款訂單還不確定是否成立不應(yīng)該占住阿姨的時間已取消和已完成的單更不用管。但這里有個隱藏問題如果用戶下單后一直不付款時間被別人搶走了怎么辦常見做法是加超時取消機制比如下單后 30 分鐘未支付自動把訂單置為已取消釋放時間占用。這個邏輯不用做成定時器用戶下單時查一下自己的待付款單是否超時順帶清理即可。4.3 支付回調(diào)的冪等處理唯一約束 樂觀鎖更新線上支付的回調(diào)接口是家政平臺另一個隱藏考點。哪怕只是模擬支付也應(yīng)該按真實支付回調(diào)的姿勢來寫支付平臺會多次通知結(jié)果你的接口必須保證“同一個訂單被回調(diào)一百次效果等同于一次”。Transactional public PayResult handlePayCallback(String orderNo, BigDecimal amount) { // 1. 冪等前置檢查查當前狀態(tài) Appointment appointment appointmentMapper.selectByOrderNo(orderNo); if (appointment null) { return PayResult.fail(訂單不存在); } // 2. 已經(jīng)處理過的回調(diào)直接返回成功不重復(fù)處理 if (appointment.getStatus() ! OrderStatus.PENDING_PAY.getCode()) { return PayResult.success(重復(fù)回調(diào)已處理); } // 3. 樂觀鎖更新只有狀態(tài)為待付款時才能變?yōu)榇?wù) int rows appointmentMapper.updateStatusByOrderNo(orderNo, OrderStatus.PENDING_PAY.getCode(), OrderStatus.PAID.getCode()); if (rows 1) { return PayResult.success(支付成功); } return PayResult.fail(狀態(tài)更新失敗請重試); }對應(yīng)的 MyBatis 更新語句只有一條UPDATE appointment SET status #{to}, update_time NOW() WHERE order_no #{orderNo} AND status #{from};這條 UPDATE 的關(guān)鍵在于 WHERE 條件里帶著舊狀態(tài)。兩個并發(fā)請求同時進來只有一個能匹配到 status 0 的記錄另一個影響行數(shù)為 0直接按“重復(fù)回調(diào)”處理。這就是樂觀鎖的思路——用一條帶條件的 UPDATE 替代“先查再改”避免競態(tài)。為什么說這個設(shè)計值得做因為幾乎所有家政平臺的簡歷項目里都會寫“對接了支付流程”面試官一聽支付接踵而來的就是三個問題怎么保證回調(diào)不重復(fù)處理、怎么處理金額校驗、怎么處理訂單狀態(tài)一致性。能用“order_no 唯一約束 條件更新”答清第一問就已經(jīng)超過很多只會在 controller 里寫 CRUD 的候選人了。5. 從源碼到能演示家政平臺 5 個常見部署踩坑與排查5.1 端口被占點啟動按鈕沒反應(yīng)日志尾部寫著 already in use現(xiàn)象IDEA 里點啟動控制臺打到一半就退出來最后一行通常是 Port 8080 was already in use。有時候連提示都不給只在日志里淺淺帶過。原因本機有別的 Java 進程或開發(fā)工具占了 8080。最常見的是你自己之前跑過另一個 Spring Boot 項目沒關(guān)掉或者是某個工具自帶的服務(wù)占了這個端口。解決先看誰占了端口。Windows 上執(zhí)行 netstat -ano | findstr 8080macOS/Linux 上執(zhí)行 lsof -i:8080找到 PID 后按需結(jié)束進程。如果那個進程不能殺就改項目的 server.port同時全局搜索前端頁面或 JS 里寫死的 localhost:8080把端口一起換掉。# Windows netstat -ano | findstr 8080 taskkill /PID 12345 /F # macOS / Linux lsof -i:8080 kill -9 12345這個坑看似簡單但我在協(xié)助別人跑類似項目時見過太多次“只改后端端口、忘記前端硬編碼”結(jié)果頁面打開了一堆接口 404。改端口務(wù)必把前端資源和頁面里的地址一次改齊。5.2 MySQL 8 連接失敗Public Key Retrieval is not allowed 與驅(qū)動版本現(xiàn)象項目啟動時報 Failed to configure a DataSource或者連接報 Public Key Retrieval is not allowed偶爾還有 ClassNotFoundException: com.mysql.jdbc.Driver。原因兩個疊加在一起。MySQL 8 默認的認證插件是 caching_sha2_password客戶端第一次連接需要向服務(wù)端請求公鑰同時 pom.xml 里的 MySQL 驅(qū)動版本太老不認識這個流程或者驅(qū)動類名寫的是 5.x 的舊名字。解決把依賴替換為 MySQL 8 對應(yīng)的驅(qū)動坐標mysql-connector-java 或 com.mysql:mysql-connector-jJDBC URL 里加上 allowPublicKeyRetrievaltrue 和 useSSLfalse驅(qū)動類名寫成 com.mysql.cj.jdbc.Driver。dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency這里的版本號不用手動寫死Spring Boot 2.x 的依賴管理會自動選一個匹配 8.x 的版本。如果項目用的是更早的 Spring Boot那就直接在 pom 里寫一個較新的 8.x 版本號讓 IDE 重新導(dǎo)入即可。5.3 SQL 文件導(dǎo)入中文亂碼記事本打開過就廢了一半現(xiàn)象導(dǎo)入 SQL 后表里的中文注釋全是亂碼或者包含中文的字段值插不進去報錯。原因最常見的是有人用 Windows 記事本打開過 .sql 文件再保存時被轉(zhuǎn)成了 ANSI 編碼。另一種是導(dǎo)入時客戶端連接的字符集和文件編碼不一致。解決先用 VS Code 或 Notepad 這類能識別編碼的編輯器重新保存為 UTF-8。導(dǎo)入時在 MySQL 命令行先執(zhí)行 SET NAMES utf8mb4再用 source 導(dǎo)入。命令行導(dǎo)入時可以顯式指定字符集mysql -uroot -p housekeeping --default-character-setutf8mb4 housekeeping.sql判斷文件編碼的小技巧看注釋里的中文是否正常。如果正?；究梢源_定編碼沒問題。如果文件頭是亂碼先轉(zhuǎn)碼再導(dǎo)入不要指望數(shù)據(jù)庫層面能兜住所有編碼問題。另外用 DBeaver 連接 MySQL 后如果表列表不顯示先檢查連接配置里選擇的 schema 是不是 housekeeping很多時候是默認連到了別的庫。5.4 登錄后立刻被踢回登錄頁Filter、Session、context-path 三連現(xiàn)象登錄頁能打開賬號密碼也正確但跳轉(zhuǎn)后馬上又回到登錄頁或者頁面樣式全丟、CSS 加載不出來。原因這類系統(tǒng)通常有一個登錄攔截 Filter 或攔截器判斷 Session 里有沒有用戶信息。常見問題有三個攔截器把所有請求都攔了包括 /css、/js、/images 這些靜態(tài)資源登錄成功后 Session 寫入的 key 和攔截器檢查的 key 不一致項目部署帶了 context-path頁面里的跳轉(zhuǎn)鏈接卻是寫死的根路徑。解決先看攔截器注冊時排除了哪些路徑。常見做法是放行登錄頁、注冊接口和所有靜態(tài)資源registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/**) .excludePathPatterns(/login, /register, /api/user/login, /css/**, /js/**, /images/**);如果靜態(tài)資源放行了還跳回登錄頁多半是登錄成功后 Session 沒寫對。登錄接口里寫入 session.setAttribute(loginUser, user)攔截器里也必須是同一個 key大小寫、下劃線都不能差。至于 context-path 問題最簡單的驗證方法就是改配置后全局搜一下源碼里有沒有寫死 /xxx/ 的跳轉(zhuǎn)統(tǒng)一改成相對路徑或從 request 里拿上下文路徑。5.5 并發(fā)下單導(dǎo)致重復(fù)預(yù)約事務(wù)隔離讓“先查后改”形同虛設(shè)現(xiàn)象兩個人幾乎同時提交同一個阿姨同一時段的預(yù)約數(shù)據(jù)庫里出現(xiàn)了兩條記錄而頁面提示都顯示預(yù)約成功。原因把 4.2 的沖突檢查 SQL 放在“查詢再插入”的普通邏輯里在高并發(fā)下會有競態(tài)。兩個請求都先執(zhí)行了 SELECT COUNT(*)都發(fā)現(xiàn)沒有預(yù)約然后都執(zhí)行 INSERT。MySQL 默認的隔離級別是 REPEATABLE READ兩個事務(wù)互相看不到對方未提交的插入于是各自認為“空閑”。解決根據(jù)項目進度二選一。最直接的是在檢查時分兩步把“檢查時間”變成“鎖住時間”在事務(wù)里對阿姨某天的某個時段加鎖SELECT id FROM appointment WHERE worker_id #{workerId} AND service_date #{serviceDate} AND slot_start #{slotStart} FOR UPDATE;如果查詢返回空說明沒人預(yù)約可以安全插入如果有人預(yù)約這條 SELECT 會等鎖插入操作自然被阻塞。另一種更徹底的方案是加唯一索引讓數(shù)據(jù)庫在物理層面拒絕重復(fù)ALTER TABLE appointment ADD UNIQUE KEY uk_worker_slot (worker_id, service_date, slot_start);唯一索引方案需要注意它要求用戶下單時就把這個時段“占住”也就是先插入一條 status0 的待付款單付款成功后再更新為待服務(wù)。這樣同一個阿姨的同一個開始時間只能存在一條訂單重復(fù)插入直接被數(shù)據(jù)庫拒絕。代價是待付款的超時釋放邏輯必須跟著做好。6. 把“高分項目”變成“自己的項目”答辯前驗收與改造6.1 跑通不等于能用四個功能閉環(huán)先驗一遍拿到項目后不要急著改代碼先把四個閉環(huán)走完走到每一步都符合預(yù)期為止。用戶側(cè)閉環(huán)注冊新賬號登錄瀏覽服務(wù)項目選一個阿姨和時間提交訂單模擬支付看到訂單狀態(tài)從待付款變成待服務(wù)服務(wù)完成后確認并評價。這一步能驗收 80% 的前后端聯(lián)通問題。服務(wù)側(cè)閉環(huán)用阿姨賬號登錄看到分配過來的訂單點擊開始服務(wù)再點擊完成服務(wù)。這里重點看狀態(tài)變化是否符合第四章的狀態(tài)機尤其是“服務(wù)中”能不能直接跳到“已完成”——能跳就說明代碼繞過了用戶確認屬于需要修的 bug。管理側(cè)閉環(huán)管理員賬號登錄新增一個服務(wù)項目修改價格把項目下架查看全部訂單按狀態(tài)篩選如果有派單功能把訂單指派給指定阿姨。數(shù)據(jù)側(cè)閉環(huán)檢查訂單表里的金額、狀態(tài)、時間字段沒有明顯異常評價表的 order_id 和訂單能對上服務(wù)項目的價格修改沒有影響到歷史訂單的金額。這一條檢驗的就是第三章說的冗余設(shè)計有沒有真正落地。6.2 性價比最高的三個改造一天內(nèi)可以完成第一把 4.2 的沖突檢查從普通查詢改成事務(wù) FOR UPDATE 或唯一索引。這是最值得做的改造因為它直接消滅一個邏輯 bug還能在簡歷上寫“通過數(shù)據(jù)庫約束解決服務(wù)時段超賣問題”。配合一段測試過程演示效果極好。第二加訂單狀態(tài)日志表。每張表的操作都記錄操作人、時間、舊狀態(tài)、新狀態(tài)和備注并在用戶端訂單詳情頁展示一條狀態(tài)時間線。這個功能不復(fù)雜卻是很多項目缺失的答辯時點開一看評委就知道你做的不只是增刪改查。第三把模擬支付接口改成“回調(diào)式”?，F(xiàn)在很多項目是用戶點一個“模擬支付”按鈕直接把訂單改成已付款這個流程拿不上臺面。改造思路生成訂單后調(diào)一個模擬支付頁點擊“確認支付”后請求層的 /api/pay/callback 接口回調(diào)里帶上訂單號和金額后端按第四章的方式做冪等處理。我做這類系統(tǒng)時吃過一次大虧演示當天現(xiàn)場兩個賬號同時下單同一個阿姨的九點到十一點時段被預(yù)約了兩次訂單列表里兩條單并排躺著氣氛非常尷尬。后來我把唯一索引和狀態(tài)機補齊才真正體會到——所謂高分項目拼的不是頁面多漂亮而是這些邊界條件有沒有被堵死。后來帶新人跑通類似項目時我都會讓他們先把訂單狀態(tài)機畫出來再動手寫代碼。這個教訓(xùn)直接讓我在之后做任何管理系統(tǒng)時都把“狀態(tài)流轉(zhuǎn)是否合法”當成第一優(yōu)先級的檢查項。希望這些步驟和坑能幫你把這個壓縮包變成一個真正敢在答辯時打開的系統(tǒng)。本文還有配套的精品資源點擊獲取