做酒店管理系統(tǒng)這件事我前后完整做過兩遍第一遍是剛入行時拿它練手第二遍是幫一個朋友的門店做內(nèi)部工具。兩次踩的坑完全不一樣——第一遍坑在代碼第二遍坑在業(yè)務。后來跟不少同行聊過發(fā)現(xiàn)大家對這個題目的認知普遍偏了覺得它就是個房間增刪改查 訂單增刪改查的入門項目網(wǎng)上模板一抓一大把照著抄一遍就能交差。真動手之后才發(fā)現(xiàn)房間是有時間維度的資源訂單是有生命周期的契約這兩樣東西一旦摻在一起CRUD 那套思路立刻就不夠用了。這篇內(nèi)容就把這套系統(tǒng)從業(yè)務動線、表結構切分、訂單狀態(tài)機、并發(fā)占房到權限攔截、部署交付完整地捋一遍重點放在那些模板代碼里永遠不會寫、但真正會把你卡住的地方。適合正在做課程設計、想拿它當面試項目、或者要給小門店做一套能真正用起來的系統(tǒng)的朋友參考Java 基礎和 Servlet 那套東西不用很精但至少要能看懂 SQL 和接口調(diào)用。1. 老題目為什么還值得用 JavaWeb 重做一遍1.1 它真正的難點不在增刪改查在時間段占用大多數(shù)管理類系統(tǒng)的核心是記錄存不存在學生表里有沒有這個學號、圖書表里這本書在不在館判斷條件都是一個個離散的字段。酒店系統(tǒng)不一樣它要回答的問題是這間房在 3 月 1 日到 3 月 3 日這段時間里有沒有被別人占著。這是一個典型的區(qū)間重疊判斷兩個訂單只要時間區(qū)間有交集就算沖突跟記錄本身是否存在沒有關系。舉個具體的例子。某位客人訂了 301 房入住日期 3 月 1 日離店日期 3 月 3 日。另一位客人想訂 301 房3 月 2 日入住、3 月 4 日離店。這兩條訂單在數(shù)據(jù)庫里完全是兩條獨立記錄主鍵不同、客人不同、訂單號不同任何常規(guī)的唯一約束都攔不住它們但它們確實是沖突的——3 月 2 日晚上那間房只能睡一個人。重疊判斷的標準寫法是startA endB AND startB endA注意這里是嚴格小于因為 3 月 3 日離店的客人當天中午就退房了同一天入住的客人下午才能進房首尾相接不算沖突。這個細節(jié)很多模板代碼都寫成了小于等于結果就是系統(tǒng)死活不讓人訂今天退房、今天入住的房間前臺天天抱怨。1.2 技術棧到底怎么選別被越新越好帶偏這個項目用什么框架做取決于你想從里面拿到什么。我把幾種常見組合的實際體感列出來你可以對照自己的目標挑。技術組合上手成本請求鏈路可見度出效果速度適合的目標Servlet JSP JDBC中極高能看到每一個請求參數(shù)怎么進來慢想徹底搞懂 JavaWeb 底層SSMSpring SpringMVC MyBatis較高配置繁多中中學校課程要求、面試講框架整合Spring Boot MyBatis Thymeleaf低低很多細節(jié)被自動配置藏起來了快快速交付、給門店真用Spring Boot Vue 前后端分離中高要寫兩套代碼低但邊界清晰中想順便練前端、做簡歷項目我的建議是如果你的目的是打基礎先用 Servlet JSP 把登錄、房態(tài)查詢、下單這三條鏈路手寫一遍感受一下 HttpServletRequest 里取參數(shù)、Session 里存用戶、JSP 里循環(huán)渲染列表這套原始流程寫完之后再換 Spring Boot你會對框架到底幫你做了什么有非常清晰的認知。反過來如果目標是盡快做出一個能演示、能給門店試用的東西直接 Spring Boot別在 XML 配置上浪費生命。有一點要提醒網(wǎng)上流傳的很多酒店管理系統(tǒng)源碼用的是十年前的 JSP 內(nèi)嵌 Java 代碼寫法% %里塞滿了業(yè)務邏輯這種代碼能跑但沒法維護也不適合當自己的作品展示。哪怕用 JSP也請把業(yè)務邏輯放到 Service 層頁面只負責渲染。1.3 一個能演示和能用的系統(tǒng)差在哪些模塊先把模塊清單拉出來心里有個全景圖后面的表結構和接口才好安排?；A數(shù)據(jù)房型管理大床房、標間、套房、房間管理物理房號、所屬房型、樓層、價格策略基礎價、周末價、節(jié)假日價預訂散客預訂、團隊預訂、預訂查詢、取消預訂、超時未到自動釋放前臺作業(yè)排房、辦理入住、換房、續(xù)住、退房、掛賬賬務押金收取、消費入賬、結賬、發(fā)票信息記錄會員會員等級、積分、協(xié)議價報表出租率、平均房價、營收日報系統(tǒng)管理用戶、角色、權限、操作日志能演示的系統(tǒng)通常只做前四個模塊的 CRUD能用的系統(tǒng)必須在換房續(xù)住拆賬超時釋放這些邊緣動作上有完整處理。這四個動作恰恰是最容易被忽略、也最容易在真實場景里出問題的部分后面會專門講。2. 先把前臺的動線走一遍業(yè)務模型比技術棧更先決定成敗2.1 一天里前臺到底會點哪些按鈕我在動手寫第一行代碼之前專門在一個門店的前臺后面站了大半天把他們的操作記錄下來。這份記錄比任何需求文檔都有用。早上八點接班第一件事是打開房態(tài)圖看昨天夜審之后的在住房間、今日預抵、今日預離。有客人到店先問姓名或訂單號查到預訂單核對證件選房系統(tǒng)推薦空閑房收押金點辦理入住房間狀態(tài)從已預訂變成在住。中午陸續(xù)有人退房點退房系統(tǒng)算出房費加消費減押金多退少補房間狀態(tài)變成待打掃?？头堪⒁檀驋咄暝谙到y(tǒng)里點已清潔房間才回到空閑可售。下午有客人打電話來問今晚還有沒有房前臺要能快速看到每種房型剩余幾間。晚上可能有客人要換房從 301 換到 508房價不一樣還得補差價。把這條動線畫清楚之后你會發(fā)現(xiàn)系統(tǒng)的核心不是房間表和訂單表兩張表而是房態(tài)這個每天都在變的東西以及房態(tài)變化的觸發(fā)點。任何一個操作沒把房態(tài)改對第二天前臺就得靠人工記憶干活。2.2 房態(tài)不是空閑/占用兩個值新手最容易犯的錯是把房態(tài)設計成布爾值。真實場景里至少需要這幾個狀態(tài)VACANT空閑可售BOOKED已被預訂未到店OCCUPIED在住DIRTY待打掃客人已退房房間還沒清理CLEANING清潔中MAINTENANCE維修停用LOCKED鎖房內(nèi)部留房、長包房預留待打掃這個狀態(tài)是分水嶺。有它系統(tǒng)才算摸到了酒店業(yè)務的邊沒它退房之后房間立刻變空閑可售前臺把剛退的房間賣出去客人進門看見床單還沒換投訴就來了。房態(tài)和訂單狀態(tài)是兩套東西千萬別合并成一張表的同一個字段。訂單狀態(tài)描述的是這筆交易走到哪一步了房態(tài)描述的是這個物理空間現(xiàn)在能不能賣。一筆訂單可以對應多次房態(tài)變化預訂→在住→待打掃一個房態(tài)也可能被多筆訂單先后占用。混在一起的后果是你取消一筆訂單的時候不知道該不該把房間置為空閑——萬一那間房同時還被另一筆訂單占著呢。2.3 房型和房間必須拆成兩張表房型是賣的品類房間是具體的庫存單位。大床房是房型301 是房間。價格、床型、面積、可住人數(shù)這些屬性掛在房型上房間只保留房號、樓層、所屬房型和當前房態(tài)。拆開的好處很直接調(diào)價的時候只改房型一行不用去改幾十個房間統(tǒng)計出租率的時候按房型聚合不用自己拼字符串換房的時候只改訂單關聯(lián)的房間 ID房型信息自動跟著變。不拆的后果我在一個項目里真切見過——房型信息直接抄在房間表里同一個房型的可住人數(shù)在 20 個房間記錄里填了 3 種不同的值后來做超員校驗的時候根本沒法統(tǒng)一。3. 數(shù)據(jù)表的三條邊界房間、訂單、入住記錄怎么切3.1 核心表清單與建表要點下面是我實際用的一套精簡版結構字段做過刪減保留了骨架。數(shù)據(jù)庫用 MySQL 8。-- 房型 CREATE TABLE room_type ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, -- 大床房 / 標間 / 套房 base_price DECIMAL(10,2) NOT NULL, -- 基礎價元/晚 bed_type VARCHAR(20), -- 床型 max_occupancy TINYINT NOT NULL DEFAULT 2, -- 最大可住人數(shù) area DECIMAL(6,2), status TINYINT NOT NULL DEFAULT 1 -- 1 啟用 0 停用 ); -- 房間 CREATE TABLE room ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_no VARCHAR(20) NOT NULL, room_type_id BIGINT NOT NULL, floor_no INT, room_status VARCHAR(20) NOT NULL DEFAULT VACANT, remark VARCHAR(200), UNIQUE KEY uk_room_no (room_no), KEY idx_type_status (room_type_id, room_status) ); -- 訂單預訂主表 CREATE TABLE booking_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, guest_name VARCHAR(50) NOT NULL, guest_phone VARCHAR(20) NOT NULL, room_type_id BIGINT NOT NULL, room_id BIGINT, -- 排房后回填 check_in_date DATE NOT NULL, check_out_date DATE NOT NULL, room_count INT NOT NULL DEFAULT 1, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0, deposit DECIMAL(10,2) NOT NULL DEFAULT 0, order_status VARCHAR(20) NOT NULL, source VARCHAR(20), -- 門店/電話/線上 created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_dates (check_in_date, check_out_date), KEY idx_status (order_status) ) ENGINEInnoDB;3.2 訂單和入住記錄為什么要拆開訂單是契約入住記錄是事實。一位客人可能先訂 3 晚住到第二晚說要換房第三晚換到另一間也可能訂 2 晚實際住了 4 晚需要續(xù)住。如果只有訂單表這些變化只能靠改訂單字段實現(xiàn)改完之后歷史軌跡全丟了出了糾紛沒法查。拆開之后booking_order保存預訂層面的信息誰訂的、訂幾晚、總價多少、訂單狀態(tài)check_in_record保存實際入住的事實實際哪天進的、住哪間房、哪天退的、實際房費。一張訂單對應一到多條入住記錄換一次房就多一條。拆表還有一個隱性好處結賬邏輯變清楚了。賬單掛在實際的入住記錄上而不是掛在訂單上拆賬、掛賬、補開發(fā)票都有一個明確的載體。3.3 時間字段怎么存這是最容易埋雷的地方房費是按夜算的不是按小時。所以入住日期和離店日期必須是DATE類型不能是DATETIME。一旦用了DATETIME你會在計算間夜數(shù)的時候遇到無窮無盡的問題客人 3 月 1 日 14:30 入住、3 月 3 日 11:00 退房按差值算是 1.85 天房間到底算幾晚標準做法是日期歸日期實際進出時間單獨記。訂單表用DATE入住記錄里用DATETIME記實際時間。間夜數(shù)算起來就一行l(wèi)ong nights ChronoUnit.DAYS.between(checkInDate, checkOutDate); if (nights 0) { throw new BizException(離店日期必須晚于入住日期); }3 月 1 日到 3 月 3 日between返回 2兩晚符合常識。還有一個坑是凌晨入住?？腿?3 月 2 日凌晨 2 點來開房他心里的今天是 3 月 1 日那一天的延續(xù)行業(yè)里通常把凌晨 6 點前的入住算到前一個營業(yè)日。如果你的系統(tǒng)直接取服務器當前日期夜審就會出錯報表也會錯位。解決辦法是引入營業(yè)日business date的概念用一個配置項存當天營業(yè)日每天凌晨固定時間比如 4 點跑一次夜審任務把它推進一天所有今天的判斷都用營業(yè)日不用LocalDate.now()。3.4 索引建在哪以及一個約束解決不了的問題上面建表語句里booking_order上建了(check_in_date, check_out_date)的聯(lián)合索引因為查某段時間內(nèi)的訂單是最高頻的查詢。room表上建了(room_type_id, room_status)因為房態(tài)圖要按房型聚合。很多人第一反應是給訂單表加一個唯一約束來防重復預訂比如把room_id check_in_date check_out_date設成唯一鍵。這個想法是錯的而且錯得很隱蔽。唯一約束只能保證完全相同的組合不重復但(301, 3-01, 3-03)和(301, 3-02, 3-04)是兩個不同的組合唯一約束完全放行。時間區(qū)間重疊這件事關系型數(shù)據(jù)庫的唯一索引管不了。真正能解決問題的方案后面第 5 章會詳細講。4. 訂單狀態(tài)機從預訂到退房這條鏈路怎么用代碼鎖死4.1 狀態(tài)定義與合法遷移訂單狀態(tài)不能隨便改必須有一個明確的遷移圖。我用的這套定義經(jīng)過兩次項目驗證基本夠用狀態(tài)含義可以遷往PENDING_PAY待支付線上預訂BOOKED、CANCELLEDBOOKED已確認預訂CHECKED_IN、CANCELLED、NO_SHOWCHECKED_IN已入住CHECKED_OUTCHECKED_OUT已退房終態(tài)CANCELLED已取消終態(tài)NO_SHOW未到店終態(tài)終態(tài)的意思是不能再改回去。很多系統(tǒng)允許取消的訂單重新激活看起來方便實際上把庫存計算攪得一團糟因為取消的時候已經(jīng)釋放過房間了重新激活要不要再占一次建議直接禁止需要的話讓前臺重新下一單。4.2 用枚舉把非法遷移擋在入口不寫校驗的代碼長這樣order.setOrderStatus(CHECKED_OUT)任何人都能把任何訂單改成任何狀態(tài)。這種代碼在演示時看不出問題上線一周就會冒出已退房的訂單又被改成在住的臟數(shù)據(jù)。我用一個枚舉把這些規(guī)則固化下來public enum OrderStatus { PENDING_PAY, BOOKED, CHECKED_IN, CHECKED_OUT, CANCELLED, NO_SHOW; private static final MapOrderStatus, SetOrderStatus TRANSITIONS new HashMap(); static { TRANSITIONS.put(PENDING_PAY, EnumSet.of(BOOKED, CANCELLED)); TRANSITIONS.put(BOOKED, EnumSet.of(CHECKED_IN, CANCELLED, NO_SHOW)); TRANSITIONS.put(CHECKED_IN, EnumSet.of(CHECKED_OUT)); TRANSITIONS.put(CHECKED_OUT, EnumSet.noneOf(OrderStatus.class)); TRANSITIONS.put(CANCELLED, EnumSet.noneOf(OrderStatus.class)); TRANSITIONS.put(NO_SHOW, EnumSet.noneOf(OrderStatus.class)); } public boolean canTransitTo(OrderStatus target) { return TRANSITIONS.getOrDefault(this, Collections.emptySet()).contains(target); } }Service 層統(tǒng)一走一個入口方法任何狀態(tài)變更都必須經(jīng)過它順手把操作日志也記了Transactional(rollbackFor Exception.class) public void changeStatus(Long orderId, OrderStatus target, String operator) { BookingOrder order orderMapper.selectById(orderId); if (order null) { throw new BizException(訂單不存在); } OrderStatus current OrderStatus.valueOf(order.getOrderStatus()); if (!current.canTransitTo(target)) { throw new BizException(訂單當前狀態(tài) current 不能變更為 target); } // 狀態(tài)變更時必須同步處理的副作用 if (target OrderStatus.CHECKED_IN) { occupyRoom(order); } else if (target OrderStatus.CANCELLED || target OrderStatus.NO_SHOW) { releaseRoom(order); } else if (target OrderStatus.CHECKED_OUT) { markRoomDirty(order.getRoomId()); } order.setOrderStatus(target.name()); orderMapper.updateById(order); opLogService.record(orderId, current.name(), target.name(), operator); }Transactional加在這里不是裝飾。狀態(tài)改了但房間沒釋放或者房間釋放了但狀態(tài)沒改都是要人命的臟數(shù)據(jù)必須放在同一個事務里。4.3 狀態(tài)遷移和房態(tài)聯(lián)動事務邊界要劃清楚事務邊界劃多寬是個需要想清楚的問題。我最初的寫法是把整個入住流程包在一個事務里改狀態(tài)、改房態(tài)、寫入住記錄、記日志。測的時候沒問題壓測的時候發(fā)現(xiàn)鎖等待時間很長因為事務里還夾了一個調(diào)用外部接口的動作發(fā)短信通知這個網(wǎng)絡調(diào)用慢的時候整個事務就卡著不放。后來拆成了兩層核心數(shù)據(jù)變更放在事務里通知類的動作放到事務提交之后用TransactionSynchronizationManager.registerSynchronization或者 Spring 的事件機制來做。這個經(jīng)驗在任何業(yè)務系統(tǒng)里都通用——事務里不要做網(wǎng)絡調(diào)用。4.4 那些和日期相關的邊緣情況跨月、跨年、閏年的日期計算用LocalDate和ChronoUnit基本不會出錯但有幾個業(yè)務上的坑需要提前處理。一是同一天入住同一天離店。有的客人凌晨入住、當天上午就走按間夜算是 0 晚。系統(tǒng)里應該直接拒絕或者強制按 1 晚計費不能讓 0 元的訂單進數(shù)據(jù)庫。二是超時未到自動釋放。預訂單默認保留到入住當天的某個時間點行業(yè)慣例是 18:00 或 20:00超過這個時間沒到店就要自動轉NO_SHOW并釋放房間。這個必須用定時任務做不能靠前臺手動。定時任務的執(zhí)行時間要考慮時區(qū)服務器如果是 UTC 時間你寫cron 0 0 18 * * ?實際跑的是北京時間凌晨 2 點。三是續(xù)住。客人在住期間說要再住一晚這時候房間后面可能已經(jīng)被別人訂了。正確的做法是先查該房間在原離店日到新離店日之間有沒有其他訂單有就拒絕或者建議換房沒有才允許延長同時要同步占用新的一晚。這個邏輯如果用第 5 章的日期占位表來做就是簡單地再插一行非常干凈。5. 同一間房被兩個人同時下單并發(fā)超賣的排查與解決5.1 現(xiàn)象長什么樣這個 bug 我在兩個項目里都復現(xiàn)過表現(xiàn)一模一樣兩個人同時打開房態(tài)頁面都看到 301 空閑同時點擊下單兩個請求都返回成功數(shù)據(jù)庫里出現(xiàn)兩條互相沖突的訂單。單獨測永遠測不出來一上真實環(huán)境就偶發(fā)。第一次遇到的時候我盯著代碼看了兩個小時沒找出來因為每一條 SQL 單獨執(zhí)行都是對的。后來在 Service 方法入口和出口各打了一行帶毫秒時間戳的日志把兩個并發(fā)請求的日志交錯著看才發(fā)現(xiàn)問題出在先查后插這個動作中間。5.2 完整排查鏈路別跳過任何一步遇到這類問題我現(xiàn)在的排查順序是這樣的一步都不跳第一步確認是不是真的并發(fā)。先看兩條沖突訂單的created_at如果相差幾毫秒基本可以確認為并發(fā)相差幾分鐘那就是業(yè)務邏輯本身漏了校驗。我第一次犯的錯就是漏看了創(chuàng)建時間以為是業(yè)務校驗沒寫改了半天校驗邏輯問題依舊。第二步確認代碼的查詢條件和插入條件用的是不是同一套。有的代碼查詢時按入住日期 離店日期 AND 離店日期 入住日期判斷沖突插入時卻忘了考慮房間數(shù)大于 1 的訂單條件不對等天然就有縫隙。第三步看事務隔離級別。MySQL 默認是REPEATABLE READ普通SELECT是快照讀不加鎖。也就是說 A 事務查的時候看不到 B 事務還沒提交的插入B 事務也看不到 A 的兩個都認為房間是空的。第四步定位間隙在哪。把SELECT和INSERT之間的時間窗口量出來只要這個窗口大于 0就存在競態(tài)。5.3 三種解法以及我為什么最終選了第三種方案做法優(yōu)點缺點悲觀鎖SELECT ... FOR UPDATE鎖住房間行實現(xiàn)簡單絕對安全粒度粗一間房一個事務排隊高峰期鎖等待明顯樂觀鎖房間表加 version 字段更新時校驗無鎖等待吞吐高只適合改同一行的場景管不了區(qū)間重疊日期占位表一間房一晚一行唯一索引兜底語義清晰天然防重查詢快需要額外維護一張表悲觀鎖的問題在于粒度。你要鎖的其實是301 房在 3 月 1 日到 3 月 3 日這一段SELECT ... FOR UPDATE只能鎖住整個 301 房這一行結果就是 3 月 10 日的訂單也要排隊等 3 月 1 日的訂單處理完。低峰期無所謂高峰期前臺會明顯感覺到卡。樂觀鎖更不對路因為兩筆沖突的訂單操作的根本不是同一行數(shù)據(jù)一條是新增一條也是新增沒有版本號沖突這回事。日期占位表是我最終采用的方案思路是把房間 日期這個最小占用單位顯式存成一行CREATE TABLE room_date_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL, biz_date DATE NOT NULL, order_id BIGINT NOT NULL, UNIQUE KEY uk_room_date (room_id, biz_date), KEY idx_order (order_id) ) ENGINEInnoDB;預訂 301 房 3 月 1 日入住、3 月 3 日離店就是插入兩行(301, 2024-03-01)和(301, 2024-03-02)。注意離店日那天不占因為客人中午就走了。這兩個行插入時如果別人已經(jīng)占過其中任意一天唯一索引uk_room_date立刻拋DuplicateKeyException事務回滾第二個人收到該房型已訂滿的提示。這個方案最舒服的地方在于它把區(qū)間重疊這個抽象問題轉化成了主鍵沖突這個數(shù)據(jù)庫最擅長的問題。不需要寫復雜的重疊查詢不需要加鎖不需要擔心隔離級別數(shù)據(jù)庫的唯一索引天然就是并發(fā)安全的。代碼層面的封裝也不復雜Transactional(rollbackFor Exception.class) public Long createOrder(OrderCreateDTO dto) { // 1. 先查出可用房間這個查詢只是給用戶看不作為最終依據(jù) ListLong candidateRoomIds roomMapper.findAvailableRooms( dto.getRoomTypeId(), dto.getCheckInDate(), dto.getCheckOutDate(), dto.getRoomCount()); if (candidateRoomIds.isEmpty()) { throw new BizException(所選日期已無可用房間); } // 2. 逐個嘗試占位占不上就換下一間 Long lockedRoomId null; for (Long roomId : candidateRoomIds) { try { occupyAllNights(roomId, dto.getCheckInDate(), dto.getCheckOutDate()); lockedRoomId roomId; break; } catch (DuplicateKeyException e) { // 這間被別人搶了繼續(xù)試下一間 } } if (lockedRoomId null) { throw new BizException(房間剛剛被訂完請刷新后重試); } // 3. 落訂單 return saveOrder(dto, lockedRoomId); } private void occupyAllNights(Long roomId, LocalDate in, LocalDate out) { LocalDate cursor in; while (cursor.isBefore(out)) { roomDateStockMapper.insert(roomId, cursor, currentOrderId); cursor cursor.plusDays(1); } }有一個坑必須提前說Spring 的聲明式事務默認只對RuntimeException回滾DuplicateKeyException是DataAccessException的子類屬于RuntimeException會正?；貪L這點沒問題。但如果你在循環(huán)里catch了這個異常Spring 就認為你處理過了不會把事務標記為回滾前面插入的部分行可能殘留。所以catch之后要么手動TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()要么把每次占位拆成獨立的小事務REQUIRES_NEW。我用的是后者雖然多幾個連接但邏輯最干凈。5.4 取消、退房、換房時的占位釋放占位表建起來容易維護起來需要細心。取消訂單的時候必須按order_id把對應的占位行全刪掉一行都不能留否則那幾天就永遠賣不出去了。換房的時候要先占新的、再放舊的順序反了會出現(xiàn)在極短的時間窗口內(nèi)兩邊都沒占住的情況雖然概率極低但真出問題就是兩筆訂單搶同一間房。退房的時候占位行不能馬上刪因為客人提前退房比如訂了 3 晚住 1 晚就走第三晚的房間是空出來的理論上可以再賣。這時候刪掉剩余的占位行是合理的但要處理好退款——客人沒住的那晚要不要退錢、退多少屬于業(yè)務策略系統(tǒng)至少要留個記錄。每天夜審的時候順便跑一個清理任務把biz_date小于昨天的占位行歸檔到歷史表主表只留未來和當天的數(shù)據(jù)查詢速度會一直保持在很高的水平。6. 登錄會話與角色權限前臺、收銀、店長看到的界面不該一樣6.1 角色怎么劃別一上來就搞復雜權限設計最容易過度工程化。RBAC 那套用戶-角色-權限-資源-菜單五張表的模型很標準但放到一個門店內(nèi)部使用的小系統(tǒng)上純屬浪費。我實際用的是三個層級角色固定三到五個前臺、收銀、客房、店長、管理員權限點用字符串枚舉比如order:create、order:cancel、room:status:update、report:view角色和權限點的對應關系寫死在代碼或者配置表里不做動態(tài)配置界面。門店規(guī)模小角色幾乎不會變動態(tài)配置能力的收益遠遠抵不上維護成本。有一個業(yè)務上的權限細節(jié)值得單獨提收銀不能改房價店長可以。這不是技術潔癖是真實的風控需求。折扣權限必須有一個明確的審批鏈條否則前臺私下給客人打折的空間太大。系統(tǒng)里對應的做法是改價接口單獨鑒權并且在操作日志里記錄原價、新價、操作人、時間事后能查。6.2 Session 還是 Token小系統(tǒng)別糾結傳統(tǒng) JavaWeb 用HttpSession存登錄用戶簡單直接取當前用戶就是request.getSession().getAttribute(loginUser)。問題出在兩處一是服務端重啟 Session 就沒了前臺得重新登錄二是如果以后要部署兩臺機器做負載均衡Session 不共享用戶會在兩臺機器之間反復掉線。解決辦法也不復雜單機部署的話把 Session 超時時間調(diào)到 8 小時server.servlet.session.timeout8h跟前臺一個班次對齊重啟丟 Session 的問題可以通過持久化 Session 或者直接接受讓前臺重登一次來解決。真要做多機再引入 Redis 存 Session。Token 方案JWT的好處是無狀態(tài)壞處是沒法主動踢人下線用戶權限變了也得等 token 過期才生效。對一個門店內(nèi)部系統(tǒng)來說能隨時踢掉離職員工的登錄狀態(tài)比無狀態(tài)重要得多所以我傾向于 Session。6.3 攔截器怎么寫得既安全又不啰嗦登錄校驗和權限校驗應該分成兩層。第一層是登錄攔截器沒登錄的一律跳登錄頁第二層是權限攔截器已登錄但沒權限的返回 403。權限映射我寫在配置文件里比在方法上加注解更直觀一眼能看全auth: rules: - pattern: /order/** roles: [FRONT_DESK, MANAGER] - pattern: /report/** roles: [MANAGER] - pattern: /room/status roles: [FRONT_DESK, HOUSEKEEPING, MANAGER] - pattern: /admin/** roles: [ADMIN]攔截器里按順序匹配命中第一條就判斷匹配不到默認放行靜態(tài)資源、登錄頁這些。這里要注意寫匹配順序/order/**這種通配規(guī)則如果放在具體規(guī)則前面會把后面更細的規(guī)則全蓋住。6.4 越權比未登錄更危險的那類問題登錄攔截器擋得住沒登錄的人擋不住登錄了但不是這條數(shù)據(jù)主人的人。我在給別人做代碼 Review 的時候這類問題出現(xiàn)頻率最高。典型場景前臺 A 打開訂單詳情頁URL 是/order/detail?id1001他手動把 id 改成 1002看到了另一筆訂單的客人身份證號和手機號。這不是權限配置的漏洞是數(shù)據(jù)歸屬校驗的缺失。修復方式有兩種。一種是每次查詢都帶上歸屬條件比如WHERE id ? AND (creator_id ? OR branch_id ?)另一種是在 Service 層拿到記錄后顯式判斷當前用戶有沒有這行數(shù)據(jù)的訪問權。前者性能好后者邏輯更集中。小店內(nèi)部系統(tǒng)用后者就夠了好維護。還有一類是狀態(tài)越權客人已經(jīng)退房了按理說訂單不能再取消但代碼里只判斷了有沒有權限取消沒判斷當前狀態(tài)能不能取消。這個用第 4 章的狀態(tài)機就能攔住前提是所有變更入口都統(tǒng)一走changeStatus不能有繞過它的野路子。7. 部署交付一個能演示的系統(tǒng)和一個能用的系統(tǒng)差在哪7.1 數(shù)據(jù)庫初始化腳本要當成正經(jīng)產(chǎn)物維護我見過太多項目把建表語句散落在各個 .sql 文件里有的叫test.sql有的叫新建文本文檔.sql交付的時候找半天。正確的做法是維護一份按順序編號的腳本db/ V1__schema.sql 建表 V2__init_data.sql 初始數(shù)據(jù)房型、房間、默認管理員 V3__index.sql 補充索引初始管理員賬號的密碼要存加密后的值BCrypt 或者至少 MD5 加鹽不能明文。這個細節(jié)在答辯或者演示的時候經(jīng)常被問到。演示數(shù)據(jù)也要認真準備。一個空空如也的系統(tǒng)沒法演示至少要塞進去三五個房型、二十來間房、幾條不同狀態(tài)的訂單覆蓋今天預抵今天預離在住已取消這幾種情況房態(tài)圖看起來才像那么回事。7.2 打包和啟動時最常見的幾個報錯用 Spring Boot 的話mvn clean package之后直接java -jar坑通常在文件編碼和時區(qū)上。用 Servlet Tomcat 的老項目坑會多一些現(xiàn)象大概率原因處理方式中文亂碼請求編碼沒設或者 JSP 頁面沒寫pageEncoding加CharacterEncodingFilterJSP 頭寫% page contentTypetext/html;charsetUTF-8 %數(shù)據(jù)庫連接池啟動就滿連接沒關或者配置文件里 maxActive 寫太大用 try-with-resources檢查連接歸還時間差 8 小時服務器 JVM 時區(qū)是 UTC啟動參數(shù)加-Duser.timezoneAsia/ShanghaiMySQL 連接串加serverTimezoneAsia/Shanghai頁面 404 但接口能通視圖解析器前綴后綴配錯或者靜態(tài)資源被攔截器攔了檢查spring.mvc.view.prefix攔截器排除/static/**部署后上傳的圖片丟失文件存到了項目目錄里重新部署被覆蓋上傳目錄配成絕對路徑放到項目外時區(qū)那個問題特別隱蔽因為它在開發(fā)機上不出現(xiàn)本機時區(qū)通常是正確的一上服務器就冒出來而且表現(xiàn)是日期整體偏移一天很容易被誤判成日期計算寫錯了。7.3 交付時一定要寫清楚的那幾頁紙技術上的東西都在代碼里運營上的東西只能靠文檔。我最少會準備這幾份一份是操作手冊按角色寫。前臺看的是怎么排房、怎么辦入住、怎么換房店長看的是怎么看報表、怎么改房價。不要寫成一個通用手冊沒人看。一份是房態(tài)圖例說明把每種顏色的含義、每種狀態(tài)怎么流轉畫成一張表貼在墻上。前臺流動性大新人來了照著圖就能上手。一份是常見問題清單比如客人提前退房怎么處理押金多收了怎么退訂單下錯了能不能改。這些問題我是在試運行第一周從門店微信群里攢下來的比任何需求文檔都真實。7.4 上線之后必然會遇到的三個需求第一個是導報表。不管你把報表做得多漂亮店長最后一定會要 Excel。提前把導出接口寫好用 EasyExcel 之類的庫別自己拼 CSV 拼出亂碼。第二個是打印。入住登記單、押金單、賬單都要打。瀏覽器直接window.print()打出來的格式通常很難看要做固定的打印模板把紙張尺寸常見是小票 80mm 或者 A5定死。第三個是手機端。老板一定會在手機上問今天住了幾間。與其做一個完整的移動端不如做一個只讀的看板頁面兩三個數(shù)字手機打開就能看成本極低但滿意度極高。我自己的體會是這套系統(tǒng)真正的價值不在于用了什么框架而在于你有沒有把房態(tài)和訂單狀態(tài)這兩條線徹底分開、有沒有用日期占位把并發(fā)問題從根上摁住、有沒有在交付的時候多花半天把操作手冊寫清楚。前兩件事決定了系統(tǒng)會不會出臟數(shù)據(jù)第三件事決定了門店愿不愿意繼續(xù)用。我第二次做的時候代碼量比第一次還少一些但因為這幾處想明白了試運行兩周只改過三個小問題跟第一次每天被追著改完全不是一個體驗。