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