1. 項(xiàng)目背景與方案選型1.1 售票痛點(diǎn)與系統(tǒng)定位做線上動(dòng)物園售票系統(tǒng)之前很多人第一反應(yīng)是“這無非是個(gè) CRUD 項(xiàng)目”。真上手之后你會(huì)發(fā)現(xiàn)訂單、庫存、支付狀態(tài)、退票規(guī)則這些點(diǎn)每一個(gè)都能讓你加班到半夜。這個(gè)系統(tǒng)的核心價(jià)值一方面是替游客省去現(xiàn)場排隊(duì)買票的時(shí)間另一方面是幫園區(qū)把票務(wù)數(shù)據(jù)沉淀下來——銷量統(tǒng)計(jì)、熱門時(shí)段分析、游客畫像全都得有數(shù)據(jù)支撐才能做。這個(gè)項(xiàng)目我定位為課程設(shè)計(jì)/畢業(yè)設(shè)計(jì)級(jí)別的完整案例不是玩具但也沒有過度工程化。它要覆蓋一條完整的購票鏈路游客瀏覽票種 → 注冊(cè)登錄 → 選擇日期與數(shù)量 → 創(chuàng)建訂單 → 模擬支付或?qū)诱鎸?shí)支付 → 生成電子票二維碼 → 入園時(shí)掃碼核銷。同時(shí)后臺(tái)需要支持票種管理、訂單管理、用戶管理、公告發(fā)布、數(shù)據(jù)統(tǒng)計(jì)。整個(gè)系統(tǒng)用 SpringBoot 作為后端主框架前端我選了 Vue Element UI數(shù)據(jù)庫用 MySQL緩存加了一層 Redis。如果你正準(zhǔn)備拿 Java 方向做畢設(shè)或課設(shè)這套組合的覆蓋面足夠廣答辯時(shí)也講得出東西。1.2 技術(shù)選型背后的取舍邏輯SpringBoot 在 Java 生態(tài)中的地位不用多說我選它的核心原因是啟動(dòng)快、配置收斂、生態(tài)成熟。你不用像 SSM 時(shí)代那樣寫一堆 XML一個(gè)SpringBootApplication就能跑起來。但這不代表你不需要理解底層——比如 SpringBoot 默認(rèn)整合了 Spring MVC、內(nèi)嵌 Tomcat、自動(dòng)配置機(jī)制你至少要明白spring-boot-starter-web幫你做了什么否則遇到詭異問題根本無從排查。持久層框架我選了 MyBatis Plus而不是原生 MyBatis 或 JPA。原因很簡單單表 CRUD 要是手寫 XML效率太低JPA 雖然省事但復(fù)雜查詢和 SQL 調(diào)優(yōu)不直觀。MyBatis Plus 兼顧兩者內(nèi)置的BaseMapper能覆蓋 80% 的簡單操作復(fù)雜統(tǒng)計(jì)用注解 SQL 或 XML 自己寫可控性很強(qiáng)。另外它自帶分頁插件后臺(tái)列表頁和訂單查詢都直接受益。Redis 的引入主要是兩件事一是緩存票種信息和公告減少數(shù)據(jù)庫壓力二是購票時(shí)的庫存預(yù)扣與防超賣處理。這兩個(gè)場景用 Redis 的原子操作非常合適。如果只是純課程設(shè)計(jì)完全不引入 Redis 也能跑但我想讓這個(gè)項(xiàng)目有一點(diǎn)“生產(chǎn)味道”所以把它加了進(jìn)來。至于支付真實(shí)對(duì)接微信/支付寶需要商戶號(hào)個(gè)人項(xiàng)目拿不到所以我在項(xiàng)目中做了“模擬支付”模塊同時(shí)把支付接口抽象出來后續(xù)要對(duì)接真實(shí)支付只需替換實(shí)現(xiàn)類。2. 系統(tǒng)模塊與數(shù)據(jù)庫設(shè)計(jì)2.1 角色權(quán)限與功能模塊拆解整個(gè)系統(tǒng)按角色劃分成三類游客、注冊(cè)用戶、管理員。游客只能瀏覽票種和公告注冊(cè)用戶在前者基礎(chǔ)上增加了購票、訂單查詢、退票、個(gè)人信息管理管理員則進(jìn)入后臺(tái)管理票種、訂單、用戶、公告還能看銷售統(tǒng)計(jì)報(bào)表。我畫模塊圖的時(shí)候習(xí)慣先列角色再列每個(gè)角色能做什么最后落到頁面和接口上。前臺(tái)部分的核心模塊是首頁輪播公告、票種列表、購票流程選日期/選數(shù)量/創(chuàng)建訂單、訂單中心待支付/已支付/已退票狀態(tài)流轉(zhuǎn)、電子票展示、個(gè)人中心。后臺(tái)部分的核心模塊是登錄鑒權(quán)、Dashboard 統(tǒng)計(jì)卡片、票種管理增刪改查上下架、訂單管理查看/退款、用戶管理、公告管理。這里我特別想強(qiáng)調(diào)一個(gè)容易在設(shè)計(jì)階段被忽略的點(diǎn)票種與日期庫存的關(guān)系。很多初學(xué)設(shè)計(jì)數(shù)據(jù)庫時(shí)只做一張 ticket 表存總量結(jié)果用戶選不同日期買票時(shí)庫存根本沒法區(qū)分。我實(shí)際的做法是引入“日期庫存表”每個(gè)票種對(duì)應(yīng)多個(gè)日期的庫存記錄比如“成人票-2025-06-01-剩余500張”。這樣既能控制單日可售量也為后續(xù)的限流和峰值控制留了余地。2.2 核心數(shù)據(jù)表結(jié)構(gòu)詳解數(shù)據(jù)庫我總共設(shè)計(jì)了9張表挑核心的幾張說一下設(shè)計(jì)思路。第一張是用戶表user。字段包括主鍵 id、手機(jī)號(hào)登錄賬號(hào)、密碼BCrypt 加密存儲(chǔ)、昵稱、頭像、角色標(biāo)識(shí)1-普通用戶 2-管理員、創(chuàng)建時(shí)間。手機(jī)號(hào)作為唯一登錄憑證在表上要加唯一索引。密碼絕對(duì)不能明文存儲(chǔ)這是底線我用 Spring Security 自帶的BCryptPasswordEncoder做哈希。第二張是票種表ticket_type。字段有名稱成人票/兒童票/學(xué)生票/家庭套票、描述、原價(jià)、售價(jià)、票種類型、狀態(tài)0-下架 1-上架、創(chuàng)建時(shí)間。這里有個(gè)細(xì)節(jié)原價(jià)和售價(jià)要分開方便后續(xù)做優(yōu)惠活動(dòng)。金額字段用 DECIMAL(10,2)千萬不要用 double/float線上環(huán)境因?yàn)楦↑c(diǎn)精度導(dǎo)致對(duì)不上賬的例子太多了。第三張是日期庫存表ticket_stock。字段有id、票種 id、售賣日期、總庫存、剩余庫存、版本號(hào)。這個(gè)表就是防超賣的關(guān)鍵戰(zhàn)場。版本號(hào)字段是為了后續(xù)做樂觀鎖控制用的雖然我在最終方案里用了 Redis 預(yù)扣為主數(shù)據(jù)庫還保留了樂觀鎖作為兜底雙保險(xiǎn)。第四張是訂單表ticket_order。字段有訂單編號(hào)自定義生成規(guī)則、用戶 id、訂單總金額、訂單狀態(tài)0-待支付 1-已支付 2-已取消 3-已退票 4-已完成、支付方式、支付時(shí)間、創(chuàng)建時(shí)間、更新時(shí)間。訂單號(hào)的生成規(guī)則我用了“日期 隨機(jī)數(shù) 用戶ID后四位”示例202506011430221234。不建議直接用數(shù)據(jù)庫自增 id 當(dāng)訂單號(hào)暴露給用戶容易被爬取和猜測這個(gè)點(diǎn)面過幾個(gè)面試官都問過。第五張是訂單明細(xì)表order_item。因?yàn)橐粋€(gè)訂單可能包含多種票一張家庭套票 兩張成人票訂單明細(xì)用來記錄每種票的數(shù)量、單價(jià)、小計(jì)金額。主表存總金額明細(xì)表存分項(xiàng)這是標(biāo)準(zhǔn)的 1:N 設(shè)計(jì)不要偷懶只建一張訂單表。最后還有公告表、輪播圖表、退款記錄表邏輯相對(duì)直接不展開細(xì)說。2.3 訂單狀態(tài)機(jī)與關(guān)鍵字段設(shè)計(jì)狀態(tài)機(jī)是這個(gè)系統(tǒng)里最值得細(xì)說的地方。訂單狀態(tài)我定義了五個(gè)0-待支付、1-已支付、2-已取消、3-已退票、4-已完成。它們之間的流轉(zhuǎn)關(guān)系是待支付可以到已支付用戶付款也可以到已取消用戶主動(dòng)取消或超時(shí)未付已支付可以到已退票用戶申請(qǐng)退款也可以到已完成入園核銷后自動(dòng)流轉(zhuǎn)已退票和已完成都是終態(tài)不能再做任何操作。這個(gè)狀態(tài)機(jī)定義清楚后所有的接口邏輯都圍繞它轉(zhuǎn)。比如用戶端“取消訂單”接口第一件事就是判斷當(dāng)前狀態(tài)是否為 0如果不是直接拒絕。又比如管理員“退款”接口只處理狀態(tài)為 1 的訂單。這樣看起來是代碼里幾行 if 判斷但設(shè)計(jì)階段沒想清楚后期就會(huì)陷入各種狀態(tài)錯(cuò)亂的 bug 泥潭。我還在訂單表里加了一個(gè)out_trade_no字段專門存第三方支付流水號(hào)。雖然模擬支付用不上但這是給未來對(duì)接真實(shí)支付留的擴(kuò)展位。做設(shè)計(jì)時(shí)預(yù)留這類字段是很好的習(xí)慣答辯加分項(xiàng)往往就在這些細(xì)節(jié)上。3. 核心業(yè)務(wù)實(shí)現(xiàn)與實(shí)操細(xì)節(jié)3.1 購票流程與庫存防超賣方案購票是整個(gè)系統(tǒng)最核心的鏈路。我把它拆成四個(gè)步驟參數(shù)校驗(yàn) → 庫存預(yù)扣 → 創(chuàng)建訂單 → 超時(shí)自動(dòng)釋放。前端頁面點(diǎn)擊“提交訂單”后后端接口按這個(gè)流程處理。參數(shù)校驗(yàn)階段除了判斷用戶是否登錄、票種是否存在、數(shù)量是否為正整數(shù)這些常規(guī)校驗(yàn)我還加了一個(gè)“售賣日期必須大于今天”的判斷防止用戶補(bǔ)買昨天的票。另外要校驗(yàn)單筆訂單最大購買數(shù)量我限制為每個(gè)票種最多 5 張防止惡意刷單。庫存預(yù)扣是我重點(diǎn)處理的部分。方案是這樣先把票種信息和目標(biāo)日期的庫存量緩存到 Rediskey 設(shè)計(jì)為stock:ticket:{ticketId}:{date}value 存剩余數(shù)量。用戶提交訂單時(shí)用一段 Lua 腳本原子執(zhí)行“檢查剩余量大于等于購買量 → 扣減剩余量 → 返回成功”否則返回庫存不足。為什么用 Lua 腳本因?yàn)?Redis 單線程執(zhí)行Lua 腳本能保證判斷和扣減這兩步的原子性避免并發(fā)情況下兩個(gè)請(qǐng)求同時(shí)讀到剩余量 1然后都買成功導(dǎo)致超賣。庫存預(yù)扣成功后才創(chuàng)建訂單記錄狀態(tài)置為待支付。這里有一個(gè)關(guān)鍵細(xì)節(jié)預(yù)扣的庫存并不會(huì)立即從數(shù)據(jù)庫的ticket_stock表扣減而是通過一個(gè)定時(shí)任務(wù)每隔 5 分鐘掃描待支付訂單如果超過 15 分鐘未支付就自動(dòng)取消同時(shí)恢復(fù) Redis 庫存來兜底。為什么用延遲釋放而不是立即釋放因?yàn)橛脩艨赡茉谥Ц俄撏Ａ羧绻崆搬尫艓齑鎰e人把票搶走了用戶支付成功卻沒票這體驗(yàn)太差了。而 15 分鐘不支付基本可以斷定用戶已經(jīng)放棄。數(shù)據(jù)庫表的剩余庫存字段只在訂單支付成功后才真正扣減。也就是說Redis 庫存負(fù)責(zé)“并發(fā)攔截”數(shù)據(jù)庫庫存負(fù)責(zé)“最終一致性”。等技術(shù)能力再強(qiáng)一點(diǎn)你可以用消息隊(duì)列把扣減動(dòng)作異步化但在這個(gè)項(xiàng)目體量下定時(shí)任務(wù)足夠。核心 Lua 腳本我貼出來這個(gè)腳本我調(diào)試過很多次-- KEYS[1] stock:ticket:{ticketId}:{date} -- ARGV[1] 購買數(shù)量 local remain tonumber(redis.call(GET, KEYS[1])) local buyNum tonumber(ARGV[1]) if remain and remain buyNum then redis.call(DECRBY, KEYS[1], buyNum) return 1 else return 0 end對(duì)應(yīng)的 Java 調(diào)用側(cè)要注意執(zhí)行完 Lua 腳本返回 1 才繼續(xù)創(chuàng)建訂單返回 0 直接拋業(yè)務(wù)異?！皫齑娌蛔恪?。另外 Redis 的 key 要設(shè)置過期時(shí)間比如票種下架或售賣日期過后可以讓它自動(dòng)淘汰避免臟數(shù)據(jù)長期占用內(nèi)存。3.2 訂單生成與超時(shí)自動(dòng)關(guān)閉訂單創(chuàng)建時(shí)幾個(gè)字段要特別處理。訂單編號(hào)我用了自定義生成器規(guī)則是yyyyMMddHHmmss 4位隨機(jī)數(shù) 用戶ID后四位。UUID 雖然簡單但很長且無序索引效率差純自增 id 又太容易暴露業(yè)務(wù)量。我的這個(gè)規(guī)則在演示效果和查詢性能之間比較均衡。創(chuàng)建訂單的接口我加了Transactional事務(wù)注解保證訂單主表和明細(xì)表要么一起成功要么一起回滾。有人可能疑惑Redis 庫存已經(jīng)扣了數(shù)據(jù)庫事務(wù)失敗怎么辦我的處理是在事務(wù)失敗時(shí)手動(dòng)調(diào)用一個(gè)releaseRedisStock()方法把預(yù)扣的庫存加回去。這一步不能依賴 Redis 的自動(dòng)過期因?yàn)?15 分鐘太久用戶立刻重試時(shí)會(huì)看到庫存被“吞了”。超時(shí)關(guān)閉訂單的定時(shí)任務(wù)我用 Spring 自帶的Scheduled實(shí)現(xiàn)固定間隔 30 秒執(zhí)行一次。任務(wù)邏輯是查詢狀態(tài)為待支付且創(chuàng)建時(shí)間小于當(dāng)前時(shí)間 15 分鐘的訂單列表逐單關(guān)閉并恢復(fù) Redis 庫存。這里我踩過一個(gè)坑千萬不能用SELECT * FROM ticket_order WHERE create_time DATE_SUB(NOW(), INTERVAL 15 MINUTE)一次性查出所有訂單然后 for 循環(huán)處理。如果訂單量大長事務(wù)會(huì)把表鎖住。正確做法是分頁查詢每批 100 條處理完再查下一批。這個(gè)習(xí)慣在大數(shù)據(jù)量下會(huì)救你一命。Scheduled(fixedDelay 30000) public void autoCloseExpiredOrders() { // 分頁查詢待支付且超時(shí)的訂單 PageOrder page orderMapper.selectExpiredOrders(new Page(1, 100), 15); while (page.getRecords().size() 0) { for (Order order : page.getRecords()) { // 關(guān)閉訂單恢復(fù)Redis庫存 closeOrder(order); } // 繼續(xù)查下一頁 page orderMapper.selectExpiredOrders(new Page(page.getCurrent() 1, 100), 15); } }定時(shí)任務(wù)里還要注意并發(fā)執(zhí)行問題。Scheduled默認(rèn)單線程執(zhí)行但如果任務(wù)執(zhí)行時(shí)間超過間隔會(huì)出現(xiàn)任務(wù)堆積。我建議在方法上加一個(gè)Lock如果是用 ShedLock 的話或者用一個(gè)簡單的AtomicBoolean標(biāo)志位防止重入。項(xiàng)目里我用的是標(biāo)志位方案夠用。3.3 電子票生成與核銷流程支付成功后系統(tǒng)要給用戶生成電子票。我用的是二維碼技術(shù)集成 ZXing 庫生成二維碼圖片內(nèi)容是一串加密后的憑證串。憑證串包含訂單號(hào)、票種ID、入園日期、用戶ID后四位我用 AES 對(duì)稱加密再拼接防止有人偽造二維碼。核銷場景是這樣的游客到了動(dòng)物園入口打開公眾號(hào)或 App 里的“我的電子票”出示二維碼工作人員用后臺(tái)的“檢票核銷”功能掃碼。掃碼后后端解析密文校驗(yàn)訂單狀態(tài)為已支付、入園日期與當(dāng)日匹配、核銷狀態(tài)為未使用滿足條件就更新狀態(tài)為已完成。這個(gè)流程里我特別提醒一個(gè)問題二維碼內(nèi)容不要直接放明文訂單號(hào)否則有人可以通過遍歷訂單號(hào)生成二維碼逃票。AES 加密雖然談不上絕對(duì)安全但在這種應(yīng)用場景里足以擋住大部分低級(jí)攻擊。密鑰別寫在代碼里放到application.yml的外部配置或者環(huán)境變量里項(xiàng)目文檔里也要注明。核銷接口必須是冪等的。如果游客的二維碼被掃了兩次第一次成功第二次要返回“該憑證已核銷”不能報(bào)系統(tǒng)異常。同時(shí)核銷操作要加鎖防止同一張票同時(shí)被兩個(gè)入口的機(jī)器掃碼導(dǎo)致并發(fā)更新。MySQL 行鎖用SELECT ... FOR UPDATE或者用 Redis分布式鎖都可以我這里用的是樂觀鎖更新時(shí)帶上核銷狀態(tài)條件影響行數(shù)為 0 說明已被核銷。3.4 接口設(shè)計(jì)與統(tǒng)一返回規(guī)范接口設(shè)計(jì)我走的是 RESTful 風(fēng)格但也沒有嚴(yán)格到教條的程度。比如“購票”這個(gè)動(dòng)作用POST /api/ticket/order來創(chuàng)建訂單“取消訂單”用PUT /api/ticket/order/{orderNo}/cancel來表示狀態(tài)變更。這樣接口的語義清晰前端對(duì)接時(shí)也容易理解。所有接口的返回格式統(tǒng)一為{ code: 200, message: success, data: {} }code 為 200 表示業(yè)務(wù)成功其他為業(yè)務(wù)錯(cuò)誤碼比如 40001 表示庫存不足40002 表示訂單狀態(tài)異常40003 表示參數(shù)校驗(yàn)失敗。我建議錯(cuò)誤碼分段規(guī)劃4xxxx 是前端傳參問題5xxxx 是服務(wù)端處理問題這樣通過錯(cuò)誤碼就能快速定位責(zé)任方。統(tǒng)一返回格式我用一個(gè)ResultT泛型類實(shí)現(xiàn)配合全局異常處理器RestControllerAdvice。業(yè)務(wù)異常類BizException里直接攜帶錯(cuò)誤碼和描述控制器代碼里只需要throw new BizException(ErrorCode.STOCK_NOT_ENOUGH)異常處理器統(tǒng)一捕獲并包裝返回。這個(gè)模式也是實(shí)際生產(chǎn)項(xiàng)目里的標(biāo)準(zhǔn)做法值得從課設(shè)階段就開始養(yǎng)成。另外接口層要加參數(shù)校驗(yàn)JSR 303 的Valid注解用起來。請(qǐng)求 DTO 里對(duì)數(shù)量字段加Min(1)、對(duì)日期字段加NotBlank。不要把這些校驗(yàn)依賴前端前端校驗(yàn)只是用戶體驗(yàn)后端校驗(yàn)才是安全底線。4. 前端頁面與接口對(duì)接4.1 前端技術(shù)棧與頁面路由結(jié)構(gòu)前端我選了 Vue 2 Element UI如果是新學(xué)建議直接上 Vue 3 Element Plus原理類似。通過 Axios 請(qǐng)求后端接口路由用 Vue Router狀態(tài)管理用 Vuex。為了演示方便我用vue-cli搭的工程開發(fā)時(shí)通過proxy配置把/api前綴的請(qǐng)求代理到后端 8080 端口避免跨域開發(fā)問題。頁面路由按用戶側(cè)和管理側(cè)拆分。用戶側(cè)頁面包括首頁、票種列表、購票確認(rèn)、訂單列表、訂單詳情、電子票、個(gè)人中心、登錄注冊(cè)。管理側(cè)頁面包括Dashboard、票種管理、訂單管理、用戶管理、公告管理、數(shù)據(jù)統(tǒng)計(jì)。整套頁面數(shù)量在 15 個(gè)左右工作量適中但覆蓋面足夠用來演示前后端分離開發(fā)的能力。4.2 購票頁面的關(guān)鍵交互邏輯購票確認(rèn)頁是最核心的交互頁面。它要完成加載票種列表 → 用戶選擇日期日期選擇控件禁用今天之前的日期→ 選擇數(shù)量 → 實(shí)時(shí)計(jì)算總價(jià) → 提交訂單?？們r(jià)計(jì)算我做了前端實(shí)時(shí)計(jì)算展示但后端接口會(huì)重新計(jì)算一遍以后端為準(zhǔn)。不要信任前端傳過來的金額這是防篡改的基本常識(shí)。前端傳參只傳票種ID、日期、數(shù)量金額由后端查表計(jì)算得出。訂單支付頁的邏輯也值得一提。用戶點(diǎn)擊“確認(rèn)支付”后前端調(diào)用支付接口后端在模擬支付模式下直接返回成功并將訂單狀態(tài)從待支付更新為已支付同時(shí)生成電子票。真實(shí)接入支付時(shí)這個(gè)接口會(huì)變成“調(diào)用支付平臺(tái)下單返回支付參數(shù)”前端跳轉(zhuǎn)收銀臺(tái)支付結(jié)果通過回調(diào)通知。我把PaymentService接口定義好分別實(shí)現(xiàn)了MockPaymentServiceImpl和預(yù)留的RealPaymentServiceImpl這塊設(shè)計(jì)在答辯時(shí)講出來會(huì)顯得專業(yè)。前端還有一個(gè)細(xì)節(jié)用戶從購物車一樣的購票頁跳到訂單確認(rèn)頁時(shí)后端返回的訂單號(hào)需要保存到 Vuex這樣支付成功后的電子票頁面才能查到屬于當(dāng)前用戶的電子票憑證。我見過不少同學(xué)把訂單號(hào)放在 URL query 里刷新頁面就丟了體驗(yàn)比較糟糕。4.3 管理后臺(tái)的統(tǒng)計(jì)報(bào)表實(shí)現(xiàn)Dashboard 統(tǒng)計(jì)頁面需要展示三個(gè)核心指標(biāo)今日銷售額、今日訂單數(shù)、本月售票總量。數(shù)據(jù)來源是訂單表按時(shí)間維度做聚合統(tǒng)計(jì)我用 MyBatis Plus 的selectMaps方法寫聚合 SQL返回ListMapString, Object前端用 ECharts 渲染柱狀圖和餅圖。這里有個(gè)性能優(yōu)化點(diǎn)統(tǒng)計(jì)接口每次實(shí)時(shí)查庫如果訂單量大了會(huì)很慢。我的處理是第一次查詢后把結(jié)果緩存到 Redis設(shè)置 60 秒過期相當(dāng)于容忍 1 分鐘內(nèi)的數(shù)據(jù)延遲。對(duì)于園區(qū)這種體量的業(yè)務(wù)這個(gè)延遲完全可接受。前端每 30 秒自動(dòng)刷一次配合緩存生效時(shí)間體驗(yàn)和性能之間取得平衡。5. 常見問題與排查心得5.1 庫存超賣問題排查實(shí)錄我測試時(shí)故意用 JMeter 開 200 個(gè)線程同時(shí)買同一個(gè)票種的最后一張票第一次測試就翻車了——賣出了 7 張。排查過程很有意思雖然最后定位到原因很簡單但把排查思路寫下來對(duì)大家有參考價(jià)值。首先檢查數(shù)據(jù)庫庫存表發(fā)現(xiàn)剩余庫存變成了負(fù)數(shù)。再翻日志發(fā)現(xiàn)Redis 里的庫存量其實(shí)扣減是正確的問題出在訂單支付成功后的“數(shù)據(jù)庫扣減”環(huán)節(jié)。我用的是先查庫存再更新庫存的代碼Stock stock stockMapper.selectByTicketIdAndDate(...); if (stock.getRemain() 0) { stock.setRemain(stock.getRemain() - 1); stockMapper.updateById(stock); }這種“讀改寫”模式下多線程同時(shí)讀到剩余 1條件都成立都執(zhí)行了更新就超賣了。修復(fù)方式是直接更新int rows stockMapper.deductStock(ticketId, date, 1); if (rows 0) { throw new BizException(ErrorCode.STOCK_NOT_ENOUGH); }對(duì)應(yīng) SQL 是UPDATE ticket_stock SET remain remain - 1, version version 1 WHERE ticket_id ? AND sell_date ? AND remain 1。通過數(shù)據(jù)庫行鎖和受影響的 UPDATE 保證原子性。這也是我在前面提到“樂觀鎖作為兜底”的原因。5.2 定時(shí)任務(wù)不執(zhí)行或重復(fù)執(zhí)行的坑Scheduled(cron 0 */5 * * * ?)這個(gè)寫法在單機(jī)環(huán)境下沒問題但如果未來系統(tǒng)部署了多實(shí)例每個(gè)實(shí)例都會(huì)執(zhí)行一遍定時(shí)任務(wù)導(dǎo)致重復(fù)處理。課程設(shè)計(jì)階段不會(huì)遇到多實(shí)例部署但我還是在文檔里提了一嘴解決方案用 Redis 的SETNX做一個(gè)簡單的分布式鎖SET key value NX EX 120獲取到鎖的實(shí)例才執(zhí)行任務(wù)執(zhí)行完刪除鎖或者引入 ShedLock 依賴兩行配置就搞定。另外提醒一個(gè)小坑SpringBoot 的Scheduled默認(rèn)線程池只有一個(gè)線程。如果你在任務(wù)內(nèi)部調(diào)了遠(yuǎn)程接口導(dǎo)致阻塞后續(xù)的任務(wù)全部卡住。我建議在配置類里顯式聲明ThreadPoolTaskScheduler設(shè)置核心線程數(shù)為 5避免一個(gè)慢任務(wù)拖垮其他定時(shí)任務(wù)。5.3 時(shí)間格式化、跨域與配置項(xiàng)小坑時(shí)間格式化這個(gè)問題幾乎每次都會(huì)遇到。后端返回LocalDateTime默認(rèn)是2025-06-01T14:30:00這種 ISO 格式前端展示很難看。我在application.yml里統(tǒng)一配置了 Jackson 的格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8跨域問題也一樣。前后端分離開發(fā)時(shí)前端 8080后端 9527瀏覽器會(huì)攔截跨域請(qǐng)求。我在后端寫了一個(gè)CorsConfig配置類允許所有來源、所有請(qǐng)求方法開發(fā)環(huán)境足夠。生產(chǎn)環(huán)境部署建議用 Nginx 反向代理統(tǒng)一入口徹底規(guī)避跨域問題同時(shí)也更安全。還有一個(gè)配置項(xiàng)坑SpringBoot 版本差異導(dǎo)致配置不生效。如果你用的 SpringBoot 2.4 以上的版本配置文件里的多環(huán)境配置寫法變了spring.profiles.active需要放到application.yml最外層不要再寫在spring.profiles下面。類似這些小坑我建議把踩過的記錄下來寫進(jìn)配套的“遇到的問題與解決”文檔中答辯時(shí)是一份很好的加分材料。5.4 配套文檔、PPT與源碼的組織經(jīng)驗(yàn)這個(gè)項(xiàng)目帶了完整的文檔和 PPT這部分經(jīng)驗(yàn)我從來沒見別人認(rèn)真整理過。畢設(shè)/課設(shè)答辯的評(píng)委會(huì)翻文檔但更重要的是他們會(huì)在現(xiàn)場讓你演示系統(tǒng)。所以我的文檔組織邏輯是需求分析用戶故事和功能清單 → 系統(tǒng)設(shè)計(jì)架構(gòu)圖數(shù)據(jù)庫ER圖接口文檔 → 系統(tǒng)實(shí)現(xiàn)核心代碼走讀 → 測試報(bào)告功能測試并發(fā)測試 → 總結(jié)與展望。PPT 則控制在 15 頁以內(nèi)核心是講清楚“我做了什么”和“我遇到了什么問題怎么解決的”不要堆代碼。源碼組織方面也有講究。后端模塊我按 controller、service、mapper、entity、common、config 分包一個(gè)包干一件事。前端把 api 請(qǐng)求封裝到src/api目錄下頁面組件在src/views下。整個(gè)代碼層級(jí)清晰別人拿到就能快速跑起來這是“含源碼”項(xiàng)目最基本的要求——不是把代碼甩出來就叫含源碼而是要讓接手的人能看明白、能改、能運(yùn)行。最后再分享一個(gè)小技巧整個(gè)系統(tǒng)做下來我最大的感受是課設(shè)級(jí)別的項(xiàng)目重點(diǎn)不在于技術(shù)多新多全而在于邏輯閉環(huán)。你做一個(gè)售票系統(tǒng)就要保證從注冊(cè)到購票到支付到核銷到退票整條鏈路每一個(gè)分支都處理到位。我見過太多項(xiàng)目演示時(shí)主流程很順暢一展示管理員退款就報(bào)錯(cuò)一展示庫存不足就白屏——這種硬傷特別致命。我自己的習(xí)慣是交付前花半天時(shí)間把核心業(yè)務(wù)鏈路的每一個(gè)接口用 Postman 過一遍包括異常場景未登錄訪問訂單接口、庫存為 0 時(shí)下單、重復(fù)核銷、非法參數(shù)請(qǐng)求。把這些異常處理正常了演示再過不了只能說明運(yùn)氣不好。另外記得MySQL 和 Redis 的本地環(huán)境配置、數(shù)據(jù)庫初始化腳本、Redis 數(shù)據(jù)預(yù)置命令全都要寫進(jìn) README。換一臺(tái)電腦就跑不起來這比你代碼寫得漂亮但要花三小時(shí)才能啟動(dòng)要致命得多。