：SSM框架練手項(xiàng)目的經(jīng)典之選)
校園卡系統(tǒng)SSM練手的經(jīng)典之作Java后端項(xiàng)目做了好幾年回頭看學(xué)生校園卡管理系統(tǒng)這類帶業(yè)務(wù)閉環(huán)的項(xiàng)目反而是我見過最“耐打”的練手載體。它不像電商系統(tǒng)那樣堆砌概念也不像純CRUD管理后臺(tái)那樣平淡而是把充值、消費(fèi)、掛失、注銷這些真實(shí)場(chǎng)景串成了一條完整業(yè)務(wù)鏈。這個(gè)系統(tǒng)用Java SSM框架實(shí)現(xiàn)Spring負(fù)責(zé)對(duì)象管理和事務(wù)SpringMVC處理請(qǐng)求分發(fā)MyBatis管數(shù)據(jù)持久化。功能上圍繞校園卡生命周期展開辦卡、充值、刷卡消費(fèi)、掛失、解掛、注銷外加用戶管理和消費(fèi)記錄查詢。對(duì)于一個(gè)學(xué)過Java基礎(chǔ)、想搞懂SSM整合的人來說這套代碼能把框架知識(shí)、業(yè)務(wù)設(shè)計(jì)、數(shù)據(jù)庫建模、前端交互一次性串起來。如果你正準(zhǔn)備畢業(yè)設(shè)計(jì)、求職面試或者剛學(xué)完SSM想找一個(gè)能完整跑通的項(xiàng)目這篇文章會(huì)把整個(gè)系統(tǒng)的設(shè)計(jì)思路、核心實(shí)現(xiàn)、部署運(yùn)行和常見坑都拆開講清楚。我不會(huì)只貼代碼而是把“為什么這么做”也講透。1. 這個(gè)項(xiàng)目的價(jià)值與定位校園卡系統(tǒng)到底在練什么1.1 項(xiàng)目背景與實(shí)際需求校園卡是高校里每天都在用的真實(shí)場(chǎng)景。學(xué)生拿一張卡在食堂刷卡、在超市消費(fèi)、在機(jī)房上機(jī)卡里沒錢了就充值卡丟了就掛失畢業(yè)了就注銷。這些操作看似簡單落到系統(tǒng)設(shè)計(jì)里就變成了賬戶管理、余額變更、狀態(tài)流轉(zhuǎn)、操作日志等技術(shù)問題。這個(gè)項(xiàng)目的核心需求其實(shí)非常明確學(xué)生信息維護(hù)學(xué)號(hào)、姓名、院系、聯(lián)系方式等基礎(chǔ)信息。校園卡賬戶一張卡對(duì)應(yīng)一個(gè)賬戶賬戶里有余額有狀態(tài)正常/掛失/注銷。充值功能學(xué)生給卡里充錢余額增加生成充值流水。消費(fèi)功能刷卡扣款余額減少生成消費(fèi)流水。掛失與解掛卡丟了先掛失凍結(jié)消費(fèi)功能找到后解掛恢復(fù)。注銷功能卡不再使用賬戶銷戶余額清零或退費(fèi)。管理員后臺(tái)管理員登錄、查詢所有記錄、統(tǒng)計(jì)報(bào)表。你看這個(gè)業(yè)務(wù)模型并不會(huì)太復(fù)雜但覆蓋面非常全。對(duì)一個(gè)SSM階段的學(xué)習(xí)者來說它既不會(huì)像ERP那樣讓代碼量失控又足夠撐起一個(gè)完整的Web項(xiàng)目。這是它作為畢業(yè)設(shè)計(jì)和練手項(xiàng)目經(jīng)久不衰的原因。1.2 適用人群與三種使用場(chǎng)景我先說結(jié)論這個(gè)系統(tǒng)適合三類人。第一類是準(zhǔn)備畢業(yè)設(shè)計(jì)的在校生。SSM框架時(shí)至今日依然是很多高校畢設(shè)選題的主流技術(shù)棧一個(gè)業(yè)務(wù)清晰、代碼規(guī)范、附帶文檔和運(yùn)行視頻的項(xiàng)目能讓答辯環(huán)節(jié)省下大量精力。特別是老師問“卡掛失了還能消費(fèi)嗎”“注銷后余額怎么處理”這類業(yè)務(wù)問題你如果親手做過回答起來完全是另一個(gè)狀態(tài)。第二類是準(zhǔn)備Java后端面試的求職者。很多人手里沒有能拿得出手的項(xiàng)目面試官問“你項(xiàng)目里遇到過什么問題”答不上來。校園卡系統(tǒng)的并發(fā)扣款、事務(wù)管理、狀態(tài)流轉(zhuǎn)設(shè)計(jì)都是面試官感興趣的切入點(diǎn)完全可以把項(xiàng)目經(jīng)驗(yàn)和Java八股文結(jié)合起來講。第三類是剛學(xué)完SSM框架的基礎(chǔ)學(xué)習(xí)者?？蚣軐W(xué)完了但不知道怎么整合三個(gè)框架各管什么配置文件怎么寫前端請(qǐng)求怎么到后端這個(gè)項(xiàng)目能回答這些問題。我見過不少同學(xué)把教程里的demo抄了一遍但遇到“注冊(cè)功能怎么和登錄功能共用一套用戶體系”這種問題就卡住。而校園卡系統(tǒng)天然包含了多角色、多狀態(tài)、多流水做一遍框架的整合能力、事務(wù)控制能力、分層設(shè)計(jì)能力都會(huì)有一個(gè)真實(shí)的提升。2. 核心業(yè)務(wù)與數(shù)據(jù)庫設(shè)計(jì)把狀態(tài)流轉(zhuǎn)想清楚再做2.1 五大功能模塊的邊界劃分系統(tǒng)雖然叫“校園卡管理系統(tǒng)”但模塊邊界一定要清楚。我在設(shè)計(jì)時(shí)把功能拆成了五個(gè)核心模塊加上一個(gè)系統(tǒng)登錄模塊一共六個(gè)用戶模塊學(xué)生信息新增、修改、查詢、刪除對(duì)應(yīng)校園卡的開卡。賬戶模塊每個(gè)用戶對(duì)應(yīng)一個(gè)卡賬戶管理余額和狀態(tài)。充值模塊學(xué)生充值更新余額寫入充值流水。消費(fèi)模塊刷卡消費(fèi)扣減余額寫入消費(fèi)流水。掛失/注銷模塊更改賬戶狀態(tài)掛失后禁止消費(fèi)注銷后賬戶失效。系統(tǒng)管理模塊管理員登錄、退出、密碼修改。模塊劃分的意義在于業(yè)務(wù)之間通過賬戶狀態(tài)和余額解耦而不是把邏輯堆在一個(gè)類里。比如掛失操作只更新賬戶狀態(tài)字段而消費(fèi)功能在扣款前檢查狀態(tài)。這樣各模塊獨(dú)立出了問題也好排查。2.2 數(shù)據(jù)庫表設(shè)計(jì)與字段說明數(shù)據(jù)庫設(shè)計(jì)是這個(gè)項(xiàng)目的地基。我當(dāng)時(shí)設(shè)計(jì)了5張表不多不少剛好覆蓋業(yè)務(wù)又沒有冗余student學(xué)生表 - id int 主鍵自增 - student_no varchar(20) 學(xué)號(hào)唯一索引 - name varchar(50) 姓名 - gender varchar(10) 性別 - department varchar(50) 院系 - phone varchar(20) 聯(lián)系方式 - create_time datetime 創(chuàng)建時(shí)間 card_account卡賬戶表 - id int 主鍵自增 - student_id int 關(guān)聯(lián)學(xué)生表 - card_no varchar(20) 卡號(hào)唯一索引 - balance decimal(10,2) 余額 - status tinyint 賬戶狀態(tài)0正常 1掛失 2注銷 - create_time datetime 開卡時(shí)間 - lose_time datetime 掛失時(shí)間 - cancel_time datetime 注銷時(shí)間 recharge_record充值記錄表 - id int 主鍵自增 - card_id int 關(guān)聯(lián)賬戶表 - amount decimal(10,2) 充值金額 - create_time datetime 充值時(shí)間 - operator varchar(20) 操作人管理員或自助 consume_record消費(fèi)記錄表 - id int 主鍵自增 - card_id int 關(guān)聯(lián)賬戶表 - amount decimal(10,2) 消費(fèi)金額 - shop_name varchar(50) 消費(fèi)地點(diǎn) - create_time datetime 消費(fèi)時(shí)間 admin_user管理員表 - id int 主鍵自增 - username varchar(50) 用戶名 唯一 - password varchar(100) 密碼 - real_name varchar(50) 姓名這里有個(gè)關(guān)鍵設(shè)計(jì)余額一定要放在賬戶表里而不是每次通過流水匯總。雖然通過“充值總和 - 消費(fèi)總和”也能算出余額但那樣每次查詢都要掃流水表數(shù)據(jù)量大了性能會(huì)很差。實(shí)戰(zhàn)項(xiàng)目里余額字段直接冗余在賬戶表流水只做記錄和對(duì)賬這個(gè)思路在很多金融系統(tǒng)里也是這么干的。2.3 充值、消費(fèi)、掛失、注銷的狀態(tài)流轉(zhuǎn)狀態(tài)是這類系統(tǒng)的靈魂。我見過很多初學(xué)者直接把狀態(tài)寫死在代碼里比如if (status 1) 就不能消費(fèi)完全沒有狀態(tài)機(jī)的概念。實(shí)際上校園卡的狀態(tài)流轉(zhuǎn)是這樣的正常狀態(tài)可以充值、可以消費(fèi)、可以掛失、可以注銷。掛失狀態(tài)不能消費(fèi)、不能注銷可以解掛恢復(fù)為正常凍結(jié)余額但不能清零。注銷狀態(tài)終態(tài)所有操作都拒絕。為什么要區(qū)分掛失和注銷因?yàn)閽焓桥R時(shí)性的找到卡還能恢復(fù)注銷是終態(tài)卡作廢。如果把掛失做成刪除賬戶那卡找到了就麻煩了。一個(gè)狀態(tài)字段加狀態(tài)校驗(yàn)就能覆蓋這些場(chǎng)景這也是面試官喜歡問的點(diǎn)。這個(gè)狀態(tài)機(jī)模型雖然簡單但背后的思想是“任何操作前先校驗(yàn)狀態(tài)合法性”和很多電商系統(tǒng)的訂單狀態(tài)機(jī)是同一套邏輯。在代碼里我用一個(gè)狀態(tài)常量類來管理避免魔法數(shù)字散落各處。3. SSM框架整合與實(shí)現(xiàn)要點(diǎn)三個(gè)框架各干各的活3.1 Spring SpringMVC MyBatis 分層思路SSM框架組合是經(jīng)典的“三層架構(gòu)”落地方式Spring負(fù)責(zé)對(duì)象管理IoC和事務(wù)管理AOP。Service層的實(shí)例不用自己new由Spring容器統(tǒng)一創(chuàng)建和管理數(shù)據(jù)庫事務(wù)通過Transactional聲明式配置一個(gè)方法就是一個(gè)事務(wù)單元。SpringMVC負(fù)責(zé)Web層的請(qǐng)求路由。前端發(fā)來的URL請(qǐng)求經(jīng)過DispatcherServlet分發(fā)到對(duì)應(yīng)的Controller方法Controller接收參數(shù)、調(diào)用Service、返回JSON或頁面。MyBatis負(fù)責(zé)數(shù)據(jù)持久化。Mapper接口定義方法XML或注解寫SQL把結(jié)果集映射成Java對(duì)象。實(shí)際分層的時(shí)候我按“Controller - Service - Mapper”拆。Controller層只做參數(shù)接收和結(jié)果返回不寫業(yè)務(wù)代碼Service層做業(yè)務(wù)邏輯和事務(wù)控制Mapper層只做SQL操作。這樣每一層都職責(zé)單一也方便后續(xù)維護(hù)。有個(gè)新手常犯的錯(cuò)誤在Controller里直接操作多個(gè)Mapper把業(yè)務(wù)邏輯堆在控制器里。這樣寫確實(shí)能跑但事務(wù)很難控制——如果兩個(gè)Mapper操作中間拋異常數(shù)據(jù)就處于不一致狀態(tài)。正確的做法是把業(yè)務(wù)邏輯封裝到Service方法里加上Transactional一個(gè)方法要么全成功要么全回滾。3.2 關(guān)鍵配置與依賴選型SSM整合的配置文件是初學(xué)者最頭疼的部分。我用的技術(shù)版本是Java 8、Maven 3.6、Spring 5.x、SpringMVC 5.x、MyBatis 3.5.x。這套組合非常穩(wěn)定教程也多出問題容易查。Maven依賴核心就幾個(gè)spring-context、spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid連接池、jackson-databind用于JSON轉(zhuǎn)換。另外還需要servlet-api和jsp-api但這兩個(gè)要加provided作用域否則會(huì)和Tomcat自帶的沖突。配置上我分成了三個(gè)核心配置文件spring-context.xml配置數(shù)據(jù)源、SqlSessionFactory、Mapper掃描、Service掃描、事務(wù)管理器。spring-mvc.xml配置注解驅(qū)動(dòng)、Controller掃描、視圖解析器、靜態(tài)資源映射。web.xml配置DispatcherServlet和Spring的ContextLoaderListener。這里說一下容易被忽略的細(xì)節(jié)Spring配置和SpringMVC配置要分清父子容器關(guān)系。Spring容器管理Service和MapperSpringMVC容器管理Controller。如果在spring-mvc.xml里掃描了Service類事務(wù)會(huì)失效。我自己就踩過這個(gè)坑后來統(tǒng)一用“spring-context.xml只掃Service和Mapperspring-mvc.xml只掃Controller”的約定問題再?zèng)]出現(xiàn)過。3.3 前端交互與接口設(shè)計(jì)思路這個(gè)項(xiàng)目的前端我用了JSP Bootstrap AJAX。JSP做頁面模板Bootstrap做樣式AJAX和JSON做前后端數(shù)據(jù)交互。雖然現(xiàn)在前端框架Vue很流行但SSM項(xiàng)目搭配JSP是最常見的組合重點(diǎn)是把接口設(shè)計(jì)清楚。項(xiàng)目的接口按REST風(fēng)格設(shè)計(jì)比如POST /card/recharge充值參數(shù)為卡號(hào)和金額。POST /card/consume消費(fèi)參數(shù)為卡號(hào)和金額。POST /card/loss掛失參數(shù)為卡號(hào)。POST /card/restore解掛參數(shù)為卡號(hào)。POST /card/cancel注銷參數(shù)為卡號(hào)。GET /record/list查詢流水支持分頁。所有的接口統(tǒng)一返回JSON格式結(jié)構(gòu)是這樣{ code: 200, msg: 操作成功, data: { balance: 98.50 } }前端根據(jù)code判斷成功失敗有數(shù)據(jù)就渲染data。這種前后端通過JSON交互的方式現(xiàn)在依然是主流做法而且就算以后你想用Vue3重新寫前端后端接口完全不用改只要做跨域配置就行。熱搜里提到“vue3連接ssm框架”其實(shí)原理就是這么簡單后端不動(dòng)把前端換成Vue用axios調(diào)接口。4. 核心功能代碼實(shí)現(xiàn)復(fù)盤把關(guān)鍵場(chǎng)景寫明白4.1 充值功能的業(yè)務(wù)邏輯與冪等處理充值邏輯看起來就是“余額加錢、記流水”兩步但實(shí)際實(shí)現(xiàn)有講究。我先說最核心的Service代碼Service public class CardServiceImpl implements CardService { Autowired private CardAccountMapper cardAccountMapper; Autowired private RechargeRecordMapper rechargeRecordMapper; Override Transactional(rollbackFor Exception.class) public Result recharge(String cardNo, BigDecimal amount) { // 1. 校驗(yàn)參數(shù) if (amount null || amount.compareTo(BigDecimal.ZERO) 0) { return Result.error(充值金額必須大于0); } // 2. 查詢賬戶 CardAccount account cardAccountMapper.findByCardNo(cardNo); if (account null) { return Result.error(卡號(hào)不存在); } if (account.getStatus() ! CardStatus.NORMAL) { return Result.error(賬戶狀態(tài)異常無法充值); } // 3. 更新余額 int rows cardAccountMapper.increaseBalance(cardNo, amount); if (rows 0) { throw new RuntimeException(充值失敗); } // 4. 插入流水 RechargeRecord record new RechargeRecord(); record.setCardId(account.getId()); record.setAmount(amount); rechargeRecordMapper.insert(record); return Result.success(充值成功, getBalance(cardNo)); } }這段代碼有幾個(gè)地方值得新手注意。第一金額用BigDecimal而不是double。這是金融相關(guān)業(yè)務(wù)的鐵律。double在加減時(shí)會(huì)丟失精度0.1 0.2可能等于0.30000000000000004這在余額計(jì)算里不可接受。BigDecimal按照實(shí)際金額精度計(jì)算配合數(shù)據(jù)庫的decimal(10,2)金額計(jì)算才靠譜。第二先更新余額再插入流水并且包裹在同一個(gè)事務(wù)里。如果流水插入失敗余額更新也會(huì)回滾。我在初始化項(xiàng)目時(shí)專門測(cè)試過手動(dòng)在插入流水處拋一個(gè)異常充值事務(wù)整體回滾余額不變。這個(gè)驗(yàn)證過程我建議你也做一遍能直觀理解Transactional的作用。第三冪等性問題。如果用戶點(diǎn)了兩次充值按鈕請(qǐng)求重復(fù)提交會(huì)不會(huì)充兩次這個(gè)系統(tǒng)用了最簡單的前端防重復(fù)提交按鈕置灰但后端更嚴(yán)謹(jǐn)?shù)淖龇ㄊ羌右粋€(gè)業(yè)務(wù)訂單號(hào)記錄到單獨(dú)的流水表通過唯一索引約束同一個(gè)訂單號(hào)只能成功一次。面試被問到“怎么防止重復(fù)支付”時(shí)這是一個(gè)很好的延伸點(diǎn)。4.2 消費(fèi)扣款與余額校驗(yàn)的代碼細(xì)節(jié)消費(fèi)是另一個(gè)核心操作邏輯上有“先查后扣”和“直接扣”兩種寫法。先看一種更穩(wěn)妥的做法Override Transactional(rollbackFor Exception.class) public Result consume(String cardNo, BigDecimal amount, String shopName) { // 1. 校驗(yàn)金額 if (amount null || amount.compareTo(BigDecimal.ZERO) 0) { return Result.error(消費(fèi)金額必須大于0); } // 2. 查詢賬戶并校驗(yàn)狀態(tài) CardAccount account cardAccountMapper.findByCardNo(cardNo); if (account null) { return Result.error(卡號(hào)不存在); } if (account.getStatus() ! CardStatus.NORMAL) { return Result.error(當(dāng)前狀態(tài)不可消費(fèi)); } // 3. 校驗(yàn)余額 if (account.getBalance().compareTo(amount) 0) { return Result.error(余額不足); } // 4. 扣減余額 int rows cardAccountMapper.decreaseBalance(cardNo, amount); if (rows 0) { throw new RuntimeException(扣款失敗); } // 5. 插入消費(fèi)流水 ConsumeRecord record new ConsumeRecord(); record.setCardId(account.getId()); record.setAmount(amount); record.setShopName(shopName); consumeRecordMapper.insert(record); return Result.success(消費(fèi)成功, getBalance(cardNo)); }這里有一個(gè)面試高頻問題“先查詢余額再扣款”在高并發(fā)下會(huì)不會(huì)有問題答案是會(huì)。假設(shè)兩個(gè)請(qǐng)求同時(shí)讀到余額是10元兩個(gè)都扣8元各自判斷余額夠最后余額變成2元但實(shí)際上兩筆消費(fèi)共扣16元超扣了。解決方案有兩種一是用數(shù)據(jù)庫行鎖SELECT ... FOR UPDATE把賬戶行鎖住串行處理二是用樂觀鎖更新的時(shí)候加條件where balance amount。MyBatis的decreaseBalanceSQL可以寫成UPDATE card_account SET balance balance - #{amount} WHERE card_no #{cardNo} AND balance #{amount}這樣數(shù)據(jù)庫層面就保證了余額夠才能扣成功如果返回影響行數(shù)為0說明余額不足或卡號(hào)不存在。數(shù)據(jù)庫的原子操作比Java代碼里的“先查后改”可靠得多這也是一個(gè)很好的面試談資。在日常單機(jī)學(xué)習(xí)環(huán)境里很多同學(xué)察覺不到這個(gè)差異但在用戶量稍大的場(chǎng)景這是一個(gè)非常關(guān)鍵的正確性設(shè)計(jì)。4.3 掛失、注銷的狀態(tài)機(jī)管理代碼掛失和注銷放在一起講因?yàn)樗鼈兊谋举|(zhì)都是改狀態(tài)。區(qū)別在于掛失之后可以解掛注銷是終態(tài)。我在CardStatus類里定義了狀態(tài)常量public class CardStatus { public static final int NORMAL 0; // 正常 public static final int LOSS 1; // 掛失 public static final int CANCEL 2; // 注銷 }掛失的Service邏輯Override Transactional(rollbackFor Exception.class) public Result loss(String cardNo) { CardAccount account cardAccountMapper.findByCardNo(cardNo); if (account null) { return Result.error(卡號(hào)不存在); } if (account.getStatus() ! CardStatus.NORMAL) { return Result.error(只有正常狀態(tài)的卡才能掛失); } account.setStatus(CardStatus.LOSS); account.setLoseTime(new Date()); cardAccountMapper.updateStatus(account); return Result.success(掛失成功); }對(duì)應(yīng)的消費(fèi)方法里已經(jīng)校驗(yàn)了status ! NORMAL就拒絕所以掛失一生效消費(fèi)功能立刻失效。解掛就是把狀態(tài)改回NORMAL同時(shí)清空掛失時(shí)間。注銷的邏輯也是類似但要把狀態(tài)改成CANCEL而且注銷前最好校驗(yàn)余額為0避免資金遺留問題。你可以把這個(gè)“注銷前余額檢查”作為擴(kuò)展點(diǎn)在項(xiàng)目里加上余額清零或退費(fèi)的功能。我特別想強(qiáng)調(diào)一點(diǎn)狀態(tài)機(jī)的核心不是怎么寫代碼而是怎么設(shè)計(jì)狀態(tài)和操作之間的約束關(guān)系。這個(gè)項(xiàng)目里用的“狀態(tài)先校驗(yàn)操作后流轉(zhuǎn)”模式在真實(shí)的交易系統(tǒng)、審批系統(tǒng)里非常常見。把這三行狀態(tài)判斷吃透比背十道面試題更有用。4.4 登錄與權(quán)限攔截的核心寫法系統(tǒng)有一個(gè)管理員登錄功能。登錄校驗(yàn)通過后把用戶信息存到Session里。為了防止未登錄用戶直接訪問后臺(tái)接口我加了一個(gè)SpringMVC的攔截器public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user request.getSession().getAttribute(adminUser); if (user null) { // 判斷是否AJAX請(qǐng)求返回不同結(jié)果 response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:401,\msg\:\未登錄或登錄已過期\}); return false; } return true; } }然后在spring-mvc.xml里注冊(cè)攔截器配置不攔截登錄接口和靜態(tài)資源mvc:interceptors mvc:interceptor mvc:mapping path/**/ mvc:exclude-mapping path/admin/login/ mvc:exclude-mapping path/static/**/ bean classcom.campus.interceptor.LoginInterceptor/ /mvc:interceptor /mvc:interceptors這個(gè)攔截器是SSM項(xiàng)目權(quán)限控制的經(jīng)典寫法。攔截器只負(fù)責(zé)“是否登錄”什么時(shí)候用戶能做什么操作交給Service層的狀態(tài)校驗(yàn)去做。把這兩個(gè)層面分開邏輯才清晰。關(guān)于密碼存儲(chǔ)項(xiàng)目里用了MD5加密。但真實(shí)系統(tǒng)中密碼加密建議用BCrypt這類帶鹽的算法MD5已經(jīng)不夠安全。你可以把這個(gè)作為項(xiàng)目優(yōu)化點(diǎn)提出來在面試?yán)飼?huì)加分。5. 部署運(yùn)行關(guān)鍵操作與常見問題排查5.1 環(huán)境準(zhǔn)備與部署全流程把這個(gè)系統(tǒng)跑起來你需要準(zhǔn)備的東西不多JDK 1.8Maven 3.6Tomcat 8.5或9.0MySQL 5.7或8.0IDEA開發(fā)工具部署步驟我整理成了一段流程每一步都很關(guān)鍵創(chuàng)建數(shù)據(jù)庫campus_card執(zhí)行項(xiàng)目里的init.sql初始化腳本腳本會(huì)建表并插入一條測(cè)試管理員賬號(hào)和幾條學(xué)生數(shù)據(jù)。修改jdbc.properties里的數(shù)據(jù)庫連接信息重點(diǎn)是用戶名、密碼、URL里的serverTimezoneAsia/Shanghai。用IDEA打開Maven項(xiàng)目等待依賴下載完成。如果網(wǎng)絡(luò)不好可以在settings.xml里配置阿里云鏡像。配置Tomcat把項(xiàng)目部署到Tomcat點(diǎn)擊啟動(dòng)。瀏覽器訪問http://localhost:8080/項(xiàng)目名/用管理員賬號(hào)登錄。很多新手在第五步前就卡住了大多數(shù)情況是數(shù)據(jù)庫連不上或者依賴沒下來。先單獨(dú)寫好數(shù)據(jù)庫連接測(cè)試再啟動(dòng)項(xiàng)目能幫你快速定位問題。5.2 常見問題排查速查表我把自己跑項(xiàng)目時(shí)遇到頻率最高的問題整理成了表你可以直接照這個(gè)排查現(xiàn)象原因解決辦法Tomcat啟動(dòng)報(bào)ClassNotFoundExceptionMaven依賴沒下載完整檢查settings.xml鏡像配置mvn clean后重新導(dǎo)入項(xiàng)目啟動(dòng)時(shí)提示Port 8080 was already in use端口被占用換端口或netstat -ano頁面中文亂碼編碼不一致JSP頁面、數(shù)據(jù)庫連接URL、Tomcat編碼統(tǒng)一為UTF-8數(shù)據(jù)庫連接失敗Access denied用戶名密碼或權(quán)限問題檢查賬號(hào)密碼GRANT ALL ON campus_card.* TO rootlocalhost登錄后頁面報(bào)404攔截器攔截了靜態(tài)資源或路徑不對(duì)檢查攔截器exclude配置檢查請(qǐng)求路徑運(yùn)行時(shí)報(bào)OutOfMemoryError: insufficient memoryJVM啟動(dòng)內(nèi)存不足在IDEA的VM options里加-Xms256m -Xmx512m查詢結(jié)果返回null但數(shù)據(jù)庫有數(shù)據(jù)字段映射不正確開啟MyBatis駝峰映射mapUnderscoreToCamelCasetrue最后一條我多說一句。Java實(shí)體類的屬性命名一般是駝峰式比如studentNo數(shù)據(jù)庫字段是下劃線式student_noMyBatis默認(rèn)不會(huì)自動(dòng)映射需要在application.properties或mybatis-config.xml里開啟駝峰映射。不開啟的話查出來的數(shù)據(jù)對(duì)象就是一個(gè)個(gè)null字段這是SSM項(xiàng)目里經(jīng)典到不能再經(jīng)典的坑。5.3 如何把項(xiàng)目講給面試官聽很多人項(xiàng)目做完了但面試被問幾句就露怯。校園卡系統(tǒng)雖然不大但只要講出“設(shè)計(jì)感”依然很有說服力。我的建議是順著三條線準(zhǔn)備一是事務(wù)控制線。充值、消費(fèi)為什么加TransactionalSpring的事務(wù)傳播行為有哪幾種默認(rèn)的REQUIRED是什么意思一個(gè)Service方法調(diào)另一個(gè)Service方法事務(wù)會(huì)合并嗎這些八股文知識(shí)點(diǎn)放在這個(gè)項(xiàng)目場(chǎng)景里講比干背效果好得多。二是并發(fā)安全線。兩個(gè)請(qǐng)求同時(shí)消費(fèi)怎么辦怎么用數(shù)據(jù)庫的行鎖或樂觀鎖保證不超扣MySQL默認(rèn)隔離級(jí)別是什么SELECT ... FOR UPDATE會(huì)鎖行嗎這些問題的答案在代碼里都有對(duì)應(yīng)位置面試官問起來你可以直接說“我在這段消費(fèi)邏輯里是怎么處理的”。三是狀態(tài)設(shè)計(jì)線。為什么掛失和注銷分開狀態(tài)放在數(shù)據(jù)庫里是什么類型如果以后要擴(kuò)展“凍結(jié)狀態(tài)”怎么辦回答的時(shí)候把狀態(tài)機(jī)的思路講出來面試官就知道你不是只會(huì)CRUD的。另外熱搜詞里的java面試八股文、HashMap底層、冒泡排序這些是面試?？嫉幕A(chǔ)題。但項(xiàng)目經(jīng)驗(yàn)存在的意義不是代替這些基礎(chǔ)題而是讓你在回答完基礎(chǔ)題之后能拿出一個(gè)具體的場(chǎng)景證明“我會(huì)用”。把這個(gè)校園卡系統(tǒng)的每條業(yè)務(wù)邏輯吃透比背一百道題有用。5.4 版本與擴(kuò)展方向如果你用的是Java 11以上或Spring Boot搭建方式會(huì)有一些差異。SSM畢竟是手動(dòng)整合三個(gè)框架配置較多而Spring Boot把很多配置都自動(dòng)完成了。但我的看法是練習(xí)階段建議先用SSM手動(dòng)搭一遍這樣才能理解Spring Boot幫我們省掉了什么。等你把SSM的配置流程走順了再切Spring Boot會(huì)非?？臁ｍ?xiàng)目本身也可以擴(kuò)展。熱搜詞里提到Vue3你可以用Vue3 Element Plus重寫前端頁面把JSP替換成前后端分離架構(gòu)后端只要加一個(gè)CORS跨域配置即可。也可以把“注銷”擴(kuò)展成完整的“退費(fèi)流程”把“消費(fèi)”擴(kuò)展成“支持不同商戶類型”。這些擴(kuò)展在文檔和答辯視頻里都是亮點(diǎn)。最后再分享一個(gè)小細(xì)節(jié)整個(gè)項(xiàng)目里我最滿意的是那張流水表的設(shè)計(jì)。剛開始我也覺得充值記錄和消費(fèi)記錄建一張表就夠了后來想了想還是拆開了。因?yàn)槌渲涤涗涥P(guān)注的是“誰給我充了多少錢”消費(fèi)記錄關(guān)注的是“我在哪花了多少錢”兩個(gè)查詢維度完全不同拆開后統(tǒng)計(jì)和分頁都輕松。這個(gè)簡單的表設(shè)計(jì)決策后來在寫對(duì)賬功能的時(shí)候幫了大忙。如果你也在做校園卡系統(tǒng)或者準(zhǔn)備做類似的SSM練手項(xiàng)目記住一個(gè)原則先把狀態(tài)和余額的流轉(zhuǎn)畫出來再動(dòng)手寫代碼。業(yè)務(wù)跑通了剩下的都是細(xì)節(jié)。踩過幾次坑之后你會(huì)發(fā)現(xiàn)這個(gè)項(xiàng)目帶給你最大的收獲不是那些代碼而是對(duì)“一個(gè)完整系統(tǒng)是怎么運(yùn)轉(zhuǎn)的”這件事的理解。 校園卡系統(tǒng)：SSM框架練手項(xiàng)目的經(jīng)典之選
校園卡系統(tǒng)SSM練手的經(jīng)典之作Java后端項(xiàng)目做了好幾年回頭看學(xué)生校園卡管理系統(tǒng)這類帶業(yè)務(wù)閉環(huán)的項(xiàng)目反而是我見過最“耐打”的練手載體。它不像電商系統(tǒng)那樣堆砌概念也不像純CRUD管理后臺(tái)那樣平淡而是把充值、消費(fèi)、掛失、注銷這些真實(shí)場(chǎng)景串成了一條完整業(yè)務(wù)鏈。這個(gè)系統(tǒng)用Java SSM框架實(shí)現(xiàn)Spring負(fù)責(zé)對(duì)象管理和事務(wù)SpringMVC處理請(qǐng)求分發(fā)MyBatis管數(shù)據(jù)持久化。功能上圍繞校園卡生命周期展開辦卡、充值、刷卡消費(fèi)、掛失、解掛、注銷外加用戶管理和消費(fèi)記錄查詢。對(duì)于一個(gè)學(xué)過Java基礎(chǔ)、想搞懂SSM整合的人來說這套代碼能把框架知識(shí)、業(yè)務(wù)設(shè)計(jì)、數(shù)據(jù)庫建模、前端交互一次性串起來。如果你正準(zhǔn)備畢業(yè)設(shè)計(jì)、求職面試或者剛學(xué)完SSM想找一個(gè)能完整跑通的項(xiàng)目這篇文章會(huì)把整個(gè)系統(tǒng)的設(shè)計(jì)思路、核心實(shí)現(xiàn)、部署運(yùn)行和常見坑都拆開講清楚。我不會(huì)只貼代碼而是把“為什么這么做”也講透。1. 這個(gè)項(xiàng)目的價(jià)值與定位校園卡系統(tǒng)到底在練什么1.1 項(xiàng)目背景與實(shí)際需求校園卡是高校里每天都在用的真實(shí)場(chǎng)景。學(xué)生拿一張卡在食堂刷卡、在超市消費(fèi)、在機(jī)房上機(jī)卡里沒錢了就充值卡丟了就掛失畢業(yè)了就注銷。這些操作看似簡單落到系統(tǒng)設(shè)計(jì)里就變成了賬戶管理、余額變更、狀態(tài)流轉(zhuǎn)、操作日志等技術(shù)問題。這個(gè)項(xiàng)目的核心需求其實(shí)非常明確學(xué)生信息維護(hù)學(xué)號(hào)、姓名、院系、聯(lián)系方式等基礎(chǔ)信息。校園卡賬戶一張卡對(duì)應(yīng)一個(gè)賬戶賬戶里有余額有狀態(tài)正常/掛失/注銷。充值功能學(xué)生給卡里充錢余額增加生成充值流水。消費(fèi)功能刷卡扣款余額減少生成消費(fèi)流水。掛失與解掛卡丟了先掛失凍結(jié)消費(fèi)功能找到后解掛恢復(fù)。注銷功能卡不再使用賬戶銷戶余額清零或退費(fèi)。管理員后臺(tái)管理員登錄、查詢所有記錄、統(tǒng)計(jì)報(bào)表。你看這個(gè)業(yè)務(wù)模型并不會(huì)太復(fù)雜但覆蓋面非常全。對(duì)一個(gè)SSM階段的學(xué)習(xí)者來說它既不會(huì)像ERP那樣讓代碼量失控又足夠撐起一個(gè)完整的Web項(xiàng)目。這是它作為畢業(yè)設(shè)計(jì)和練手項(xiàng)目經(jīng)久不衰的原因。1.2 適用人群與三種使用場(chǎng)景我先說結(jié)論這個(gè)系統(tǒng)適合三類人。第一類是準(zhǔn)備畢業(yè)設(shè)計(jì)的在校生。SSM框架時(shí)至今日依然是很多高校畢設(shè)選題的主流技術(shù)棧一個(gè)業(yè)務(wù)清晰、代碼規(guī)范、附帶文檔和運(yùn)行視頻的項(xiàng)目能讓答辯環(huán)節(jié)省下大量精力。特別是老師問“卡掛失了還能消費(fèi)嗎”“注銷后余額怎么處理”這類業(yè)務(wù)問題你如果親手做過回答起來完全是另一個(gè)狀態(tài)。第二類是準(zhǔn)備Java后端面試的求職者。很多人手里沒有能拿得出手的項(xiàng)目面試官問“你項(xiàng)目里遇到過什么問題”答不上來。校園卡系統(tǒng)的并發(fā)扣款、事務(wù)管理、狀態(tài)流轉(zhuǎn)設(shè)計(jì)都是面試官感興趣的切入點(diǎn)完全可以把項(xiàng)目經(jīng)驗(yàn)和Java八股文結(jié)合起來講。第三類是剛學(xué)完SSM框架的基礎(chǔ)學(xué)習(xí)者?？蚣軐W(xué)完了但不知道怎么整合三個(gè)框架各管什么配置文件怎么寫前端請(qǐng)求怎么到后端這個(gè)項(xiàng)目能回答這些問題。我見過不少同學(xué)把教程里的demo抄了一遍但遇到“注冊(cè)功能怎么和登錄功能共用一套用戶體系”這種問題就卡住。而校園卡系統(tǒng)天然包含了多角色、多狀態(tài)、多流水做一遍框架的整合能力、事務(wù)控制能力、分層設(shè)計(jì)能力都會(huì)有一個(gè)真實(shí)的提升。2. 核心業(yè)務(wù)與數(shù)據(jù)庫設(shè)計(jì)把狀態(tài)流轉(zhuǎn)想清楚再做2.1 五大功能模塊的邊界劃分系統(tǒng)雖然叫“校園卡管理系統(tǒng)”但模塊邊界一定要清楚。我在設(shè)計(jì)時(shí)把功能拆成了五個(gè)核心模塊加上一個(gè)系統(tǒng)登錄模塊一共六個(gè)用戶模塊學(xué)生信息新增、修改、查詢、刪除對(duì)應(yīng)校園卡的開卡。賬戶模塊每個(gè)用戶對(duì)應(yīng)一個(gè)卡賬戶管理余額和狀態(tài)。充值模塊學(xué)生充值更新余額寫入充值流水。消費(fèi)模塊刷卡消費(fèi)扣減余額寫入消費(fèi)流水。掛失/注銷模塊更改賬戶狀態(tài)掛失后禁止消費(fèi)注銷后賬戶失效。系統(tǒng)管理模塊管理員登錄、退出、密碼修改。模塊劃分的意義在于業(yè)務(wù)之間通過賬戶狀態(tài)和余額解耦而不是把邏輯堆在一個(gè)類里。比如掛失操作只更新賬戶狀態(tài)字段而消費(fèi)功能在扣款前檢查狀態(tài)。這樣各模塊獨(dú)立出了問題也好排查。2.2 數(shù)據(jù)庫表設(shè)計(jì)與字段說明數(shù)據(jù)庫設(shè)計(jì)是這個(gè)項(xiàng)目的地基。我當(dāng)時(shí)設(shè)計(jì)了5張表不多不少剛好覆蓋業(yè)務(wù)又沒有冗余student學(xué)生表 - id int 主鍵自增 - student_no varchar(20) 學(xué)號(hào)唯一索引 - name varchar(50) 姓名 - gender varchar(10) 性別 - department varchar(50) 院系 - phone varchar(20) 聯(lián)系方式 - create_time datetime 創(chuàng)建時(shí)間 card_account卡賬戶表 - id int 主鍵自增 - student_id int 關(guān)聯(lián)學(xué)生表 - card_no varchar(20) 卡號(hào)唯一索引 - balance decimal(10,2) 余額 - status tinyint 賬戶狀態(tài)0正常 1掛失 2注銷 - create_time datetime 開卡時(shí)間 - lose_time datetime 掛失時(shí)間 - cancel_time datetime 注銷時(shí)間 recharge_record充值記錄表 - id int 主鍵自增 - card_id int 關(guān)聯(lián)賬戶表 - amount decimal(10,2) 充值金額 - create_time datetime 充值時(shí)間 - operator varchar(20) 操作人管理員或自助 consume_record消費(fèi)記錄表 - id int 主鍵自增 - card_id int 關(guān)聯(lián)賬戶表 - amount decimal(10,2) 消費(fèi)金額 - shop_name varchar(50) 消費(fèi)地點(diǎn) - create_time datetime 消費(fèi)時(shí)間 admin_user管理員表 - id int 主鍵自增 - username varchar(50) 用戶名 唯一 - password varchar(100) 密碼 - real_name varchar(50) 姓名這里有個(gè)關(guān)鍵設(shè)計(jì)余額一定要放在賬戶表里而不是每次通過流水匯總。雖然通過“充值總和 - 消費(fèi)總和”也能算出余額但那樣每次查詢都要掃流水表數(shù)據(jù)量大了性能會(huì)很差。實(shí)戰(zhàn)項(xiàng)目里余額字段直接冗余在賬戶表流水只做記錄和對(duì)賬這個(gè)思路在很多金融系統(tǒng)里也是這么干的。2.3 充值、消費(fèi)、掛失、注銷的狀態(tài)流轉(zhuǎn)狀態(tài)是這類系統(tǒng)的靈魂。我見過很多初學(xué)者直接把狀態(tài)寫死在代碼里比如if (status 1) 就不能消費(fèi)完全沒有狀態(tài)機(jī)的概念。實(shí)際上校園卡的狀態(tài)流轉(zhuǎn)是這樣的正常狀態(tài)可以充值、可以消費(fèi)、可以掛失、可以注銷。掛失狀態(tài)不能消費(fèi)、不能注銷可以解掛恢復(fù)為正常凍結(jié)余額但不能清零。注銷狀態(tài)終態(tài)所有操作都拒絕。為什么要區(qū)分掛失和注銷因?yàn)閽焓桥R時(shí)性的找到卡還能恢復(fù)注銷是終態(tài)卡作廢。如果把掛失做成刪除賬戶那卡找到了就麻煩了。一個(gè)狀態(tài)字段加狀態(tài)校驗(yàn)就能覆蓋這些場(chǎng)景這也是面試官喜歡問的點(diǎn)。這個(gè)狀態(tài)機(jī)模型雖然簡單但背后的思想是“任何操作前先校驗(yàn)狀態(tài)合法性”和很多電商系統(tǒng)的訂單狀態(tài)機(jī)是同一套邏輯。在代碼里我用一個(gè)狀態(tài)常量類來管理避免魔法數(shù)字散落各處。3. SSM框架整合與實(shí)現(xiàn)要點(diǎn)三個(gè)框架各干各的活3.1 Spring SpringMVC MyBatis 分層思路SSM框架組合是經(jīng)典的“三層架構(gòu)”落地方式Spring負(fù)責(zé)對(duì)象管理IoC和事務(wù)管理AOP。Service層的實(shí)例不用自己new由Spring容器統(tǒng)一創(chuàng)建和管理數(shù)據(jù)庫事務(wù)通過Transactional聲明式配置一個(gè)方法就是一個(gè)事務(wù)單元。SpringMVC負(fù)責(zé)Web層的請(qǐng)求路由。前端發(fā)來的URL請(qǐng)求經(jīng)過DispatcherServlet分發(fā)到對(duì)應(yīng)的Controller方法Controller接收參數(shù)、調(diào)用Service、返回JSON或頁面。MyBatis負(fù)責(zé)數(shù)據(jù)持久化。Mapper接口定義方法XML或注解寫SQL把結(jié)果集映射成Java對(duì)象。實(shí)際分層的時(shí)候我按“Controller - Service - Mapper”拆。Controller層只做參數(shù)接收和結(jié)果返回不寫業(yè)務(wù)代碼Service層做業(yè)務(wù)邏輯和事務(wù)控制Mapper層只做SQL操作。這樣每一層都職責(zé)單一也方便后續(xù)維護(hù)。有個(gè)新手常犯的錯(cuò)誤在Controller里直接操作多個(gè)Mapper把業(yè)務(wù)邏輯堆在控制器里。這樣寫確實(shí)能跑但事務(wù)很難控制——如果兩個(gè)Mapper操作中間拋異常數(shù)據(jù)就處于不一致狀態(tài)。正確的做法是把業(yè)務(wù)邏輯封裝到Service方法里加上Transactional一個(gè)方法要么全成功要么全回滾。3.2 關(guān)鍵配置與依賴選型SSM整合的配置文件是初學(xué)者最頭疼的部分。我用的技術(shù)版本是Java 8、Maven 3.6、Spring 5.x、SpringMVC 5.x、MyBatis 3.5.x。這套組合非常穩(wěn)定教程也多出問題容易查。Maven依賴核心就幾個(gè)spring-context、spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid連接池、jackson-databind用于JSON轉(zhuǎn)換。另外還需要servlet-api和jsp-api但這兩個(gè)要加provided作用域否則會(huì)和Tomcat自帶的沖突。配置上我分成了三個(gè)核心配置文件spring-context.xml配置數(shù)據(jù)源、SqlSessionFactory、Mapper掃描、Service掃描、事務(wù)管理器。spring-mvc.xml配置注解驅(qū)動(dòng)、Controller掃描、視圖解析器、靜態(tài)資源映射。web.xml配置DispatcherServlet和Spring的ContextLoaderListener。這里說一下容易被忽略的細(xì)節(jié)Spring配置和SpringMVC配置要分清父子容器關(guān)系。Spring容器管理Service和MapperSpringMVC容器管理Controller。如果在spring-mvc.xml里掃描了Service類事務(wù)會(huì)失效。我自己就踩過這個(gè)坑后來統(tǒng)一用“spring-context.xml只掃Service和Mapperspring-mvc.xml只掃Controller”的約定問題再?zèng)]出現(xiàn)過。3.3 前端交互與接口設(shè)計(jì)思路這個(gè)項(xiàng)目的前端我用了JSP Bootstrap AJAX。JSP做頁面模板Bootstrap做樣式AJAX和JSON做前后端數(shù)據(jù)交互。雖然現(xiàn)在前端框架Vue很流行但SSM項(xiàng)目搭配JSP是最常見的組合重點(diǎn)是把接口設(shè)計(jì)清楚。項(xiàng)目的接口按REST風(fēng)格設(shè)計(jì)比如POST /card/recharge充值參數(shù)為卡號(hào)和金額。POST /card/consume消費(fèi)參數(shù)為卡號(hào)和金額。POST /card/loss掛失參數(shù)為卡號(hào)。POST /card/restore解掛參數(shù)為卡號(hào)。POST /card/cancel注銷參數(shù)為卡號(hào)。GET /record/list查詢流水支持分頁。所有的接口統(tǒng)一返回JSON格式結(jié)構(gòu)是這樣{ code: 200, msg: 操作成功, data: { balance: 98.50 } }前端根據(jù)code判斷成功失敗有數(shù)據(jù)就渲染data。這種前后端通過JSON交互的方式現(xiàn)在依然是主流做法而且就算以后你想用Vue3重新寫前端后端接口完全不用改只要做跨域配置就行。熱搜里提到“vue3連接ssm框架”其實(shí)原理就是這么簡單后端不動(dòng)把前端換成Vue用axios調(diào)接口。4. 核心功能代碼實(shí)現(xiàn)復(fù)盤把關(guān)鍵場(chǎng)景寫明白4.1 充值功能的業(yè)務(wù)邏輯與冪等處理充值邏輯看起來就是“余額加錢、記流水”兩步但實(shí)際實(shí)現(xiàn)有講究。我先說最核心的Service代碼Service public class CardServiceImpl implements CardService { Autowired private CardAccountMapper cardAccountMapper; Autowired private RechargeRecordMapper rechargeRecordMapper; Override Transactional(rollbackFor Exception.class) public Result recharge(String cardNo, BigDecimal amount) { // 1. 校驗(yàn)參數(shù) if (amount null || amount.compareTo(BigDecimal.ZERO) 0) { return Result.error(充值金額必須大于0); } // 2. 查詢賬戶 CardAccount account cardAccountMapper.findByCardNo(cardNo); if (account null) { return Result.error(卡號(hào)不存在); } if (account.getStatus() ! CardStatus.NORMAL) { return Result.error(賬戶狀態(tài)異常無法充值); } // 3. 更新余額 int rows cardAccountMapper.increaseBalance(cardNo, amount); if (rows 0) { throw new RuntimeException(充值失敗); } // 4. 插入流水 RechargeRecord record new RechargeRecord(); record.setCardId(account.getId()); record.setAmount(amount); rechargeRecordMapper.insert(record); return Result.success(充值成功, getBalance(cardNo)); } }這段代碼有幾個(gè)地方值得新手注意。第一金額用BigDecimal而不是double。這是金融相關(guān)業(yè)務(wù)的鐵律。double在加減時(shí)會(huì)丟失精度0.1 0.2可能等于0.30000000000000004這在余額計(jì)算里不可接受。BigDecimal按照實(shí)際金額精度計(jì)算配合數(shù)據(jù)庫的decimal(10,2)金額計(jì)算才靠譜。第二先更新余額再插入流水并且包裹在同一個(gè)事務(wù)里。如果流水插入失敗余額更新也會(huì)回滾。我在初始化項(xiàng)目時(shí)專門測(cè)試過手動(dòng)在插入流水處拋一個(gè)異常充值事務(wù)整體回滾余額不變。這個(gè)驗(yàn)證過程我建議你也做一遍能直觀理解Transactional的作用。第三冪等性問題。如果用戶點(diǎn)了兩次充值按鈕請(qǐng)求重復(fù)提交會(huì)不會(huì)充兩次這個(gè)系統(tǒng)用了最簡單的前端防重復(fù)提交按鈕置灰但后端更嚴(yán)謹(jǐn)?shù)淖龇ㄊ羌右粋€(gè)業(yè)務(wù)訂單號(hào)記錄到單獨(dú)的流水表通過唯一索引約束同一個(gè)訂單號(hào)只能成功一次。面試被問到“怎么防止重復(fù)支付”時(shí)這是一個(gè)很好的延伸點(diǎn)。4.2 消費(fèi)扣款與余額校驗(yàn)的代碼細(xì)節(jié)消費(fèi)是另一個(gè)核心操作邏輯上有“先查后扣”和“直接扣”兩種寫法。先看一種更穩(wěn)妥的做法Override Transactional(rollbackFor Exception.class) public Result consume(String cardNo, BigDecimal amount, String shopName) { // 1. 校驗(yàn)金額 if (amount null || amount.compareTo(BigDecimal.ZERO) 0) { return Result.error(消費(fèi)金額必須大于0); } // 2. 查詢賬戶并校驗(yàn)狀態(tài) CardAccount account cardAccountMapper.findByCardNo(cardNo); if (account null) { return Result.error(卡號(hào)不存在); } if (account.getStatus() ! CardStatus.NORMAL) { return Result.error(當(dāng)前狀態(tài)不可消費(fèi)); } // 3. 校驗(yàn)余額 if (account.getBalance().compareTo(amount) 0) { return Result.error(余額不足); } // 4. 扣減余額 int rows cardAccountMapper.decreaseBalance(cardNo, amount); if (rows 0) { throw new RuntimeException(扣款失敗); } // 5. 插入消費(fèi)流水 ConsumeRecord record new ConsumeRecord(); record.setCardId(account.getId()); record.setAmount(amount); record.setShopName(shopName); consumeRecordMapper.insert(record); return Result.success(消費(fèi)成功, getBalance(cardNo)); }這里有一個(gè)面試高頻問題“先查詢余額再扣款”在高并發(fā)下會(huì)不會(huì)有問題答案是會(huì)。假設(shè)兩個(gè)請(qǐng)求同時(shí)讀到余額是10元兩個(gè)都扣8元各自判斷余額夠最后余額變成2元但實(shí)際上兩筆消費(fèi)共扣16元超扣了。解決方案有兩種一是用數(shù)據(jù)庫行鎖SELECT ... FOR UPDATE把賬戶行鎖住串行處理二是用樂觀鎖更新的時(shí)候加條件where balance amount。MyBatis的decreaseBalanceSQL可以寫成UPDATE card_account SET balance balance - #{amount} WHERE card_no #{cardNo} AND balance #{amount}這樣數(shù)據(jù)庫層面就保證了余額夠才能扣成功如果返回影響行數(shù)為0說明余額不足或卡號(hào)不存在。數(shù)據(jù)庫的原子操作比Java代碼里的“先查后改”可靠得多這也是一個(gè)很好的面試談資。在日常單機(jī)學(xué)習(xí)環(huán)境里很多同學(xué)察覺不到這個(gè)差異但在用戶量稍大的場(chǎng)景這是一個(gè)非常關(guān)鍵的正確性設(shè)計(jì)。4.3 掛失、注銷的狀態(tài)機(jī)管理代碼掛失和注銷放在一起講因?yàn)樗鼈兊谋举|(zhì)都是改狀態(tài)。區(qū)別在于掛失之后可以解掛注銷是終態(tài)。我在CardStatus類里定義了狀態(tài)常量public class CardStatus { public static final int NORMAL 0; // 正常 public static final int LOSS 1; // 掛失 public static final int CANCEL 2; // 注銷 }掛失的Service邏輯Override Transactional(rollbackFor Exception.class) public Result loss(String cardNo) { CardAccount account cardAccountMapper.findByCardNo(cardNo); if (account null) { return Result.error(卡號(hào)不存在); } if (account.getStatus() ! CardStatus.NORMAL) { return Result.error(只有正常狀態(tài)的卡才能掛失); } account.setStatus(CardStatus.LOSS); account.setLoseTime(new Date()); cardAccountMapper.updateStatus(account); return Result.success(掛失成功); }對(duì)應(yīng)的消費(fèi)方法里已經(jīng)校驗(yàn)了status ! NORMAL就拒絕所以掛失一生效消費(fèi)功能立刻失效。解掛就是把狀態(tài)改回NORMAL同時(shí)清空掛失時(shí)間。注銷的邏輯也是類似但要把狀態(tài)改成CANCEL而且注銷前最好校驗(yàn)余額為0避免資金遺留問題。你可以把這個(gè)“注銷前余額檢查”作為擴(kuò)展點(diǎn)在項(xiàng)目里加上余額清零或退費(fèi)的功能。我特別想強(qiáng)調(diào)一點(diǎn)狀態(tài)機(jī)的核心不是怎么寫代碼而是怎么設(shè)計(jì)狀態(tài)和操作之間的約束關(guān)系。這個(gè)項(xiàng)目里用的“狀態(tài)先校驗(yàn)操作后流轉(zhuǎn)”模式在真實(shí)的交易系統(tǒng)、審批系統(tǒng)里非常常見。把這三行狀態(tài)判斷吃透比背十道面試題更有用。4.4 登錄與權(quán)限攔截的核心寫法系統(tǒng)有一個(gè)管理員登錄功能。登錄校驗(yàn)通過后把用戶信息存到Session里。為了防止未登錄用戶直接訪問后臺(tái)接口我加了一個(gè)SpringMVC的攔截器public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user request.getSession().getAttribute(adminUser); if (user null) { // 判斷是否AJAX請(qǐng)求返回不同結(jié)果 response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:401,\msg\:\未登錄或登錄已過期\}); return false; } return true; } }然后在spring-mvc.xml里注冊(cè)攔截器配置不攔截登錄接口和靜態(tài)資源mvc:interceptors mvc:interceptor mvc:mapping path/**/ mvc:exclude-mapping path/admin/login/ mvc:exclude-mapping path/static/**/ bean classcom.campus.interceptor.LoginInterceptor/ /mvc:interceptor /mvc:interceptors這個(gè)攔截器是SSM項(xiàng)目權(quán)限控制的經(jīng)典寫法。攔截器只負(fù)責(zé)“是否登錄”什么時(shí)候用戶能做什么操作交給Service層的狀態(tài)校驗(yàn)去做。把這兩個(gè)層面分開邏輯才清晰。關(guān)于密碼存儲(chǔ)項(xiàng)目里用了MD5加密。但真實(shí)系統(tǒng)中密碼加密建議用BCrypt這類帶鹽的算法MD5已經(jīng)不夠安全。你可以把這個(gè)作為項(xiàng)目優(yōu)化點(diǎn)提出來在面試?yán)飼?huì)加分。5. 部署運(yùn)行關(guān)鍵操作與常見問題排查5.1 環(huán)境準(zhǔn)備與部署全流程把這個(gè)系統(tǒng)跑起來你需要準(zhǔn)備的東西不多JDK 1.8Maven 3.6Tomcat 8.5或9.0MySQL 5.7或8.0IDEA開發(fā)工具部署步驟我整理成了一段流程每一步都很關(guān)鍵創(chuàng)建數(shù)據(jù)庫campus_card執(zhí)行項(xiàng)目里的init.sql初始化腳本腳本會(huì)建表并插入一條測(cè)試管理員賬號(hào)和幾條學(xué)生數(shù)據(jù)。修改jdbc.properties里的數(shù)據(jù)庫連接信息重點(diǎn)是用戶名、密碼、URL里的serverTimezoneAsia/Shanghai。用IDEA打開Maven項(xiàng)目等待依賴下載完成。如果網(wǎng)絡(luò)不好可以在settings.xml里配置阿里云鏡像。配置Tomcat把項(xiàng)目部署到Tomcat點(diǎn)擊啟動(dòng)。瀏覽器訪問http://localhost:8080/項(xiàng)目名/用管理員賬號(hào)登錄。很多新手在第五步前就卡住了大多數(shù)情況是數(shù)據(jù)庫連不上或者依賴沒下來。先單獨(dú)寫好數(shù)據(jù)庫連接測(cè)試再啟動(dòng)項(xiàng)目能幫你快速定位問題。5.2 常見問題排查速查表我把自己跑項(xiàng)目時(shí)遇到頻率最高的問題整理成了表你可以直接照這個(gè)排查現(xiàn)象原因解決辦法Tomcat啟動(dòng)報(bào)ClassNotFoundExceptionMaven依賴沒下載完整檢查settings.xml鏡像配置mvn clean后重新導(dǎo)入項(xiàng)目啟動(dòng)時(shí)提示Port 8080 was already in use端口被占用換端口或netstat -ano頁面中文亂碼編碼不一致JSP頁面、數(shù)據(jù)庫連接URL、Tomcat編碼統(tǒng)一為UTF-8數(shù)據(jù)庫連接失敗Access denied用戶名密碼或權(quán)限問題檢查賬號(hào)密碼GRANT ALL ON campus_card.* TO rootlocalhost登錄后頁面報(bào)404攔截器攔截了靜態(tài)資源或路徑不對(duì)檢查攔截器exclude配置檢查請(qǐng)求路徑運(yùn)行時(shí)報(bào)OutOfMemoryError: insufficient memoryJVM啟動(dòng)內(nèi)存不足在IDEA的VM options里加-Xms256m -Xmx512m查詢結(jié)果返回null但數(shù)據(jù)庫有數(shù)據(jù)字段映射不正確開啟MyBatis駝峰映射mapUnderscoreToCamelCasetrue最后一條我多說一句。Java實(shí)體類的屬性命名一般是駝峰式比如studentNo數(shù)據(jù)庫字段是下劃線式student_noMyBatis默認(rèn)不會(huì)自動(dòng)映射需要在application.properties或mybatis-config.xml里開啟駝峰映射。不開啟的話查出來的數(shù)據(jù)對(duì)象就是一個(gè)個(gè)null字段這是SSM項(xiàng)目里經(jīng)典到不能再經(jīng)典的坑。5.3 如何把項(xiàng)目講給面試官聽很多人項(xiàng)目做完了但面試被問幾句就露怯。校園卡系統(tǒng)雖然不大但只要講出“設(shè)計(jì)感”依然很有說服力。我的建議是順著三條線準(zhǔn)備一是事務(wù)控制線。充值、消費(fèi)為什么加TransactionalSpring的事務(wù)傳播行為有哪幾種默認(rèn)的REQUIRED是什么意思一個(gè)Service方法調(diào)另一個(gè)Service方法事務(wù)會(huì)合并嗎這些八股文知識(shí)點(diǎn)放在這個(gè)項(xiàng)目場(chǎng)景里講比干背效果好得多。二是并發(fā)安全線。兩個(gè)請(qǐng)求同時(shí)消費(fèi)怎么辦怎么用數(shù)據(jù)庫的行鎖或樂觀鎖保證不超扣MySQL默認(rèn)隔離級(jí)別是什么SELECT ... FOR UPDATE會(huì)鎖行嗎這些問題的答案在代碼里都有對(duì)應(yīng)位置面試官問起來你可以直接說“我在這段消費(fèi)邏輯里是怎么處理的”。三是狀態(tài)設(shè)計(jì)線。為什么掛失和注銷分開狀態(tài)放在數(shù)據(jù)庫里是什么類型如果以后要擴(kuò)展“凍結(jié)狀態(tài)”怎么辦回答的時(shí)候把狀態(tài)機(jī)的思路講出來面試官就知道你不是只會(huì)CRUD的。另外熱搜詞里的java面試八股文、HashMap底層、冒泡排序這些是面試?？嫉幕A(chǔ)題。但項(xiàng)目經(jīng)驗(yàn)存在的意義不是代替這些基礎(chǔ)題而是讓你在回答完基礎(chǔ)題之后能拿出一個(gè)具體的場(chǎng)景證明“我會(huì)用”。把這個(gè)校園卡系統(tǒng)的每條業(yè)務(wù)邏輯吃透比背一百道題有用。5.4 版本與擴(kuò)展方向如果你用的是Java 11以上或Spring Boot搭建方式會(huì)有一些差異。SSM畢竟是手動(dòng)整合三個(gè)框架配置較多而Spring Boot把很多配置都自動(dòng)完成了。但我的看法是練習(xí)階段建議先用SSM手動(dòng)搭一遍這樣才能理解Spring Boot幫我們省掉了什么。等你把SSM的配置流程走順了再切Spring Boot會(huì)非?？臁ｍ?xiàng)目本身也可以擴(kuò)展。熱搜詞里提到Vue3你可以用Vue3 Element Plus重寫前端頁面把JSP替換成前后端分離架構(gòu)后端只要加一個(gè)CORS跨域配置即可。也可以把“注銷”擴(kuò)展成完整的“退費(fèi)流程”把“消費(fèi)”擴(kuò)展成“支持不同商戶類型”。這些擴(kuò)展在文檔和答辯視頻里都是亮點(diǎn)。最后再分享一個(gè)小細(xì)節(jié)整個(gè)項(xiàng)目里我最滿意的是那張流水表的設(shè)計(jì)。剛開始我也覺得充值記錄和消費(fèi)記錄建一張表就夠了后來想了想還是拆開了。因?yàn)槌渲涤涗涥P(guān)注的是“誰給我充了多少錢”消費(fèi)記錄關(guān)注的是“我在哪花了多少錢”兩個(gè)查詢維度完全不同拆開后統(tǒng)計(jì)和分頁都輕松。這個(gè)簡單的表設(shè)計(jì)決策后來在寫對(duì)賬功能的時(shí)候幫了大忙。如果你也在做校園卡系統(tǒng)或者準(zhǔn)備做類似的SSM練手項(xiàng)目記住一個(gè)原則先把狀態(tài)和余額的流轉(zhuǎn)畫出來再動(dòng)手寫代碼。業(yè)務(wù)跑通了剩下的都是細(xì)節(jié)。踩過幾次坑之后你會(huì)發(fā)現(xiàn)這個(gè)項(xiàng)目帶給你最大的收獲不是那些代碼而是對(duì)“一個(gè)完整系統(tǒng)是怎么運(yùn)轉(zhuǎn)的”這件事的理解。