簡介「游泳館管理系統(tǒng)」是一套面向高校計算機與數(shù)據(jù)庫課程設(shè)計的Java項目源碼適合正在完成課程作業(yè)、練習企業(yè)級應(yīng)用開發(fā)的學生參考。系統(tǒng)圍繞會員信息、在線預約、泳道與更衣室等場地調(diào)度、收費記賬及財務(wù)報表展開包含會員等級、預約沖突處理、場地狀態(tài)維護等業(yè)務(wù)點并配有基于ER模型的數(shù)據(jù)庫設(shè)計可幫助理解實體關(guān)系、數(shù)據(jù)一致性與界面實現(xiàn)思路。壓縮包共1286個文件、約3.81MB主要由htm頁面、class字節(jié)碼與java源碼構(gòu)成另含jar、sql及mdf/ldf數(shù)據(jù)庫文件覆蓋前端頁面、程序代碼與建庫腳本。已有1536人學習讀者可借助源碼梳理會員、預約、場地與收費模塊的調(diào)用關(guān)系對照SQL與MDF/LDF文件理解建庫過程并補全需求分析、系統(tǒng)設(shè)計與測試文檔積累Java數(shù)據(jù)庫項目經(jīng)驗。1. 一套跑在瀏覽器里的泳池前臺游泳館管理系統(tǒng)的真實邊界上個月有個做場館運營的朋友拿著 Excel 來找我說暑假一天賣三百多張票晚上對賬對了兩個小時最后還漏了三張次卡沒扣。這種場景下一個用 Java 寫的游泳館管理系統(tǒng)干的事其實很樸素把會員、票卡、場次、泳道、入場核銷和日結(jié)報表收進一個后臺前臺掃碼放行后臺自動記賬中間不靠人手抄。它適合兩類人一類是做課程設(shè)計、想找一個業(yè)務(wù)閉環(huán)完整、表結(jié)構(gòu)不至于太寒酸的 Java 項目另一類是小型場館想拿一份能跑起來的底子改成自己的。邊界也得先說清它不做硬件閘機直連不接真實支付渠道核銷和記賬是核心報表是加分項剩下的靠二次開發(fā)補。2. 技術(shù)棧與工程骨架Spring Boot 分層怎么落到目錄上2.1 技術(shù)選型這套組合為什么成了默認答案這個項目的技術(shù)組合基本是 Java 生態(tài)里做中小型管理系統(tǒng)的標準配置Spring Boot 做容器和自動裝配MyBatis-Plus 做持久層MySQL 8 存業(yè)務(wù)數(shù)據(jù)Redis 可選用來放登錄 token 和場次余量緩存前端可以是 Vue2 Element UI 的前后端分離也可以是 Thymeleaf 服務(wù)端渲染。選 Spring Boot 的理由很直接一個main方法就能把 Tomcat、數(shù)據(jù)源、事務(wù)管理器全帶起來不用再去寫一堆 XML。選 MyBatis-Plus 而不是 JPA 的理由更實際場館類系統(tǒng)的報表 SQL 特別多日結(jié)、月結(jié)、按場次統(tǒng)計人次這些用 JPA 的 Criteria 寫出來又長又難調(diào)而 MyBatis-Plus 保留了手寫 SQL 的自由同時把單表 CRUD 用BaseMapper省掉了。代碼生成器跑一遍entity、mapper、service、controller 四層骨架就出來了對課設(shè)這種時間緊的場景幾乎是救命稻草。前端走分離還是走模板取決于你要不要給閘機側(cè)留接口。分離方案里后臺管理頁面和前臺核銷頁面共用一套axios封裝接口層用 JWT 做無狀態(tài)鑒權(quán)攔截器里解析 token 塞進ThreadLocalService 層隨時能拿到當前操作人。模板方案省一個工程但核銷頁要單獨做移動端適配時會很難受我一般還是傾向分離。權(quán)限這塊項目里通常是sys_user、sys_role、sys_menu、sys_user_role、sys_role_menu五張表登錄后查出菜單樹渲染側(cè)邊欄接口層用自定義注解RequirePerm(member:add)配合 AOP 做校驗。不要一上來就上 Spring Security 全套配置量會吃掉你一半的調(diào)試時間用一個 HandlerInterceptor 加注解足夠撐住這個體量。2.2 目錄結(jié)構(gòu)一個包一層看過去單模塊工程是這個項目最常見的形態(tài)分包按職責切不按業(yè)務(wù)切?？粗鴺闼氐钠饋碚业玫降胤?。swim-center ├── pom.xml ├── sql/ │ ├── schema.sql # 建表語句 │ └── data.sql # 字典、菜單、管理員初始數(shù)據(jù) └── src/main/ ├── resources/ │ ├── application.yml │ ├── application-dev.yml │ └── mapper/ # MyBatis XML復雜 SQL 放這里 └── java/com/example/swim/ ├── SwimApplication.java ├── common/ # Result、BizException、全局異常處理 ├── config/ # MybatisPlus、Jackson、WebMvc、跨域 ├── controller/ # 只做參數(shù)接收和結(jié)果包裝 ├── service/ │ └── impl/ # 業(yè)務(wù)邏輯和事務(wù)邊界都在這一層 ├── mapper/ # 繼承 BaseMapper 的接口 ├── entity/ # 和表一一對應(yīng) ├── dto/ # 入?yún)ο髱ｒ炞⒔?├── vo/ # 出參對象拼裝展示字段 ├── task/ # 定時任務(wù)場次關(guān)閉、卡過期 └── util/ # 訂單號、二維碼、導出工具dto和vo分開這件事很多課設(shè)項目會偷懶合并成 entity 直接用結(jié)果是前端一傳參就能改balance字段。分開之后MemberCardDTO里根本不出現(xiàn)余額字段越權(quán)修改從入?yún)用婢捅欢伦×?。同樣vo用來拼memberName、sessionName這類跨表展示字段避免在 entity 上掛一堆TableField(exist false)。service/impl是事務(wù)的唯一入口。Controller 不寫TransactionalMapper 也不寫事務(wù)邊界統(tǒng)一收在 Service 的公開方法上異常往上拋全局異常處理器統(tǒng)一轉(zhuǎn)成Result。這套約定聽著教條但項目一旦超過二十個接口沒有約定就會亂成一鍋粥。2.3 把項目跑起來配置、建庫、啟動四步配置文件里真正需要改的其實只有三處數(shù)據(jù)源、時區(qū)、MyBatis 的 mapper 掃描路徑。剩下的照抄即可。server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver # serverTimezone 必須顯式指定否則 MySQL 8 下時間會整體偏移 url: jdbc:mysql://127.0.0.1:3306/swim_center?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: 123456 jackson: # 統(tǒng)一出參時間格式前端不用再自己格式化 date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml configuration: map-underscore-to-camel-case: true # 下劃線轉(zhuǎn)駝峰entity 不用寫 TableField log-impl: org.apache.ibatis.logging.stdout.StdOutImpl參數(shù)含義逐個說serverTimezoneAsia/Shanghai解決的是 JDBC 驅(qū)動和 MySQL 服務(wù)端時區(qū)解釋不一致的問題不加它LocalDateTime寫進去再讀出來可能差 8 小時allowPublicKeyRetrievaltrue是 MySQL 8 默認加密插件在沒配 SSL 時的必需項不加會報Public Key Retrieval is not allowedmap-underscore-to-camel-case打開后create_time自動映射到createTime省掉大量TableField注解。啟動步驟按順序走# 1. 建庫字符集必須是 utf8mb4否則會員昵稱里的表情符號存不進去 mysql -uroot -p -e CREATE DATABASE swim_center DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci; # 2. 導入表結(jié)構(gòu)和初始數(shù)據(jù)順序不能反 mysql -uroot -p swim_center sql/schema.sql mysql -uroot -p swim_center sql/data.sql # 3. 編譯打包課設(shè)階段沒必要跑測試拖時間 mvn clean package -DskipTests # 4. 啟動生產(chǎn)環(huán)境把 dev 換成 prod日志級別和連接池參數(shù)會跟著切 java -jar target/swim-center-1.0.0.jar --spring.profiles.activedev跑起來之后先訪問登錄接口拿 token再拿 token 去調(diào)會員列表能返回數(shù)據(jù)就說明數(shù)據(jù)源、MyBatis 映射、鑒權(quán)攔截器三關(guān)都通了。這一步別急著看前端頁面接口通不通是根頁面白屏十有八九是跨域或者 token 沒帶。提示data.sql里一般會預置一個管理員賬號和幾條卡類型字典。密碼如果存的是 MD5第一次登錄后記得在后臺改掉別直接拿去部署。3. 核心業(yè)務(wù)拆解從賣一張票到放一個人進場3.1 會員卡與余額扣減先查后改為什么一定會出事余額扣減是這個項目里最容易寫錯的地方。新手版本的寫法通常是先select出卡對象判斷balance amount然后setBalance(balance - amount)再update。單機單線程跑起來毫無問題一開并發(fā)就翻車兩個請求同時讀到余額 100各自判斷通過各自寫回 0 和 0實際扣了兩次但賬上只少了一次。正確的做法是把判斷和更新壓到一條 SQL 里由數(shù)據(jù)庫保證原子性影響行數(shù)就是唯一判據(jù)。Service RequiredArgsConstructor public class MemberCardService { private final MemberCardMapper cardMapper; private final CardFlowMapper flowMapper; /** * 扣減余額 * param cardId 會員卡主鍵 * param amount 扣減金額單位分 * param bizNo 業(yè)務(wù)單號用于流水冪等 */ Transactional(rollbackFor Exception.class) public void deductBalance(Long cardId, Long amount, String bizNo) { // 條件更新余額不足、卡凍結(jié)、卡過期三種情況都會讓 rows 為 0 int rows cardMapper.deductBalance(cardId, amount); if (rows 0) { throw new BizException(卡余額不足或卡狀態(tài)不可用); } // 流水落庫biz_no 上建唯一索引重復提交會直接拋 DuplicateKeyException CardFlow flow new CardFlow(); flow.setCardId(cardId); flow.setAmount(-amount); flow.setBizNo(bizNo); flow.setCreateTime(LocalDateTime.now()); flowMapper.insert(flow); } }對應(yīng)的 Mapper SQLupdate iddeductBalance UPDATE member_card SET balance balance - #{amount}, update_time NOW() WHERE id #{cardId} AND status 1 AND (expire_time IS NULL OR expire_time gt; NOW()) AND balance gt; #{amount} /update三個參數(shù)的作用分別是cardId定位到具體一行InnoDB 會在這行上加排他鎖amount是扣減額用減法而不是覆蓋賦值天然避免丟失更新bizNo不進這條 SQL但它是流水表的唯一鍵同一個業(yè)務(wù)單號重復調(diào)用第二次會直接拋唯一鍵沖突相當于給接口加了一層冪等。為什么不用select ... for update不是不能用而是它把鎖的持有時間拉長了中間還要走一遍 Java 判斷代碼路徑變長就多一個出錯點。條件更新一條語句解決鎖的范圍和時長都是最小的。金額單位統(tǒng)一用「分」存bigint這一點后面還會提到它是對賬能不能對上的分水嶺。3.2 場次容量一條帶 where 的 update 擋住超賣游泳館和普通票務(wù)不一樣它有時段概念。上午場限 200 人賣滿就不能再賣否則池子里站不下。這個「賣滿」的控制本質(zhì)和秒殺扣庫存是同一類問題。表里給swim_session放兩個字段capacity可售人次sold已售人次。下單時不是先查sold capacity再更新而是直接帶著條件去更新。Transactional(rollbackFor Exception.class) public Long buyTicket(Long sessionId, Long memberId, Long ticketTypeId) { // 第一步占坑。只有 sold capacity 時才會 1返回 0 說明已滿 int rows sessionMapper.tryOccupy(sessionId); if (rows 0) { throw new BizException(該場次已滿請選擇其他場次); } // 第二步落訂單。訂單插入失敗會觸發(fā)整個事務(wù)回滾把剛占的坑位吐回去 TicketOrder order new TicketOrder(); order.setOrderNo(OrderNoUtil.next()); order.setMemberId(memberId); order.setSessionId(sessionId); order.setTicketTypeId(ticketTypeId); order.setStatus(1); // 1 待入場 order.setCreateTime(LocalDateTime.now()); orderMapper.insert(order); return order.getId(); }update idtryOccupy UPDATE swim_session SET sold sold 1 WHERE id #{sessionId} AND status 1 AND sold lt; capacity /update這段的關(guān)鍵在于「相對更新」而不是「絕對值更新」。sold sold 1是在數(shù)據(jù)庫當前值基礎(chǔ)上加多個事務(wù)并發(fā)進來InnoDB 的行鎖會把它們排成隊每個事務(wù)看到的都是上一個事務(wù)提交后的值sold capacity這個條件在排隊過程中逐個判定第 201 個人拿到的rows必然是 0。status 1這個條件也別省。場次被后臺手動關(guān)閉之后即使沒賣滿也不該繼續(xù)放票把它寫進 where 里關(guān)閉動作和售賣動作天然互斥。注意這里整段必須在同一個事務(wù)里。如果占坑和落訂單分別提交訂單插入失敗時坑位不會回滾sold就會越漲越高最后場次明明沒人卻顯示已滿這種臟數(shù)據(jù)排查起來極其費勁。3.3 入場核銷掃碼掃兩次賬不能記兩條前臺核銷是這個系統(tǒng)里調(diào)用頻率最高、也最容易出并發(fā)的接口?？腿四弥S碼在閘機前晃網(wǎng)絡(luò)抖一下前端重試一次或者工作人員手快點兩下就會出現(xiàn)同一個訂單進兩次的情況。核銷接口必須做到冪等。設(shè)計上走狀態(tài)機訂單狀態(tài) 1 是待入場2 是已入場3 是已退票。核銷就是把 1 推到 2推不動就說明已經(jīng)處理過了。Transactional(rollbackFor Exception.class) public void checkIn(String orderNo, String gateNo) { TicketOrder order orderMapper.selectByOrderNo(orderNo); if (order null) { throw new BizException(訂單不存在); } // 帶原狀態(tài)的條件更新只有當前還是 1 才能推到 2 int rows orderMapper.updateStatus(order.getId(), 1, 2); if (rows 0) { // 推不動有兩種可能已核銷狀態(tài) 2或已退票狀態(tài) 3 // 已核銷直接靜默返回重復掃碼不彈紅已退票才需要報錯 TicketOrder latest orderMapper.selectById(order.getId()); if (latest.getStatus() 2) { return; } throw new BizException(該訂單狀態(tài)不可入場); } EntryRecord record new EntryRecord(); record.setOrderId(order.getId()); record.setMemberId(order.getMemberId()); record.setSessionId(order.getSessionId()); record.setGateNo(gateNo); record.setEntryTime(LocalDateTime.now()); entryRecordMapper.insert(record); }update idupdateStatus UPDATE ticket_order SET status #{toStatus}, update_time NOW() WHERE id #{id} AND status #{fromStatus} /updateupdateStatus的三個參數(shù)是訂單主鍵、期望的原狀態(tài)、目標狀態(tài)本質(zhì)是一個 CAS 操作。并發(fā)兩次請求只有一個能把status 1改成 2另一個影響行數(shù)為 0走靜默返回分支。數(shù)據(jù)庫層面再加一道保險entry_record表上給order_id建唯一索引。就算哪天有人繞過 Service 直接寫 Mapper或者事務(wù)傳播行為配錯導致狀態(tài)更新和記錄插入不在一個事務(wù)里唯一索引也會在第二次插入時拋異常把臟數(shù)據(jù)擋在門外。這種「代碼邏輯 數(shù)據(jù)庫約束」雙保險的寫法在涉及錢和進出的業(yè)務(wù)里我基本都會加上。3.4 日結(jié)報表一條聚合 SQL 加一層 VO場館老板每天最關(guān)心的就三件事今天賣了多少張、收了多少錢、會員占多少。這個需求用一條 SQL 就夠了不需要在 Java 里循環(huán)累加。SELECT DATE(o.create_time) AS bizDate, COUNT(*) AS orderCnt, SUM(o.amount) AS totalAmount, SUM(CASE WHEN o.member_id IS NOT NULL THEN 1 ELSE 0 END) AS memberCnt, SUM(CASE WHEN o.source 2 THEN 1 ELSE 0 END) AS offlineCnt FROM ticket_order o WHERE o.status IN (1, 2) -- 排除已退票 AND o.create_time gt; #{startTime} AND o.create_time lt; #{endTime} -- 用小于而不是小于等于避開邊界重復 GROUP BY DATE(o.create_time) ORDER BY bizDate DESC幾個細節(jié)值得說。SUM(o.amount)依賴amount是整數(shù)分如果是decimal或者double累加幾十萬條之后尾差會顯現(xiàn)出來對賬時差一分錢能讓人查一下午。create_time start AND create_time end這種左閉右開的寫法是為了避免BETWEEN在跨天統(tǒng)計時把 23:59:59 之后的數(shù)據(jù)漏掉或者重復算。返回的 VO 里totalAmount在序列化前除以 100 轉(zhuǎn)成元用BigDecimal做除法并指定保留兩位別直接用double除浮點誤差在小數(shù)位上會現(xiàn)形。public class DailyReportVO { private String bizDate; private Integer orderCnt; private BigDecimal totalAmount; // 出參已轉(zhuǎn)成元保留兩位 private Integer memberCnt; private Integer offlineCnt; }報表接口一般還要支持按場次維度再切一刀那就把GROUP BY DATE(o.create_time)換成GROUP BY o.session_id其余聚合邏輯不變。同一個 Mapper 里放兩個selectService 層根據(jù)前端傳的dimension參數(shù)分發(fā)比寫兩套 Controller 干凈。4. 數(shù)據(jù)表與 SQL十幾張表撐起一個場館4.1 核心表清單與字段取舍整個系統(tǒng)的表不算多十四五張能覆蓋主要業(yè)務(wù)。按模塊歸一下表名作用關(guān)鍵字段備注member會員檔案name、phone、status手機號建唯一索引card_type卡類型字典type、price、times、valid_daystype1 儲值 2 次卡 3 期限卡member_card會員持卡card_no、balance、remain_times、expire_time金額單位分swim_session場次start_time、capacity、sold、status售賣核心表ticket_order票訂單order_no、session_id、amount、status狀態(tài)機 1/2/3entry_record入場記錄order_id、gate_no、entry_timeorder_id唯一card_flow卡流水card_id、amount、biz_nobiz_no唯一冪等用coach教練name、level、phone排課關(guān)聯(lián)course_schedule課程排期coach_id、start_time、capacity二次開發(fā)高頻改動點locker儲物柜no、status、member_id可選模塊water_quality水質(zhì)記錄ph、chlorine、check_time應(yīng)付檢查用sys_user/sys_role/sys_menu權(quán)限三件套—配關(guān)聯(lián)表字段取舍上有個原則凡是涉及錢和次數(shù)的一律用整數(shù)存最小單位。balance存分、remain_times存整數(shù)次數(shù)不用decimal也不用double?？粗粌?yōu)雅但省掉了所有浮點比較的麻煩balance amount直接比大小不用考慮0.1 0.2 ! 0.3這種玄學問題。時間字段統(tǒng)一用datetime而不是timestamp。timestamp有 2038 年上限而且會隨時區(qū)轉(zhuǎn)換導出報表給別人時容易對不上。datetime存的是字面值存什么讀什么配合LocalDateTime用起來最省心。4.2 三張關(guān)鍵表的建表腳本swim_session是全場最熱的一張表讀寫都集中在這。索引除了主鍵只留一個時間范圍查詢用的聯(lián)合索引。CREATE TABLE swim_session ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主鍵, name varchar(64) NOT NULL COMMENT 場次名如上午場, start_time datetime NOT NULL COMMENT 開場時間, end_time datetime NOT NULL COMMENT 散場時間, capacity int NOT NULL DEFAULT 0 COMMENT 可售人次, sold int NOT NULL DEFAULT 0 COMMENT 已售人次, status tinyint NOT NULL DEFAULT 1 COMMENT 1開放 0關(guān)閉, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_time (start_time, end_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT場次表;entry_record的重點在唯一索引它是核銷冪等的最后一道防線。CREATE TABLE entry_record ( id bigint NOT NULL AUTO_INCREMENT, order_id bigint NOT NULL COMMENT 票訂單主鍵, member_id bigint DEFAULT NULL, session_id bigint NOT NULL, gate_no varchar(32) DEFAULT NULL COMMENT 閘機編號, entry_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order (order_id), -- 一個訂單只能進一次 KEY idx_session_time (session_id, entry_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT入場記錄;member_card的card_no唯一索引用來防止重復發(fā)卡member_id上的普通索引用來做「查這個人的所有卡」這個高頻查詢。CREATE TABLE member_card ( id bigint NOT NULL AUTO_INCREMENT, member_id bigint NOT NULL, card_no varchar(32) NOT NULL COMMENT 卡號可掃碼, card_type_id bigint NOT NULL, balance bigint NOT NULL DEFAULT 0 COMMENT 余額單位分, remain_times int NOT NULL DEFAULT 0 COMMENT 次卡剩余次數(shù), expire_time datetime DEFAULT NULL, status tinyint NOT NULL DEFAULT 1 COMMENT 1正常 0凍結(jié) 2作廢, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_card_no (card_no), KEY idx_member (member_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT會員卡;ON UPDATE CURRENT_TIMESTAMP這個細節(jié)省事任何一次 update 都自動刷新update_time不用在每條 SQL 里手寫。但要注意如果哪天做數(shù)據(jù)同步需要保留原始時間得顯式在 update 語句里給update_time賦值否則會被自動覆蓋。4.3 慢查詢一般出在哪這個體量的系統(tǒng)數(shù)據(jù)量不上百萬基本不會慢。真正出問題的地方集中在兩類查詢上。第一類是報表的日期范圍掃描。ticket_order表只建了主鍵索引WHERE create_time BETWEEN ...會走全表掃。解決辦法是給create_time單獨建索引或者建(status, create_time)的聯(lián)合索引把狀態(tài)過濾也帶上。聯(lián)合索引的字段順序按「等值在前、范圍在后」排status IN (1,2)是等值create_time是范圍順序不能反。第二類是后臺列表的模糊搜索。會員列表按姓名或手機號搜LIKE %張%前置通配符會讓索引失效。這個場景數(shù)據(jù)量一般不大實在要優(yōu)化就上全文索引或者把手機號改成前綴匹配LIKE 138%。別為了這個去引 ES運維成本遠超收益。還有一種隱蔽的慢來自 N1 查詢。訂單列表里每條記錄都要顯示會員姓名和場次名稱如果循環(huán)里逐條查一頁 20 條就是 40 次查詢。改成 MyBatis 的collection嵌套查詢或者直接在 SQL 里LEFT JOIN一次搞定。XML 里寫 join 比在 Java 里拼裝可讀性高得多。4.4 初始化數(shù)據(jù)與字典data.sql里必須預置的東西有四類管理員賬號、卡類型字典、場次模板、菜單權(quán)限。-- 管理員密碼是 BCrypt 加密后的 123456首次登錄必須改 INSERT INTO sys_user (id, username, password, real_name, status) VALUES (1, admin, $2a$10$N.zmdr9k7uOCQb376NoUnuTJ8iAt6Z5EHsM8lE9lBOsl7iKTVKIUi, 管理員, 1); -- 卡類型儲值卡、次卡、月卡 INSERT INTO card_type (id, name, type, price, times, valid_days) VALUES (1, 儲值卡, 1, 0, 0, NULL), (2, 十次卡, 2, 300, 10, 180), (3, 月卡, 3, 500, 0, 30); -- 場次模板日期部分按實際排期改 INSERT INTO swim_session (name, start_time, end_time, capacity, sold, status) VALUES (上午場, 2024-07-01 08:00:00, 2024-07-01 12:00:00, 200, 0, 1), (下午場, 2024-07-01 13:00:00, 2024-07-01 17:00:00, 200, 0, 1), (夜場, 2024-07-01 18:00:00, 2024-07-01 22:00:00, 150, 0, 1);密碼用 BCrypt 而不是 MD5是因為 MD5 撞庫太容易而且同一個密碼每次加密結(jié)果一樣拖庫之后一眼就能看出哪些用戶密碼相同。BCrypt 自帶鹽值每次加密結(jié)果不同校驗時用matches比對。菜單數(shù)據(jù)插入后登錄接口返回的菜單樹才有內(nèi)容前端側(cè)邊欄不會空著。這塊數(shù)據(jù)建議直接從 SQL 腳本導入別在代碼里硬編碼改權(quán)限的時候只改數(shù)據(jù)不改代碼。5. 避坑與排查五個坑每一個都能卡住半天5.1 環(huán)境和啟動階段的三個坑現(xiàn)象啟動報Communications link failure日志里連不上數(shù)據(jù)庫。原因通常是三種MySQL 服務(wù)沒起、端口不是 3306、或者 8.0 版本必須帶allowPublicKeyRetrievaltrue而配置里漏了。 解決順序是先telnet 127.0.0.1 3306確認端口通再檢查 URL 參數(shù)。如果是 Docker 起的 MySQL注意容器內(nèi)外的端口映射本地連127.0.0.1沒問題但配置里寫成容器名就需要在同一網(wǎng)絡(luò)里。現(xiàn)象頁面上的時間和數(shù)據(jù)庫里存的差 8 小時。原因是時區(qū)在三處各管一段JDBC 連接的serverTimezone、Jackson 序列化的time-zone、MySQL 服務(wù)端的time_zone。哪一處沒對齊都會偏。 解決是把三處統(tǒng)一成Asia/Shanghai并且在實體類上不要再用java.util.Date統(tǒng)一換成LocalDateTime。Date會受 JVM 默認時區(qū)影響LocalDateTime是明確的本地時間語義少一層解釋就少一個坑?，F(xiàn)象前端拿到的id末尾幾位變成 0或者詳情頁查不到數(shù)據(jù)。原因是雪花算法生成的長整型超過了 JavaScript 的Number.MAX_SAFE_INTEGERJSON 反序列化時精度丟失。 解決有兩種后端全局配置 Jackson 把Long序列化成字符串或者給主鍵字段加JsonSerialize(using ToStringSerializer.class)。我一般選全局配置一次性解決所有實體省得漏加。Configuration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer longToString() { return builder - builder .serializerByType(Long.class, ToStringSerializer.instance) .serializerByType(Long.TYPE, ToStringSerializer.instance); } }這個配置加上之后前端所有id都是字符串路由傳參和比較時要注意別用直接比數(shù)字血淚經(jīng)驗。5.2 業(yè)務(wù)和數(shù)據(jù)層面的兩個坑現(xiàn)象對賬時總額差幾分錢逐條核對又看不出問題。原因八成是金額字段用了double或者float累加過程中產(chǎn)生了浮點誤差。0.1 0.2 0.30000000000000004這種事在單條記錄上看不出來聚合之后就顯形了。 解決是把金額全部改成bigint存分Java 側(cè)用Long只在展示層除以 100 轉(zhuǎn)BigDecimal。改的時候要全表掃一遍凡是decimal(10,2)的金額字段都換成bigintSQL 里的SUM結(jié)果再除。這個改造越早做越省事等數(shù)據(jù)攢了幾十萬條再改遷移腳本能寫到你懷疑人生?，F(xiàn)象Service 方法上明明加了Transactional拋異常后數(shù)據(jù)還是寫進去了。原因有四種常見情況同類內(nèi)部方法自調(diào)用代理不生效異常被try-catch吞掉沒有重新拋出方法不是public異常類型是受檢異常而注解沒配rollbackFor。 排查方法是先看調(diào)用是不是從外部進來的再看 catch 塊里有沒有throw最后確認注解寫了rollbackFor Exception.class。Spring 默認只對RuntimeException回滾業(yè)務(wù)里拋的自定義異常如果繼承的是Exception不加這個參數(shù)就不會回滾這個坑我見過不止一次。// 錯誤示范內(nèi)部自調(diào)用事務(wù)注解形同虛設(shè) public void outer() { this.inner(); // 走的是 this不是代理對象 } Transactional(rollbackFor Exception.class) public void inner() { /* ... */ }正確做法是把inner挪到另一個 Bean 里或者注入自身代理Lazy MemberCardService self再調(diào)self.inner()。后者寫法簡單但有點繞前者結(jié)構(gòu)更清晰我一般選前者?，F(xiàn)象核銷接口偶發(fā)Duplicate entry異常日志里一片紅。原因不是 bug恰恰是唯一索引在起作用——同一個訂單被并發(fā)核銷了兩次第二次插入被擋下來了。但這個異常如果直接拋到前端工作人員會以為系統(tǒng)壞了。 解決是在 Service 層捕獲DuplicateKeyException當成「已核銷」處理返回成功即可。同時把狀態(tài)更新的 CAS 邏輯補上讓絕大多數(shù)重復請求在第一步就被攔住唯一索引只做兜底。6. 二次開發(fā)加一個培訓課程報名模塊要動哪幾層場館跑順之后老板十有八九會提一句「順便把游泳培訓班的報名也管起來」。這個需求看著是新增實際是復用改動清單可以列得很清楚。層次改動內(nèi)容復用點表新增course、course_schedule、course_booking容量字段和swim_session同構(gòu)實體/Mapper三張表各生成一套MyBatis-Plus 代碼生成器直接跑ServiceCourseBookingService.book()直接套 3.2 的tryOccupy模式Controller報名、取消、我的課程三個接口鑒權(quán)和統(tǒng)一返回體沿用菜單sys_menu插三條記錄綁定角色后臺刷新即可見核心的報名扣名額邏輯和票務(wù)售賣是同一個套路把表名換掉就行Transactional(rollbackFor Exception.class) public Long book(Long scheduleId, Long memberId) { // 和場次占坑完全一致的 CAS 寫法只是換了張表 int rows scheduleMapper.tryBook(scheduleId); if (rows 0) { throw new BizException(該課程已報滿); } // 報名記錄上給 (schedule_id, member_id) 建唯一索引防止同一個人重復報 CourseBooking booking new CourseBooking(); booking.setScheduleId(scheduleId); booking.setMemberId(memberId); booking.setStatus(1); bookingMapper.insert(booking); return booking.getId(); }驗證的時候別只點頁面。用ab或者 JMeter 對報名接口打 200 并發(fā)搶 50 個名額跑完查SELECT COUNT(*) FROM course_booking WHERE schedule_id ?是不是正好 50再看sold字段和實際記錄數(shù)對不對得上。這個驗證方法比點一百次頁面都管用而且能順帶壓出連接池配置的問題。還有一個容易忽略的點新模塊上線前把course_booking的唯一索引和course_schedule的sold capacity條件一起寫進回歸清單。后來加功能的人如果只改了 Service 沒動 SQL接口層面測不出問題只有并發(fā)場景才會暴露。從那以后我每次給這類系統(tǒng)加新模塊都強制先跑一遍并發(fā)腳本再提測寧可多花二十分鐘也不想半夜被電話叫起來查「為什么多賣了八張票」。希望這些拆解能幫你少走點彎路。本文還有配套的精品資源點擊獲取