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