地鐵票務(wù)這種題目在計(jì)算機(jī)畢設(shè)里屬于“看著簡單、做起來全是細(xì)節(jié)”的典型。表面上是做個(gè)買票APP實(shí)際上要把用戶體系、線路數(shù)據(jù)、訂單狀態(tài)、支付回調(diào)、并發(fā)扣減這些環(huán)節(jié)全部串起來。我去年幫一位同學(xué)完整走了一遍基于Java的地鐵購票App的開發(fā)與實(shí)習(xí)流程從選題、技術(shù)選型到編碼、調(diào)試再到寫論文整個(gè)過程踩了不少坑也總結(jié)出一套可以復(fù)用的思路。這篇文章就把這套完整經(jīng)歷拆開從核心設(shè)計(jì)到代碼落地方案再到實(shí)戰(zhàn)問題排查給正在做類似項(xiàng)目的同學(xué)一份可直接上手的參考。不需要你有三年工作經(jīng)驗(yàn)只要Java基礎(chǔ)和Servlet、MyBatis這類常用框架的基本概念按照這套路線走做出一個(gè)能演示、能答辯、邏輯自洽的地鐵購票系統(tǒng)是完全可行的。1. 項(xiàng)目核心定位地鐵購票App到底要解決什么問題做畢設(shè)最忌一上來就寫代碼。地鐵購票App這個(gè)題目首先得把業(yè)務(wù)邏輯想透。它不是簡單地把線下購票搬到線上而是涉及一整條交易鏈路用戶查線路、看站點(diǎn)、選擇車票類型、下單支付、生成電子票、進(jìn)站核驗(yàn)、退票處理。每一個(gè)環(huán)節(jié)都有獨(dú)立的業(yè)務(wù)規(guī)則這些規(guī)則才是系統(tǒng)的靈魂。1.1 業(yè)務(wù)痛點(diǎn)與系統(tǒng)目標(biāo)先聊聊痛點(diǎn)。地鐵自動(dòng)售票機(jī)只能處理單程票排隊(duì)是常態(tài)儲(chǔ)值卡充值要去人工窗口乘客查線路換乘往往要臨時(shí)看線路圖。一個(gè)線上購票App要解決的問題有三個(gè)一是把購票入口搬到手機(jī)端減少線下排隊(duì)二是讓乘客提前規(guī)劃路線并直接完成支付到站刷碼過閘三是沉淀乘客的出行記錄為后續(xù)優(yōu)惠活動(dòng)、客流分析留數(shù)據(jù)基礎(chǔ)。明確了痛點(diǎn)系統(tǒng)目標(biāo)就清晰了構(gòu)建一個(gè)面向普通乘客的地鐵出行購票平臺(tái)支持線路查詢、余票展示、在線下單、模擬支付、電子票生成、訂單管理、退票申請(qǐng)等功能。畢業(yè)設(shè)計(jì)語境下這里不用真的接入地鐵閘機(jī)但業(yè)務(wù)流程必須完整閉環(huán)讓評(píng)委看到的是一個(gè)“能跑通的真實(shí)系統(tǒng)”而不是幾個(gè)散落的CRUD頁面。1.2 功能模塊劃分與職責(zé)邊界功能模塊劃分建議遵循“用戶—票務(wù)—訂單—支付—后臺(tái)”五個(gè)維度用戶端注冊(cè)、登錄、個(gè)人中心、常用乘車人管理票務(wù)端線路列表、站點(diǎn)查詢、車票類型選擇單程/日票/月票訂單端創(chuàng)建訂單、訂單查詢、取消訂單、退票申請(qǐng)支付端模擬支付、支付狀態(tài)回調(diào)、訂單狀態(tài)流轉(zhuǎn)管理端基礎(chǔ)數(shù)據(jù)維護(hù)線路、站點(diǎn)、車票價(jià)格、訂單審計(jì)、退票審核模塊劃分的核心作用是把職責(zé)邊界定清楚。比如支付模塊只負(fù)責(zé)“改訂單支付狀態(tài)”不負(fù)責(zé)“生成車票”生成車票是訂單支付成功后的聯(lián)動(dòng)邏輯。我在項(xiàng)目里用了一個(gè)獨(dú)立的API層做模塊間通信避免Service之間互相new對(duì)象這是后面代碼能保持清爽的關(guān)鍵。每個(gè)模塊對(duì)應(yīng)的包名也建議規(guī)范一點(diǎn)比如controller、service、mapper、entity、dto這些基礎(chǔ)分層鋪好了后面寫業(yè)務(wù)代碼效率會(huì)高很多。1.3 為什么選擇Java技術(shù)棧選Java做這類項(xiàng)目最大的理由是生態(tài)成熟、參考資料多、出問題到處都有答案。Spring Boot簡化了配置MyBatis讓SQL可控MySQL存業(yè)務(wù)數(shù)據(jù)Redis做緩存和Token管理這套組合在就業(yè)市場(chǎng)上也是主流。相比PythonJava在事務(wù)管理、并發(fā)控制、類型安全方面更接近生產(chǎn)環(huán)境真實(shí)情況對(duì)畢設(shè)來說能體現(xiàn)你對(duì)工程化開發(fā)的理解深度。具體版本我建議JDK 8、Spring Boot 2.x、MyBatis 3.x、MySQL 5.7或8.0、Redis 6.x。前端如果不想寫復(fù)雜頁面直接用Vue ElementUI搭一個(gè)管理后臺(tái)用戶端用H5頁面模擬App也可以打包成Android WebView殼。這種“模擬但不失真實(shí)”的路線既能控制工作量又不影響系統(tǒng)完整度。2. 技術(shù)選型與開發(fā)環(huán)境準(zhǔn)備這一節(jié)把用到的工具和框架說清楚重點(diǎn)講為什么這么選以及搭建過程中容易被忽略的細(xì)節(jié)。2.1 后端框架組合的取舍后端我最終用的是Spring Boot MyBatis MySQL Redis這套組合。Spring Boot負(fù)責(zé)接口暴露和依賴管理MyBatis負(fù)責(zé)SQL與對(duì)象映射MySQL存業(yè)務(wù)數(shù)據(jù)Redis存Token和熱點(diǎn)線路緩存。沒有用Spring Cloud那套分布式方案原因很簡單畢設(shè)系統(tǒng)體量用不上而且配置Eureka、Nacos這類組件會(huì)消耗大量時(shí)間收益卻很低。優(yōu)先保證核心鏈路完整比堆技術(shù)棧更有說服力。事務(wù)管理用到Spring的Transactional主要是訂單創(chuàng)建、支付回調(diào)、退票這幾個(gè)寫操作。這里有個(gè)細(xì)節(jié)事務(wù)不是加得越多越好只讀查詢不需要事務(wù)不然會(huì)白白增加數(shù)據(jù)庫連接開銷。我建議把事務(wù)注解放在Service層方法上Controller層保持輕薄只有參數(shù)校驗(yàn)和響應(yīng)封裝。2.2 數(shù)據(jù)庫與緩存方案數(shù)據(jù)庫設(shè)計(jì)遵循三范式但實(shí)際建模時(shí)適度冗余。比如訂單表里冗余了用戶昵稱和車票類型名稱這樣查詢訂單列表時(shí)不用每次都關(guān)聯(lián)三張表。另一個(gè)關(guān)鍵點(diǎn)是地鐵線路數(shù)據(jù)是“讀多寫少”的典型場(chǎng)景把線路列表、站點(diǎn)經(jīng)緯度、票價(jià)表放進(jìn)Redis緩存能明顯緩解數(shù)據(jù)庫壓力。這個(gè)緩存不是在方法內(nèi)部隨手寫而是用一個(gè)CacheService統(tǒng)一管理緩存key和過期時(shí)間都集中定義方便后期調(diào)整。MySQL連接池用的HikariCPSpring Boot 2.x自帶默認(rèn)的參數(shù)不用改太多。注意一下maximum-pool-size個(gè)人開發(fā)環(huán)境默認(rèn)10就夠了調(diào)太大反而增加連接管理開銷。2.3 前端展示層的實(shí)現(xiàn)方式如果是個(gè)人獨(dú)立開發(fā)前端時(shí)間成本往往是最大的坑。我當(dāng)時(shí)的策略是管理后臺(tái)用Vue ElementUI因?yàn)楸砀瘛⒈韱?、彈窗這些組件開箱即用用戶端用H5頁面模擬App通過微信風(fēng)格的卡片布局展示線路和車票信息再用瀏覽器開發(fā)者工具切換成手機(jī)尺寸預(yù)覽。還有一個(gè)更輕的方案如果你不熟前端直接用Spring Boot的模板引擎Thymeleaf渲染頁面雖然交互體驗(yàn)弱一些但勝在不用另外啟動(dòng)前端服務(wù)。這里建議根據(jù)自己情況選型不要為了“看起來高級(jí)”硬上沒把握的前端框架。項(xiàng)目答辯時(shí)核心演示重點(diǎn)還是后端功能的完整性用戶端保證關(guān)鍵流程能跑通即可。2.4 開發(fā)工具清單與版本搭配工具這塊列一張我實(shí)際使用的清單方便照方抓藥工具版本用途注意點(diǎn)JDK1.8Java運(yùn)行環(huán)境選Oracle或OpenJDK均可Maven3.6依賴管理與打包配置阿里云鏡像加速IDEA2023.x主開發(fā)IDE安裝Lombok插件MySQL8.0主數(shù)據(jù)庫注意字符集utf8mb4Redis6.x緩存與TokenWindows用編譯版或WSLNavicat16.x數(shù)據(jù)庫客戶端方便導(dǎo)入導(dǎo)出SQLPostman10.x接口測(cè)試配置環(huán)境變量區(qū)分dev/prod版本搭配上Spring Boot 2.7.x對(duì)應(yīng)JDK 8完全沒問題不用追新。MyBatis用mybatis-spring-boot-starter2.3.x避免版本不對(duì)引發(fā)的綁定異常。2.5 環(huán)境搭建的幾個(gè)坑環(huán)境搭建看似簡單我實(shí)際幫同學(xué)調(diào)試時(shí)遇到過不少低級(jí)問題。第一個(gè)坑是MySQL字符集沒設(shè)置成utf8mb4導(dǎo)致存emoji或中文時(shí)出現(xiàn)亂碼。解決方式是建庫時(shí)顯式指定DEFAULT CHARACTER SET utf8mb4連接串加characterEncodingutf8。第二個(gè)坑是Redis端口被占用或沒設(shè)密碼Spring Boot連接時(shí)報(bào)Connection refused。第三個(gè)坑是IDEA里沒啟用Lombok的Annotation Processing導(dǎo)致實(shí)體類編譯時(shí)getter/setter找不到。這些問題單看都不復(fù)雜但如果沒提前排查會(huì)浪費(fèi)大量時(shí)間。3. 數(shù)據(jù)庫設(shè)計(jì)與核心表結(jié)構(gòu)數(shù)據(jù)庫設(shè)計(jì)決定了整個(gè)項(xiàng)目的上限。表結(jié)構(gòu)不合理后面寫業(yè)務(wù)代碼時(shí)會(huì)處處別扭。這一節(jié)把核心表的字段設(shè)計(jì)、關(guān)聯(lián)關(guān)系和設(shè)計(jì)意圖講明白。3.1 數(shù)據(jù)關(guān)系梳理整個(gè)系統(tǒng)的數(shù)據(jù)關(guān)系可以歸納為一個(gè)用戶有多張訂單一張訂單對(duì)應(yīng)一種車票類型一種車票類型關(guān)聯(lián)多條線路一條線路包含多個(gè)站點(diǎn)。訂單表是核心樞紐它把用戶、車票、線路串成一條完整鏈路。畫ER圖的時(shí)候注意區(qū)分邏輯關(guān)系和物理外鍵。比如訂單表和用戶表之間用user_id邏輯關(guān)聯(lián)但不一定真的建外鍵約束原因是在分頁查詢和刪改操作時(shí)外鍵會(huì)影響性能而且調(diào)試時(shí)很麻煩。我在實(shí)際項(xiàng)目中保留的邏輯外鍵較多物理外鍵一個(gè)都沒加數(shù)據(jù)一致性靠代碼邏輯保證。這個(gè)決策后期運(yùn)行下來是合理的。3.2 用戶表與訂單表設(shè)計(jì)要點(diǎn)用戶表user的字段不算多id、手機(jī)號(hào)、密碼BCrypt加密、昵稱、頭像URL、創(chuàng)建時(shí)間。手機(jī)號(hào)建議做成唯一索引因?yàn)樗堑卿涃~號(hào)邏輯刪除字段is_deleted用tinyint默認(rèn)0。密碼千萬不要明文存儲(chǔ)答辯時(shí)換一個(gè)安全意識(shí)也是加分項(xiàng)。訂單表order的字段是關(guān)鍵訂單號(hào)唯一、用戶id、車票類型id、線路id、站點(diǎn)起始、訂單金額、支付狀態(tài)、訂單狀態(tài)、創(chuàng)建時(shí)間、支付時(shí)間、取消時(shí)間。訂單號(hào)不用數(shù)據(jù)庫自增而是用時(shí)間戳隨機(jī)數(shù)生成避免業(yè)務(wù)數(shù)據(jù)被猜測(cè)。支付狀態(tài)和訂單狀態(tài)分開兩個(gè)字段因?yàn)椤耙阎Ц丁辈坏扔凇耙殉銎薄敝虚g隔一個(gè)狀態(tài)機(jī)流轉(zhuǎn)過程。3.3 線路與站點(diǎn)建模線路表line字段簡單線路名稱、線路編號(hào)、起點(diǎn)站、終點(diǎn)站、票價(jià)、運(yùn)營時(shí)間。站點(diǎn)表station字段站點(diǎn)名稱、所屬線路id、站點(diǎn)序號(hào)、換乘標(biāo)識(shí)、經(jīng)度、緯度。這里有個(gè)容易忽略的點(diǎn)一個(gè)站可能屬于多條線路換乘站所以站點(diǎn)和線路的關(guān)系是多對(duì)多需要一張中間表line_station關(guān)聯(lián)。如果你圖省事把站點(diǎn)直接掛在單條線路下后面做換乘查詢時(shí)只能傻眼。票價(jià)信息建議冗余在線路表里而不是單獨(dú)建票價(jià)表。原因很簡單地鐵票價(jià)規(guī)則通常是統(tǒng)一的按里程計(jì)價(jià)但畢設(shè)項(xiàng)目沒必要把計(jì)價(jià)規(guī)則做成動(dòng)態(tài)引擎直接在線路表里存一個(gè)基礎(chǔ)票價(jià)再按車票類型乘系數(shù)即可。我用一個(gè)工具類FareCalculator統(tǒng)一處理票價(jià)計(jì)算避免散落在各個(gè)Service里。3.4 余票與庫存設(shè)計(jì)地鐵本身沒有“余票”概念因?yàn)檫\(yùn)力是固定的但為了讓系統(tǒng)有購票邏輯的完整感我引入了“可售余票”字段存在線路表或車票類型表里。這個(gè)字段不是真實(shí)庫存而是一個(gè)初始化的虛擬數(shù)量每次購買成功后減一減到零就提示售罄。這樣做的好處是能走通“下單校驗(yàn)—扣減—回滾”這條完整事務(wù)鏈路跟真實(shí)電商交易的庫存邏輯一致?？蹨p余票操作我用了數(shù)據(jù)庫原子更新的方式UPDATE ticket_stock SET stock stock - 1 WHERE stock 0配合事務(wù)和行鎖能有效防止并發(fā)超賣。這個(gè)點(diǎn)在你的論文里可以寫成一個(gè)亮點(diǎn)體現(xiàn)你對(duì)并發(fā)控制的理解。4. 核心功能模塊的代碼級(jí)實(shí)現(xiàn)進(jìn)入編碼環(huán)節(jié)。這一節(jié)挑五個(gè)核心功能模塊拆開講包括實(shí)現(xiàn)思路、關(guān)鍵代碼片段、需要注意的邊界條件。4.1 用戶注冊(cè)登錄與Token鑒權(quán)注冊(cè)接口接收手機(jī)號(hào)和密碼密碼用BCrypt加密再入庫防止數(shù)據(jù)庫泄露后密碼裸奔。登錄成功后生成一個(gè)UUID作為Token存進(jìn)Rediskey是token:{uuid}value是用戶id過期時(shí)間設(shè)置為24小時(shí)。后續(xù)接口通過攔截器校驗(yàn)Token從Redis拿到用戶id后放進(jìn)ThreadLocal業(yè)務(wù)代碼直接從ThreadLocal取當(dāng)前用戶。這里有個(gè)細(xì)節(jié)登錄接口要加驗(yàn)證碼嗎畢設(shè)系統(tǒng)建議加因?yàn)樵u(píng)委經(jīng)常在這個(gè)環(huán)節(jié)挑毛病。用一個(gè)簡單的算術(shù)驗(yàn)證碼接口或者用Hutool生成圖片驗(yàn)證碼前端展示圖片后端比對(duì)一次后失效。成本不高但能明顯提升系統(tǒng)完整度。核心登錄邏輯參考如下Service public class AuthService { Autowired private UserMapper userMapper; Autowired private RedisTemplateString, String redisTemplate; public String login(String phone, String password) { User user userMapper.selectByPhone(phone); if (user null || !BCrypt.checkpw(password, user.getPassword())) { throw new BizException(手機(jī)號(hào)或密碼錯(cuò)誤); } String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(token: token, user.getId().toString(), 24, TimeUnit.HOURS); return token; } }4.2 線路查詢與換乘推薦線路查詢這塊最基礎(chǔ)的是按線路號(hào)和站點(diǎn)名查詢。但“換乘推薦”是區(qū)分普通項(xiàng)目和優(yōu)質(zhì)項(xiàng)目的重要指標(biāo)。我的實(shí)現(xiàn)思路是先用Dijkstra算法計(jì)算兩站點(diǎn)間的最短路徑以站間距離為權(quán)重然后根據(jù)線路屬性是否換乘站、運(yùn)營時(shí)間段對(duì)路徑做二次篩選優(yōu)先推薦換乘次數(shù)少的方案。算法本身不難難點(diǎn)在于數(shù)據(jù)處理。需要把站點(diǎn)的鄰接關(guān)系提前算好存成一張鄰接表啟動(dòng)時(shí)加載到內(nèi)存。這樣查詢時(shí)就不需要頻繁訪問數(shù)據(jù)庫。我實(shí)際測(cè)試下來整個(gè)地鐵網(wǎng)絡(luò)50個(gè)站左右的最短路計(jì)算耗時(shí)在200毫秒以內(nèi)完全滿足演示需求。路徑結(jié)果封裝成RoutePlanVO包含總站數(shù)、總耗時(shí)、換乘次數(shù)、途經(jīng)站點(diǎn)列表。前端用一個(gè)縱向時(shí)間線組件展示換乘方案直觀又好看答辯演示效果好。4.3 購票下單與訂單狀態(tài)機(jī)下單是整個(gè)系統(tǒng)最核心的方法涉及參數(shù)校驗(yàn)、庫存扣減、訂單生成三個(gè)步驟必須在一個(gè)事務(wù)里完成。先校驗(yàn)車票類型是否存在、線路是否運(yùn)營中、所選數(shù)量是否大于零然后執(zhí)行庫存原子扣減扣減成功后生成訂單訂單狀態(tài)為待支付。這個(gè)流程容易踩的坑是冪等性。用戶可能因?yàn)榫W(wǎng)絡(luò)原因重復(fù)點(diǎn)擊下單按鈕導(dǎo)致產(chǎn)生多張訂單。解決辦法是前端按鈕防抖后端在下單接口增加一個(gè)requestId參數(shù)在Redis里以requestId為key進(jìn)行冪等判斷。第一次請(qǐng)求處理后寫入標(biāo)記后續(xù)相同requestId的請(qǐng)求直接返回已有訂單。事務(wù)實(shí)現(xiàn)參考如下Transactional(rollbackFor Exception.class) public OrderVO createOrder(OrderCreateRequest request) { // 1. 防重校驗(yàn) if (redisTemplate.hasKey(order:req: request.getRequestId())) { throw new BizException(重復(fù)提交); } // 2. 校驗(yàn)線路和票種 // 3. 扣減庫存原子操作 int updated ticketStockMapper.deductStock(request.getTicketTypeId(), request.getQuantity()); if (updated 0) { throw new BizException(余票不足); } // 4. 生成訂單 // 5. 記錄requestId到Redis時(shí)間戳隨機(jī)數(shù)作為訂單號(hào) return vo; }4.4 支付回調(diào)與對(duì)賬處理畢設(shè)里接真實(shí)支付平臺(tái)不現(xiàn)實(shí)但可以用“模擬支付回調(diào)”來模擬完整流程。做法是用戶點(diǎn)擊支付后調(diào)到模擬支付頁面輸入一個(gè)固定密碼如123456系統(tǒng)后端直接觸發(fā)支付成功回調(diào)把訂單狀態(tài)從待支付改成已支付并生成電子車票。回調(diào)處理的關(guān)鍵是冪等?？赡芤?yàn)榫W(wǎng)絡(luò)抖動(dòng)同一筆訂單的回調(diào)會(huì)重復(fù)到達(dá)。我在回調(diào)方法里先查詢訂單狀態(tài)如果已經(jīng)是已支付就直接返回成功不再重復(fù)處理。同時(shí)回調(diào)接口要加簽名校驗(yàn)即使是模擬場(chǎng)景也要體現(xiàn)這個(gè)意識(shí)答辯時(shí)可以主動(dòng)提。生成電子車票后系統(tǒng)會(huì)往用戶端推一條乘車憑證信息包含二維碼字符串用訂單號(hào)加密生成。這個(gè)二維碼可以用Hutool的QrCodeUtil生成掃碼驗(yàn)證的接口做在管理端掃碼后查到訂單信息即視為進(jìn)站成功。這一整套邏輯走下來閉環(huán)感非常強(qiáng)。4.5 我的車票與退票流程“我的車票”頁面邏輯相對(duì)簡單按用戶id分頁查詢訂單列表按創(chuàng)建時(shí)間倒序排列展示車票類型、線路、乘車日期、狀態(tài)等。要區(qū)分未支付訂單和已支付訂單未支付的提供“取消”按鈕已支付的提供“退票”按鈕。退票流程是一個(gè)很好的加分點(diǎn)。設(shè)計(jì)規(guī)則為發(fā)車前2小時(shí)可免費(fèi)退票發(fā)車前2小時(shí)內(nèi)退票收取20%手續(xù)費(fèi)已過發(fā)車時(shí)間不可退票。這個(gè)規(guī)則用定時(shí)任務(wù)或簡單的時(shí)間判斷就能實(shí)現(xiàn)關(guān)鍵是狀態(tài)流轉(zhuǎn)要清晰已支付-退票中-已退款。退票時(shí)要把庫存加回去同時(shí)記錄一條退款流水表refund_record。這個(gè)表記錄退款金額、手續(xù)費(fèi)、原訂單號(hào)保證每一筆退票都有據(jù)可查。別小看退票功能它體現(xiàn)了你對(duì)完整業(yè)務(wù)閉環(huán)的理解很多同學(xué)做到這一步就喊停導(dǎo)致系統(tǒng)缺了一條腿。5. 實(shí)操過程從建項(xiàng)目到調(diào)試通過這一節(jié)記錄我自己實(shí)際搭建項(xiàng)目、寫代碼、部署的全過程包括順序安排和具體操作筆記。5.1 用腳手架初始化工程創(chuàng)建項(xiàng)目直接走Spring Initializr選Java 8、Spring Boot 2.7.x依賴勾選Spring Web、MyBatis、MySQL Driver、Redis、Lombok、Validation。生成后先跑一次空項(xiàng)目確認(rèn)能啟動(dòng)這個(gè)動(dòng)作能提前暴露環(huán)境問題。接下來按包結(jié)構(gòu)建立目錄controller放接口層service放業(yè)務(wù)層mapper放數(shù)據(jù)庫訪問entity放實(shí)體類dto放請(qǐng)求響應(yīng)對(duì)象config放配置類common放統(tǒng)一返回結(jié)果和異常處理。目錄建好后先寫一個(gè)Result統(tǒng)一返回類和GlobalExceptionHandler讓所有接口返回結(jié)構(gòu)一致。這樣后續(xù)寫接口時(shí)只需關(guān)注業(yè)務(wù)邏輯錯(cuò)誤處理統(tǒng)一走異常拋出即可。5.2 分層編碼的落地順序編碼順序建議按數(shù)據(jù)鏈路走先實(shí)體類再M(fèi)apper再Service最后Controller。實(shí)體類用Lombok的Data注解字段和數(shù)據(jù)庫列一一對(duì)應(yīng)。Mapper寫SQL時(shí)注意MyBatis的#{}和${}區(qū)別#{}是預(yù)編譯能防SQL注入動(dòng)態(tài)排序等場(chǎng)景才用到${}且必須做白名單校驗(yàn)。Service是核心層業(yè)務(wù)規(guī)則的校驗(yàn)、事務(wù)管理、狀態(tài)流轉(zhuǎn)都放這里。我總結(jié)的經(jīng)驗(yàn)是每個(gè)Service方法盡量保持單一職責(zé)像“創(chuàng)建訂單”和“支付回調(diào)”不要混在同一個(gè)方法里否則一個(gè)方法變長后事務(wù)邊界很難控制。Controller層只負(fù)責(zé)收參數(shù)、調(diào)Service、返回Result不寫任何業(yè)務(wù)代碼。5.3 接口聯(lián)調(diào)與Mock數(shù)據(jù)前端頁面還沒寫時(shí)先用Postman調(diào)通所有核心接口。建議準(zhǔn)備一份完整的接口文檔用Swagger注解生成每個(gè)接口標(biāo)注請(qǐng)求參數(shù)、返回字段、業(yè)務(wù)說明。這樣前端同學(xué)或者你自己寫前端時(shí)不需要反復(fù)問后端字段含義。Mock數(shù)據(jù)的準(zhǔn)備也很重要。地鐵線路、站點(diǎn)信息我寫了一鍵導(dǎo)入的SQL腳本數(shù)據(jù)量不用很大3條線路、30個(gè)站點(diǎn)、4種車票類型、10個(gè)測(cè)試用戶即可。將站點(diǎn)坐標(biāo)和換乘關(guān)系手寫在SQL里導(dǎo)入后立即能做路徑規(guī)劃測(cè)試。另外準(zhǔn)備一個(gè)DataInitializer類在系統(tǒng)啟動(dòng)時(shí)自動(dòng)檢查數(shù)據(jù)庫是否為空為空則插入基礎(chǔ)測(cè)試數(shù)據(jù)這樣換一臺(tái)電腦運(yùn)行項(xiàng)目時(shí)不用手動(dòng)導(dǎo)數(shù)據(jù)。5.4 部署演示環(huán)境的操作筆記演示環(huán)境部署我建議在本地開發(fā)完成后用Maven打包成jar包在Windows服務(wù)器或虛擬機(jī)Java環(huán)境運(yùn)行。命令行啟動(dòng)方式mvn clean package -DskipTests java -jar target/metro-app.jar --spring.profiles.activeprod在application-prod.yml里配置MySQL和Redis的生產(chǎn)連接信息端口設(shè)成一個(gè)不常用的比如8090避免和本機(jī)其他服務(wù)沖突。前端頁面打包后的靜態(tài)文件可以直接放在Spring Boot的static目錄下這樣只啟動(dòng)一個(gè)服務(wù)就能同時(shí)提供API和頁面訪問演示時(shí)不用同時(shí)開前后端兩個(gè)服務(wù)穩(wěn)定性高不少。6. 常見問題與排查技巧實(shí)錄最后這部分是實(shí)戰(zhàn)排錯(cuò)的經(jīng)驗(yàn)總結(jié)。我整理了幾個(gè)高頻問題每個(gè)都給出現(xiàn)象、排查路徑和解法。6.1 數(shù)據(jù)庫中文亂碼現(xiàn)象接口返回正常但數(shù)據(jù)庫里中文顯示成問號(hào)或亂碼。排查路徑先看MySQL庫和表的字符集再查連接串有沒有加characterEncodingutf8。解決方法建庫時(shí)用CREATE DATABASE metro DEFAULT CHARACTER SET utf8mb4連接串追加characterEncodingutf8useSSLfalse。改完字符集后記得重啟應(yīng)用。這個(gè)坑基本每個(gè)項(xiàng)目都會(huì)遇到提前處理能省很多事。6.2 并發(fā)下單導(dǎo)致超賣現(xiàn)象兩個(gè)人同時(shí)買最后一張票兩個(gè)請(qǐng)求都顯示成功。排查路徑查扣減庫存的SQL是不是先查后改SELECT stock ...再UPDATE stock stock - 1。這種寫法在并發(fā)下一定出問題。解決方法是把SQL改成原子更新UPDATE ticket_stock SET stock stock - 1 WHERE ticket_type_id ? AND stock 0配合Transactional事務(wù)一寫在事務(wù)提交前對(duì)該行加鎖并發(fā)請(qǐng)求會(huì)排隊(duì)。我在壓測(cè)工具里模擬100個(gè)并發(fā)請(qǐng)求下訂單最終庫存扣減正確沒有一條超賣。6.3 Token過期與登錄態(tài)丟失現(xiàn)象接口偶爾報(bào)401必須重新登錄。排查路徑一是Redis的Token過期時(shí)間設(shè)置是否太短二是攔截器校驗(yàn)邏輯是否每次請(qǐng)求都去查Redis如果Redis連接不穩(wěn)也會(huì)拋異常。解決方法Token過期時(shí)間設(shè)置24小時(shí)攔截器里增加一層本地緩存將最近驗(yàn)證過的Token短時(shí)緩存5分鐘減少Redis訪問次數(shù)。注意本地緩存只存token - userId的映射不會(huì)泄露敏感信息。6.4 支付回調(diào)重復(fù)通知現(xiàn)象一張訂單結(jié)算時(shí)出現(xiàn)兩張電子車票。排查路徑回調(diào)接口沒有做冪等判斷。解決方法回調(diào)處理第一步先調(diào)用selectByOrderNo查詢訂單狀態(tài)只有待支付狀態(tài)才往下執(zhí)行其他狀態(tài)直接返回成功。加一個(gè)訂單號(hào)的唯一索引兜底即使并發(fā)重復(fù)回調(diào)數(shù)據(jù)庫層面也會(huì)拒絕第二條更新保證數(shù)據(jù)不出錯(cuò)。6.5 換乘算法超時(shí)或結(jié)果異?，F(xiàn)象測(cè)試換乘查詢時(shí)個(gè)別起終點(diǎn)返回空結(jié)果。排查路徑第一步檢查線路站點(diǎn)鄰接數(shù)據(jù)是否完整特別是換乘站是否同時(shí)關(guān)聯(lián)了兩條線路的站點(diǎn)記錄第二步查看算法初始化時(shí)是否把起始站和終點(diǎn)站的id傳錯(cuò)。我的經(jīng)驗(yàn)是寫一個(gè)小的單元測(cè)試輸入固定的起終點(diǎn)預(yù)期返回固定路徑用斷言校驗(yàn)結(jié)果這樣能快速定位算法邏輯問題。6.6 常見問題速查表問題大概率原因快速解法啟動(dòng)報(bào)端口被占用8090被其他進(jìn)程占用換端口或netstat -ano找PID釋放Redis連接超時(shí)Redis沒啟動(dòng)或密碼不對(duì)啟動(dòng)服務(wù)檢查配置里的密碼MyBatis映射字段為空實(shí)體類屬性與列名不一致開啟map-underscore-to-camel-case前端接口跨域前后端分離部署后端加CrossOrigin或全局跨域配置圖片驗(yàn)證碼不顯示前端沒拿到圖片流返回Base64字符串前端data:image/png;base64,拼接按照這套方案走下來一個(gè)能完整演示、邏輯閉環(huán)、代碼規(guī)范的地鐵購票App基本就成型了。整個(gè)開發(fā)過程中我個(gè)人最大的體會(huì)是畢業(yè)設(shè)計(jì)最怕的不是技術(shù)難而是怕目標(biāo)模糊、模塊散亂。先把業(yè)務(wù)鏈路想清楚再把數(shù)據(jù)模型設(shè)計(jì)好編碼就是按圖索驥的體力活。至于答辯只要代碼里每一個(gè)關(guān)鍵環(huán)節(jié)都說得清“為什么這樣設(shè)計(jì)”評(píng)委問什么都能接得住。如果后續(xù)想擴(kuò)展可以在現(xiàn)有基礎(chǔ)上加入地圖選站、支付接入真實(shí)沙箱環(huán)境、后臺(tái)數(shù)據(jù)分析面板、用戶積分體系每加一塊都是獨(dú)立的加分點(diǎn)。