一個(gè)“文物征集管理系統(tǒng)”聽(tīng)起來(lái)好像很小眾但放在畢設(shè)和課設(shè)的背景下這其實(shí)是一個(gè)非常經(jīng)典、非常聰明的選題。它表面上是一個(gè)面向“紅色革命文物”的業(yè)務(wù)管理系統(tǒng)實(shí)際上內(nèi)核是一個(gè)標(biāo)準(zhǔn)的信息管理平臺(tái)有用戶權(quán)限、有業(yè)務(wù)流程流轉(zhuǎn)、有文件上傳、有數(shù)據(jù)統(tǒng)計(jì)難度適中業(yè)務(wù)故事也好講。很多同學(xué)拿到類似的源碼要么只會(huì)對(duì)著教程跑起來(lái)要么不知道怎么在答辯時(shí)講清楚更別說(shuō)萬(wàn)一遇到問(wèn)題如何排查。這篇文章我就以這套 SpringBoot Vue 的 MVC 模式管理系統(tǒng)為例從頭到尾拆一遍它解決什么問(wèn)題、技術(shù)架構(gòu)怎么選、核心代碼怎么寫、數(shù)據(jù)庫(kù)怎么建、怎么從零跑起來(lái)以及我在實(shí)際調(diào)試中踩過(guò)的一些坑。先說(shuō)結(jié)論這套東西你把它吃透了不只是完成一個(gè)畢設(shè)而是真正理解了企業(yè)級(jí)前后端分離開(kāi)發(fā)的基本套路。1. 需求先想清楚再動(dòng)手這個(gè)系統(tǒng)到底要管什么很多同學(xué)拿到項(xiàng)目第一件事就是打開(kāi) IDEA 開(kāi)始跑代碼其實(shí)這是比較低效的做法。先搞清楚業(yè)務(wù)再看代碼事半功倍。1.1 別被“文物征集”四個(gè)字勸退拆解核心業(yè)務(wù)紅色革命文物征集系統(tǒng)的核心業(yè)務(wù)說(shuō)白了就是一件事把散落在民間的文物線索和實(shí)物征集信息系統(tǒng)化地管起來(lái)。傳統(tǒng)的線下流程是發(fā)布征集公告 - 群眾來(lái)電來(lái)信提供線索 - 工作人員登記紙質(zhì)信息 - 專家鑒定審核 - 入庫(kù)登記 - 建立臺(tái)賬。這個(gè)過(guò)程里問(wèn)題很多紙質(zhì)表格容易丟、想查一條記錄翻半天檔案柜、審核進(jìn)度誰(shuí)也不知道、統(tǒng)計(jì)本月征集了多少文物全靠人工數(shù)。而管理系統(tǒng)要做的就是把這條鏈路搬到線上。我建議你把整個(gè)系統(tǒng)抽象成一條“征集業(yè)務(wù)線”所有功能都圍繞這條線展開(kāi)線索登記群眾或者征集員錄入文物基本信息名稱、年代、類別、來(lái)源、保存現(xiàn)狀、征集方式等。材料附件上傳文物照片、相關(guān)證明文件。審核流轉(zhuǎn)管理員或者專家對(duì)征集信息進(jìn)行審核可能通過(guò)、可能退回補(bǔ)充材料。入庫(kù)登記審核通過(guò)后文物正式進(jìn)入館藏臺(tái)賬生成唯一編號(hào)。統(tǒng)計(jì)展示按年代、類別、征集狀態(tài)等維度做統(tǒng)計(jì)讓管理者掌握征集進(jìn)度。理解了這條線你再看代碼里的實(shí)體類、數(shù)據(jù)庫(kù)表、接口設(shè)計(jì)就會(huì)覺(jué)得“原來(lái)如此”而不是“這是什么鬼”。1.2 功能模塊劃分與權(quán)限設(shè)計(jì)系統(tǒng)里不是所有人都能干所有事的這就是權(quán)限設(shè)計(jì)的由來(lái)。一個(gè)完整的征集管理系統(tǒng)至少要考慮三類角色系統(tǒng)管理員擁有全部權(quán)限包括用戶管理、數(shù)據(jù)字典維護(hù)、審核管理、統(tǒng)計(jì)查看。征集員/錄入員可以新增征集信息、錄入文物資料、維護(hù)自己創(chuàng)建的記錄。專家/審核員主要負(fù)責(zé)審核征集線索和文物信息給出審核意見(jiàn)。有些系統(tǒng)里還會(huì)把“普通社會(huì)公眾”角色放進(jìn)來(lái)用于在線提交征集線索這就是另一個(gè)典型的業(yè)務(wù)場(chǎng)景了。模塊和權(quán)限的合理劃分是你答辯時(shí)可以重點(diǎn)講的一個(gè)亮點(diǎn)。比如“為什么同一個(gè)登錄接口要返回不同的菜單權(quán)限”“為什么征集的文物信息要用狀態(tài)字段而不是直接刪除”這些都是體現(xiàn)你對(duì)系統(tǒng)思考深度的點(diǎn)。權(quán)限設(shè)計(jì)做得好這個(gè)系統(tǒng)的框架感就出來(lái)了后面加功能也只是在模塊里堆接口而已。2. 技術(shù)選型解析SpringBoot Vue MVC 這個(gè)組合為什么“穩(wěn)”選技術(shù)棧不要追求新奇要追求“能跑、好講、有問(wèn)題能搜到答案”。SpringBoot Vue 這個(gè)組合可以說(shuō)是當(dāng)下Java Web前后端分離項(xiàng)目的“標(biāo)準(zhǔn)答案”。2.1 后端SpringBoot 到底幫我們省了哪些事SpringBoot 是一個(gè)建立在 Spring 框架之上的快速開(kāi)發(fā)腳手架。沒(méi)有它的時(shí)候你要配置 SpringMVC、配置 Tomcat、配置 MyBatis 的 SqlSessionFactory、寫一大堆 XML。有了 SpringBoot 之后很多配置都變成了“約定大于配置”你只需要引入依賴寫上application.yml就能快速啟動(dòng)一個(gè) Web 服務(wù)。在這套系統(tǒng)里SpringBoot 的核心作用有幾個(gè)內(nèi)嵌 Tomcat打包成 jar直接java -jar就能啟動(dòng)不用單獨(dú)裝 Tomcat 服務(wù)器。Starter 機(jī)制引入spring-boot-starter-web就完成了 Web 環(huán)境搭建引入mybatis-plus-boot-starter就有了數(shù)據(jù)庫(kù)操作能力。統(tǒng)一配置數(shù)據(jù)庫(kù)連接、文件上傳大小、端口號(hào)等都在application.yml里管理改配置不用重編譯。還有一個(gè)很實(shí)用的點(diǎn)是SpringBoot 項(xiàng)目現(xiàn)在幾乎都配套 MyBatis-Plus 使用。它幫你封裝了單表的增刪改查不需要寫基礎(chǔ)的 SQL。比如你要按 ID 查一條文物信息只需要CulturalRelic relic culturalRelicMapper.selectById(id);連 SQL 都不用寫。對(duì)于這類業(yè)務(wù)相對(duì)標(biāo)準(zhǔn)化的管理系統(tǒng)來(lái)說(shuō)MyBatis-Plus 能減少大量低級(jí)重復(fù)勞動(dòng)你只需要把心思放在業(yè)務(wù)流程上。2.2 MVC 三層架構(gòu)在前后端分離項(xiàng)目里怎么落地項(xiàng)目標(biāo)題里有一個(gè)詞“MVC模式”這個(gè)是答辯的時(shí)候老師幾乎必問(wèn)的。MVC 不是前后端分離時(shí)代的專用概念但它依然適用于這種架構(gòu)。我們來(lái)說(shuō)清楚它在前后端分離里分別對(duì)應(yīng)什么。后端里的嚴(yán)格分層是這樣的Controller 層表現(xiàn)層只負(fù)責(zé)接收前端請(qǐng)求、解析參數(shù)、調(diào)用 Service、封裝返回結(jié)果。它不寫業(yè)務(wù)邏輯也不直接操作數(shù)據(jù)庫(kù)。一個(gè)干凈的 Controller 方法大概長(zhǎng)這樣RestController RequestMapping(/api/relic) public class CulturalRelicController { Resource private CulturalRelicService relicService; PostMapping(/add) public Result add(RequestBody CulturalRelicDTO dto) { return Result.success(relicService.addRelic(dto)); } }Service 層業(yè)務(wù)邏輯層這是整個(gè)系統(tǒng)的核心負(fù)責(zé)處理業(yè)務(wù)流程、做事務(wù)控制、調(diào)用數(shù)據(jù)層接口。判斷狀態(tài)、校驗(yàn)參數(shù)、組織數(shù)據(jù)都在這一層完成。Mapper/DAO 層數(shù)據(jù)訪問(wèn)層跟數(shù)據(jù)庫(kù)打交道。MyBatis-Plus 的 Mapper 接口繼承BaseMapperT后就自動(dòng)擁有單表的 CRUD 能力你需要關(guān)注的就是那些自定義的復(fù)雜 SQL 和分頁(yè)查詢。至于前端 Vue它本身是一個(gè) MVVM 框架Model-View-ViewModel但這里的“View”只負(fù)責(zé)渲染和交互并沒(méi)有承擔(dān)業(yè)務(wù)處理和數(shù)據(jù)庫(kù)操作的職責(zé)。所以整套系統(tǒng)的業(yè)務(wù)歸屬是清晰的Vue 管界面SpringBoot 的 Controller 管接口Service 管業(yè)務(wù)Mapper 管數(shù)據(jù)。這就是 MVC 思想在后端落地的方式。2.3 數(shù)據(jù)庫(kù)與中間件選型數(shù)據(jù)庫(kù)用的 MySQL 8.0這是目前最主流的選擇。跟這套系統(tǒng)配合你需要注意兩點(diǎn)驅(qū)動(dòng)選擇連接 URL 里建議寫成com.mysql.cj.jdbc.Driver這是 MySQL 8.x 的驅(qū)動(dòng)類老的com.mysql.jdbc.Driver在新版本下會(huì)報(bào)警告甚至報(bào)錯(cuò)。時(shí)區(qū)問(wèn)題URL 后面一定要加serverTimezoneAsia/Shanghai否則數(shù)據(jù)庫(kù)連接很容易報(bào)時(shí)區(qū)錯(cuò)誤。這套系統(tǒng)里基本不需要 Redis、消息隊(duì)列這類中間件除非你想給它加分比如用 Redis 存登錄 token、用 RabbitMQ 做提交征集信息后的異步通知?；A(chǔ)版本MySQL 足夠。3. 數(shù)據(jù)庫(kù)設(shè)計(jì)核心表結(jié)構(gòu)這樣建才合理數(shù)據(jù)庫(kù)設(shè)計(jì)決定了整個(gè)系統(tǒng)代碼好不好寫。很多同學(xué)在建表的時(shí)候喜歡一股腦把所有字段堆在一張表里后面做狀態(tài)流轉(zhuǎn)就各種別扭。這里我直接把核心表拆給你看。3.1 文物征集表業(yè)務(wù)主表怎么設(shè)計(jì)這張表是整個(gè)系統(tǒng)的核心建議叫cultural_relic字段設(shè)計(jì)要有業(yè)務(wù)導(dǎo)向思維。注意名稱、類別、年代這種是很多查詢條件的來(lái)源必須單獨(dú)設(shè)計(jì)字段。字段名類型注釋idbigint主鍵IDrelic_namevarchar(100)文物名稱relic_categoryvarchar(50)文物類別文件/實(shí)物/照片/其他relic_eravarchar(50)所屬年代source_typevarchar(20)征集方式捐贈(zèng)/移交/購(gòu)買/借展current_ownervarchar(50)當(dāng)前持有人contact_phonevarchar(20)聯(lián)系電話descriptiontext文物描述/歷史背景說(shuō)明statustinyint狀態(tài)0草稿/1待審核/2審核通過(guò)/3已入庫(kù)/4已退回submitter_idbigint提交人IDcreate_timedatetime創(chuàng)建時(shí)間update_timedatetime更新時(shí)間這里有幾個(gè)很容易踩的坑一種是“所有字段都用 varchar ”比如描述文本也用 varchar(255)后面存超過(guò) 255 字就報(bào)錯(cuò)了。描述類字段用text日期用datetime金額用decimal該用什么類型就用什么答辯的時(shí)候被問(wèn)到字段類型選擇這也是一個(gè)加分點(diǎn)。另一種是遺漏status狀態(tài)字段。沒(méi)有狀態(tài)字段你就無(wú)法區(qū)分一條記錄是“剛登記”還是“已經(jīng)入庫(kù)”審核流程的代碼根本寫不出來(lái)。狀態(tài)字段一定要預(yù)留而且建議用tinyint0 到 255 的取值空間足夠用十年。3.2 輔助表與狀態(tài)流轉(zhuǎn)除了主表至少還需要這幾張輔助表文物圖片表relic_image一張文物對(duì)應(yīng)多張圖片。字段就是id、relic_id、image_url、is_primary是否主圖。這就是一對(duì)多關(guān)系的標(biāo)準(zhǔn)建模方式前端展示圖片列表時(shí)直接WHERE relic_id ?查詢即可。審核記錄表audit_record記錄誰(shuí)在什么時(shí)間審核了哪條文物意見(jiàn)是什么。字段包含id、relic_id、auditor_id、audit_status、audit_comment、audit_time。用戶表sys_user賬戶、密碼、姓名、角色、手機(jī)號(hào)、創(chuàng)建時(shí)間。這是數(shù)據(jù)庫(kù)層面必須有的“家底”。建好這幾張表整個(gè)系統(tǒng)的數(shù)據(jù)流轉(zhuǎn)就順理成章了。文物征集的狀態(tài)流轉(zhuǎn)建議用狀態(tài)機(jī)思想來(lái)控制而不是隨隨便便在代碼里賦值草稿(0) - 待審核(1) - 審核通過(guò)(2) - 已入庫(kù)(3) \- 已退回(4) - 修改后重新提交 - 待審核(1)這個(gè)流轉(zhuǎn)關(guān)系畫(huà)成圖貼在論文里也是很有說(shuō)服力的。4. 后端核心功能實(shí)現(xiàn)細(xì)節(jié)4.1 文物征集登記接口DTO VO 分層不能省后端代碼的復(fù)雜度往往不是功能有多難而是代碼組織得好不好。比如一個(gè)“新增征集信息”的接口很多初學(xué)者會(huì)直接把實(shí)體類CulturalRelic作為接收參數(shù)PostMapping(/add) public Result add(RequestBody CulturalRelic relic) { ... }這在簡(jiǎn)單場(chǎng)景下沒(méi)什么問(wèn)題但在實(shí)際項(xiàng)目中前端傳來(lái)的字段和后端實(shí)體類的字段往往不是完全一致的。比如前端要傳一個(gè)“擬征集方式”而實(shí)體類里根本沒(méi)有這個(gè)字段或者前端會(huì)把“圖片列表”也一起傳過(guò)來(lái)你總不能指望實(shí)體類里包含一個(gè) List。更好的做法是給前端單獨(dú)定義一個(gè)接收對(duì)象 DTOData Transfer Object比如CulturalRelicDTOData public class CulturalRelicDTO { private String relicName; private String relicCategory; private String relicEra; private String sourceType; private String currentOwner; private String contactPhone; private String description; private ListString imageUrls; // 圖片地址列表 }然后在 Service 層把 DTO 轉(zhuǎn)換成實(shí)體類再保存到數(shù)據(jù)庫(kù)。同理接口返回給前端的數(shù)據(jù)最好也用 VOView Object包裝不要直接把數(shù)據(jù)庫(kù)實(shí)體暴露出去。這樣做的好處很明顯接口字段可控?cái)?shù)據(jù)庫(kù)表結(jié)構(gòu)調(diào)整不會(huì)影響前端聯(lián)調(diào)代碼也更規(guī)范。答辯時(shí)你可以說(shuō)“這是為了接口層與持久層解耦”這個(gè)話一出來(lái)檔次就上去了。4.2 審核流程事務(wù)控制是關(guān)鍵“審核”是征集系統(tǒng)里最核心的業(yè)務(wù)操作。審核通過(guò)一條文物記錄意味著兩件事同時(shí)發(fā)生修改cultural_relic表的status為“審核通過(guò)”。往audit_record表插入一條審核記錄。這兩個(gè)操作必須同時(shí)成功或者同時(shí)失敗。如果你只改了主表狀態(tài)插入審核記錄時(shí)數(shù)據(jù)庫(kù)報(bào)錯(cuò)了那么就會(huì)出現(xiàn)“狀態(tài)已經(jīng)變了但沒(méi)有任何審核記錄”的數(shù)據(jù)不一致問(wèn)題。解決辦法就是加事務(wù)Transactional(rollbackFor Exception.class) public Result audit(AuditDTO auditDTO) { // 1. 修改文物狀態(tài) CulturalRelic relic culturalRelicMapper.selectById(auditDTO.getRelicId()); relic.setStatus(auditDTO.getAuditStatus()); culturalRelicMapper.updateById(relic); // 2. 插入審核記錄 AuditRecord record new AuditRecord(); record.setRelicId(relic.getId()); record.setAuditorId(...); record.setAuditStatus(auditDTO.getAuditStatus()); record.setAuditComment(auditDTO.getAuditComment()); auditRecordMapper.insert(record); return Result.success(); }Transactional就是告訴 Spring這個(gè)方法里的所有數(shù)據(jù)庫(kù)操作要么都提交要么都回滾。這是 Java 后端開(kāi)發(fā)者必須掌握的基礎(chǔ)知識(shí)點(diǎn)也是所有業(yè)務(wù)系統(tǒng)里保護(hù)數(shù)據(jù)一致性的常規(guī)手段。4.3 文件圖片上傳別把文件存進(jìn)數(shù)據(jù)庫(kù)文物征集系統(tǒng)里圖片上傳是必不可少的功能。這里有一個(gè)最常見(jiàn)的新手誤區(qū)想都不想就把圖片轉(zhuǎn)成 Base64 字符串存進(jìn)數(shù)據(jù)庫(kù)或者干脆把圖片的二進(jìn)制數(shù)據(jù)用blob類型存進(jìn)去。這個(gè)方案在畢設(shè)項(xiàng)目里能跑但一旦圖片多了數(shù)據(jù)庫(kù)體積會(huì)膨脹得非?？鞌?shù)據(jù)庫(kù)備份和查詢性能都會(huì)受拖累。正確的常規(guī)做法是文件存磁盤數(shù)據(jù)庫(kù)只存文件路徑。在 SpringBoot 中上傳文件的 Controller 方法可以這樣寫PostMapping(/upload) public Result upload(RequestParam(file) MultipartFile file) { // 1. 生成唯一文件名防止重名覆蓋 String originalFilename file.getOriginalFilename(); // 例如 xxx.jpg String fileSuffix originalFilename.substring(originalFilename.lastIndexOf(.)); String newFileName UUID.randomUUID().toString().replace(-, ) fileSuffix; // 2. 指定存儲(chǔ)目錄注意目錄要先創(chuàng)建 String dirPath D:/upload/relic/; File dir new File(dirPath); if (!dir.exists()) { dir.mkdirs(); } // 3. 保存文件 file.transferTo(new File(dirPath newFileName)); // 4. 返回可訪問(wèn)的 URL 地址 return Result.success(/files/relic/ newFileName); }這里要注意的是第 3 步的transferTo如果報(bào)錯(cuò)大概率是目錄沒(méi)有創(chuàng)建權(quán)限Linux 下尤為常見(jiàn)。文件存好之后還差一步讓 URL 能訪問(wèn)到它。在 SpringBoot 里你需要配置一個(gè)靜態(tài)資源映射把/files/**路徑映射到磁盤目錄Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/files/**) .addResourceLocations(file:D:/upload/); } }這樣前端拿到/files/relic/xxx.jpg瀏覽器直接就能打開(kāi)圖片。4.4 統(tǒng)計(jì)報(bào)表的 SQL 寫法統(tǒng)計(jì)分析模塊在畢設(shè)里很受老師青睞因?yàn)樗苤苯芋w現(xiàn)“數(shù)據(jù)是有價(jià)值的”。常用的統(tǒng)計(jì)有兩個(gè)維度一是按文物類別統(tǒng)計(jì)看看征集到的文物里文件類、實(shí)物類、照片類各占多少。SQL 其實(shí)非常簡(jiǎn)單SELECT relic_category AS category, COUNT(*) AS count FROM cultural_relic WHERE status 3 GROUP BY relic_category;二是按年代統(tǒng)計(jì)比如解放戰(zhàn)爭(zhēng)時(shí)期、土地革命時(shí)期等同樣用 GROUP BY 就能完成。這種統(tǒng)計(jì)結(jié)果傳給前端之后配合 ECharts 畫(huà)餅圖、柱狀圖視覺(jué)效果非常好答辯的時(shí)候把圖一展示比空口說(shuō)“系統(tǒng)很完善”有用得多。5. 前端 Vue 實(shí)現(xiàn)要點(diǎn)5.1 項(xiàng)目初始化與路由設(shè)計(jì)前端的工程化開(kāi)發(fā)一定要從“創(chuàng)建一個(gè)標(biāo)準(zhǔn)項(xiàng)目”開(kāi)始。Vue 官方推薦的腳手架是 Vite但很多老教程用的是 Vue CLI也就是 webpack 方案。這里我的建議是如果你選 Vue 2用 Vue CLInpm install -g vue/cli然后vue create 項(xiàng)目名。如果你選 Vue 3直接用 Vitenpm create vitelatest 項(xiàng)目名 -- --template vue。無(wú)論哪種生成的項(xiàng)目骨架都是標(biāo)準(zhǔn)的 src 結(jié)構(gòu)。路由設(shè)計(jì)上一個(gè)典型的管理系統(tǒng)包含這些頁(yè)面/login 登錄頁(yè) /layout 主布局包含側(cè)邊欄和頂欄 ├── /dashboard 數(shù)據(jù)統(tǒng)計(jì)首頁(yè) ├── /relic/list 文物征集列表 ├── /relic/add 新增征集信息 ├── /relic/detail/:id 文物詳情 ├── /audit/list 審核管理 └── /user/list 用戶管理管理員可見(jiàn)路由配置要配合權(quán)限來(lái)做。最簡(jiǎn)單的做法是登錄時(shí)后端返回當(dāng)前用戶的角色前端根據(jù)角色動(dòng)態(tài)決定渲染哪些菜單和路由。比如“專家”角色就不顯示“用戶管理”菜單而“管理員”則全部可見(jiàn)。這個(gè)功能實(shí)現(xiàn)起來(lái)不難但非常能體現(xiàn)“系統(tǒng)的完整性”。5.2 列表頁(yè)與表單頁(yè)的實(shí)操要點(diǎn)列表展示是整個(gè)前端最常用的功能。我們可以用 Element UI 的el-table加上el-pagination來(lái)做分頁(yè)。關(guān)鍵點(diǎn)在于前端不要把后端返回的全量數(shù)據(jù)在內(nèi)存里做分頁(yè)應(yīng)該把當(dāng)前頁(yè)碼和第頁(yè)條數(shù)傳給后端由后端 SQL 分頁(yè)返回。頁(yè)面第一次加載時(shí)調(diào)用后端接口查詢第一頁(yè)數(shù)據(jù)this.loadData();async loadData() { const res await this.$http.get(/api/relic/list, { params: { pageNum: this.pageNum, pageSize: this.pageSize, relicName: this.searchForm.relicName, status: this.searchForm.status } }); this.tableData res.data.records; this.total res.data.total; }然后每次切換頁(yè)碼、修改搜索條件重新調(diào)用loadData()就行。這里有一個(gè)“經(jīng)典坑”很多同學(xué)在搜索時(shí)把搜索條件里的空字符串也傳給后端導(dǎo)致 SQL 里出現(xiàn)WHERE relic_name 的情況。穩(wěn)妥的做法是在后端接口里對(duì)空字符串做一次判斷或者用 MyBatis-Plus 的StringUtils.isNotBlank()配合 QueryWrapper 動(dòng)態(tài)拼接條件QueryWrapperCulturalRelic wrapper new QueryWrapper(); if (StringUtils.isNotBlank(relicName)) { wrapper.like(relic_name, relicName); }這樣搜索條件為空時(shí)就不會(huì)拼接 SQL避免了很多隱性問(wèn)題。5.3 axios 封裝與攔截器前端拿不到數(shù)據(jù)、接口報(bào)錯(cuò)很多時(shí)候不是后端問(wèn)題而是 axios 沒(méi)有封裝好。我建議項(xiàng)目一開(kāi)始就封裝一個(gè)統(tǒng)一的請(qǐng)求模塊給所有接口設(shè)置一個(gè) baseURL同時(shí)配置請(qǐng)求攔截器和響應(yīng)攔截器import axios from axios; import { Message } from element-ui; import router from ../router; const request axios.create({ baseURL: /api, timeout: 10000 }); // 請(qǐng)求攔截器附加 token request.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] token; } return config; }); // 響應(yīng)攔截器統(tǒng)一處理錯(cuò)誤 request.interceptors.response.use( response { const res response.data; if (res.code ! 200) { Message.error(res.message || 請(qǐng)求失敗); return Promise.reject(new Error(res.message)); } return res; }, error { Message.error(網(wǎng)絡(luò)異常請(qǐng)稍后重試); return Promise.reject(error); } ); export default request;有了這個(gè)封裝前端每個(gè)頁(yè)面調(diào)用接口時(shí)只需要關(guān)心業(yè)務(wù)數(shù)據(jù)不需要每個(gè)地方都寫錯(cuò)誤處理。尤其是登錄功能里“token 過(guò)期自動(dòng)跳轉(zhuǎn)登錄頁(yè)”的邏輯在響應(yīng)攔截器里統(tǒng)一寫一次就夠了。這個(gè)模塊如果寫好了整個(gè)前端工程質(zhì)量立刻提升一個(gè)檔次。6. 從源碼到跑起來(lái)環(huán)境準(zhǔn)備與部署啟動(dòng)拿到源碼之后很多同學(xué)卡在最開(kāi)始的環(huán)境搭配上。這里給出一份經(jīng)過(guò)實(shí)測(cè)的版本組合能少走很多彎路。6.1 后端環(huán)境搭配與啟動(dòng)流程推薦這套組合JDK 1.8或者 JDK 11SpringBoot 2.x 都支持Maven 3.6MySQL 8.0SpringBoot 2.7.x不是 3.x3.x 基于 JDK17學(xué)生項(xiàng)目沒(méi)必要追新2.7 的資料最多遇到問(wèn)題最好搜啟動(dòng)前要做的三件事第一在 MySQL 里創(chuàng)建數(shù)據(jù)庫(kù)并導(dǎo)入 SQL 文件。一般源碼包里會(huì)有一個(gè).sql文件用 Navicat 或者命令行執(zhí)行mysql -u root -p relic_system.sql執(zhí)行前看一眼 SQL 文件里的建庫(kù)語(yǔ)句如果沒(méi)有CREATE DATABASE那就要自己先在 Navicat 里新建一個(gè)數(shù)據(jù)庫(kù)再導(dǎo)入。第二修改application.yml里的數(shù)據(jù)庫(kù)連接配置。把你的數(shù)據(jù)庫(kù)名、用戶名、密碼改對(duì)spring: datasource: url: jdbc:mysql://localhost:3306/relic_system?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8 username: root password: 你自己的密碼 driver-class-name: com.mysql.cj.jdbc.Driver這里特別強(qiáng)調(diào)useSSLfalse和serverTimezoneAsia/Shanghai。MySQL 8 默認(rèn)開(kāi)啟了 SSL本地開(kāi)發(fā)不需要不加這個(gè)參數(shù)可能報(bào)SSL connection error時(shí)區(qū)不配的話數(shù)據(jù)庫(kù)連接池初始化就可能直接報(bào)錯(cuò)。第三啟動(dòng)項(xiàng)目。在 IDEA 里打開(kāi)項(xiàng)目等待 Maven 依賴下載完成找到主啟動(dòng)類右鍵 Run。如果看到類似Tomcat started on port(s): 8080的日志說(shuō)明后端已經(jīng)起來(lái)了。6.2 前端環(huán)境配置與啟動(dòng)流程前端需要安裝 Node.js建議版本 14 或者 16。啟動(dòng)步驟npm install npm run servenpm install第一次執(zhí)行時(shí)可能很慢尤其是安裝 electron 那類跨平臺(tái)依賴。常規(guī)做法是改 registry 鏡像源npm config set registry https://registry.npmmirror.com然后再跑npm install速度會(huì)快很多。前端默認(rèn)端口是 8080后端的端口也是 8080就會(huì)沖突。處理方法有兩個(gè)推薦改前端的 devServer 端口比如改成 8081然后配置代理轉(zhuǎn)發(fā)到 8080。Vue CLI 項(xiàng)目在vue.config.js里配置代理module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } };或者直接改后端端口為 8080 之外的端口如 9090。就算只用一套系統(tǒng)前端 8081 代理到后端 9090 也是可以的。順帶一提前端發(fā)請(qǐng)求時(shí)用/api/relic/list這種以/api開(kāi)頭的相對(duì)路徑代理會(huì)幫它轉(zhuǎn)發(fā)到后端就不會(huì)有跨域問(wèn)題了。如果你的前端直接寫http://localhost:8080/api/relic/list全路徑請(qǐng)求那必須讓后端開(kāi)啟跨域CrossOrigin否則瀏覽器會(huì)攔截響應(yīng)。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這部分內(nèi)容真的是你在實(shí)際開(kāi)發(fā)和學(xué)習(xí)過(guò)程中大概率會(huì)遇到的比看一百遍教程都有用。我把這套系統(tǒng)里高頻故障整理成速查表。癥狀常見(jiàn)原因解決辦法后端啟動(dòng)時(shí)數(shù)據(jù)庫(kù)報(bào) SSL 連接錯(cuò)誤連接 URL 缺少useSSLfalse在application.yml的 url 里加上useSSLfalse時(shí)區(qū)報(bào)錯(cuò)The server time zone value連接 URL 缺少serverTimezone加上serverTimezoneAsia/Shanghai前端請(qǐng)求后端接口 404代理沒(méi)配好或請(qǐng)求路徑不對(duì)檢查vue.config.js的 proxy 配置路徑是否以/api開(kāi)頭接口 405 錯(cuò)誤請(qǐng)求方式不匹配檢查是 POST 還是 GET前后端保持一致請(qǐng)求 401/無(wú)權(quán)限沒(méi)帶 token或 token 過(guò)期看前端請(qǐng)求攔截器有沒(méi)有附加 token后端是否校驗(yàn)圖片上傳后訪問(wèn) 404靜態(tài)資源映射沒(méi)配置在 WebMvcConfig 里配置/files/**映射到磁盤目錄前端頁(yè)面白屏控制臺(tái)報(bào)錯(cuò)路由或組件引入路徑不對(duì)檢查路由配置和 import 路徑有些源碼里的路徑直接用絕對(duì)路徑需要改成相對(duì)路徑npm install非常慢默認(rèn)源在國(guó)外用registry.npmmirror.com鏡像MyBatis-Plus 分頁(yè)查詢返回 total 是 0少了分頁(yè)插件配置檢查是否配置了MybatisPlusInterceptor且添加了PaginationInnerInterceptor數(shù)據(jù)庫(kù)導(dǎo)入 SQL 報(bào)錯(cuò)SQL 文件編碼不是 UTF-8用 Navicat 導(dǎo)入時(shí)選擇 UTF-8 編碼或在命令行執(zhí)行時(shí)指定--default-character-setutf87.1 排查問(wèn)題的通用方法論光有速查表還不夠我給你一個(gè)通用的排查思路這個(gè)方法比任何具體答案都管用。很多同學(xué)遇到報(bào)錯(cuò)的第一反應(yīng)就是把報(bào)錯(cuò)信息復(fù)制粘貼到百度這本身沒(méi)錯(cuò)但效率太低了。正確順序是第一步看控制臺(tái)最底部的 Caused by 信息。Java 的報(bào)錯(cuò)信息往往很長(zhǎng)真正的原因藏在最下面。比如你在 IDEA 的紅色報(bào)錯(cuò)信息里往上翻幾頁(yè)找到Caused by: java.sql.SQLException: Access denied for user rootlocalhost (using password: YES)這時(shí)候就直接知道是數(shù)據(jù)庫(kù)賬號(hào)密碼不對(duì)而不是被上面的什么 NullPointerException 帶偏。第二步確認(rèn)錯(cuò)誤屬于哪個(gè)層級(jí)。是數(shù)據(jù)庫(kù)連接失敗還是 SQL 拼寫錯(cuò)誤還是業(yè)務(wù)代碼空指針還是前端網(wǎng)絡(luò)請(qǐng)求失敗層級(jí)判斷準(zhǔn)確查找范圍縮小一半。第三步斷點(diǎn)調(diào)試。不要覺(jué)得斷點(diǎn)調(diào)試很難。在 IDEA 里打個(gè)斷點(diǎn)用調(diào)試模式啟動(dòng)一步步看代碼執(zhí)行到哪一步出錯(cuò)、某個(gè)變量的值是什么十次里有八次能直接揪出問(wèn)題。這比盲猜變量值高效得多。第四步保留原始日志。排查問(wèn)題之前先復(fù)制完整的日志片段再去查。很多問(wèn)題單看報(bào)錯(cuò)標(biāo)題判斷不出來(lái)但結(jié)合完整的異常堆棧很容易定位。問(wèn)別人問(wèn)題的時(shí)候也一定要把完整日志貼出來(lái)而不是只說(shuō)“報(bào)錯(cuò)了”。7.2 跨域問(wèn)題關(guān)鍵是不重蹈覆轍我單獨(dú)把跨域拎出來(lái)說(shuō)因?yàn)檫@個(gè)是前后端分離項(xiàng)目里最容易困擾新人的問(wèn)題。瀏覽器有一個(gè)同源策略A 網(wǎng)站的 JavaScript 代碼默認(rèn)無(wú)法直接訪問(wèn) B 網(wǎng)站的接口。如果前端跑在http://localhost:8081后端跑在http://localhost:8080端口不同就算域名相同也算跨域。最省事的方案就是上面說(shuō)的代理轉(zhuǎn)發(fā)。前端的所有請(qǐng)求路徑都寫成相對(duì)路徑以/api開(kāi)頭由 Vite 或 webpack-dev-server 代理轉(zhuǎn)發(fā)到后端。這樣瀏覽器看到的請(qǐng)求就是同源的都在 8081跨域問(wèn)題不存在。如果確實(shí)不走代理要后端開(kāi)跨域你可以在 SpringBoot 里寫一個(gè)全局的跨域配置比在每個(gè) Controller 上加CrossOrigin注解更干凈Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(http://localhost:8081) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true); } }需要提醒的是allowedOrigins寫死前端地址如果是線上部署用 nginx 反代這句通常卻是不需要的有些情況下反而會(huì)導(dǎo)致登錄的 cookie 帶不上。8. 二開(kāi)擴(kuò)展讓這個(gè)系統(tǒng)從“能交”變成“出彩”基礎(chǔ)功能跑通只是第一步如果想在答辯時(shí)拿高分或者自己在技術(shù)上真的有收獲一定要嘗試做一兩個(gè)擴(kuò)展功能。我給你幾個(gè)方向難度從低到高。第一個(gè)方向是接入 JWT 做無(wú)狀態(tài)登錄?，F(xiàn)在很多管理系統(tǒng)的登錄方案還是基于 Session 的但前后端分離環(huán)境下更通用的是 JWT。原理是用戶登錄成功后后端生成一個(gè)帶簽名的 token 返回給前端前端把 token 存在 localStorage 里之后每次請(qǐng)求在請(qǐng)求頭帶上這個(gè) token。后端用攔截器校驗(yàn) token 是否有效、是否是當(dāng)前用戶。這個(gè)機(jī)制不復(fù)雜但做完之后你對(duì)“登錄態(tài)”的理解會(huì)通透很多。第二個(gè)方向是引入對(duì)象存儲(chǔ)服務(wù)。我上面文章里寫的圖片上傳是存本地磁盤這在教學(xué)項(xiàng)目里足夠。但如果你想讓項(xiàng)目更接近生產(chǎn)環(huán)境可以考慮把文件上傳到云端的對(duì)象存儲(chǔ)服務(wù)比如 MinIO。MinIO 是開(kāi)源的對(duì)象存儲(chǔ)方案可以部署在你自己的服務(wù)器上文檔也比較友好。SpringBoot 整合 MinIO 有對(duì)應(yīng)的 SDK接口兩三行代碼就能實(shí)現(xiàn)上傳。這個(gè)改造既解決了“文件存在服務(wù)器本地”的擴(kuò)容難題也讓你提前接觸了企業(yè)里常用的文件存儲(chǔ)方案。熱搜詞里還提到了“minio加入到springboot”這正好是一個(gè)加分項(xiàng)。第三個(gè)方向是引入工作流引擎。比如 Flowable 或者 Activiti把審核流程做成可配置的動(dòng)態(tài)流程。這個(gè)難度高但對(duì)于“征集審核”“入庫(kù)審批”這種多環(huán)節(jié)業(yè)務(wù)來(lái)說(shuō)確實(shí)更貼切。如果你時(shí)間充?？梢越ㄗh團(tuán)隊(duì)里一兩個(gè)人專門研究這個(gè)方向作為進(jìn)階功能展示。這幾個(gè)擴(kuò)展方向里我個(gè)人最推薦第二個(gè)方案。理由很簡(jiǎn)單在你們整個(gè)前后端分離的架構(gòu)里文件存儲(chǔ)是不可或缺的一個(gè)環(huán)節(jié)MinIO 的引入不會(huì)打斷現(xiàn)有代碼邏輯又能在答辯時(shí)展示你對(duì)“生產(chǎn)級(jí)文件存儲(chǔ)”的認(rèn)知性價(jià)比最高。9. 寫在后面做項(xiàng)目最忌諱“跑起來(lái)就完事”最后分享一點(diǎn)我自己做這些項(xiàng)目時(shí)的心得。很多人把一個(gè)項(xiàng)目拉下來(lái)之后跑起來(lái)截幾張圖論文一貼就覺(jué)得自己完成任務(wù)了。實(shí)際上等到答辯的時(shí)候老師隨便問(wèn)一個(gè)“審核狀態(tài)是怎么流轉(zhuǎn)的”立刻就露餡了。我的建議是你拿到任何系統(tǒng)源碼不要急著跑而是先干兩件事第一件事用筆在紙上畫(huà)一遍數(shù)據(jù)庫(kù)關(guān)系圖。不用畫(huà)得多華麗就畫(huà)出用戶表、文物征集表、審核記錄表、圖片表之間誰(shuí)關(guān)聯(lián)誰(shuí)就能明確這個(gè)系統(tǒng)的業(yè)務(wù)主鏈路。畫(huà)完你就能發(fā)現(xiàn)原來(lái)從這個(gè)系統(tǒng)里隨便找一個(gè)功能點(diǎn)都離不開(kāi)這幾張表的聯(lián)動(dòng)。第二件事把其中一個(gè)核心功能從頭到尾寫一遍。不需要完整重寫整個(gè)系統(tǒng)但你可以試著自己寫一個(gè)“文物征集信息新增”功能從建表、寫實(shí)體、寫 Mapper、寫 Service、寫 Controller到前端寫一個(gè)表單頁(yè)、調(diào)接口、刷新列表。親手寫完這一個(gè)閉環(huán)你就掌握了前后端分離項(xiàng)目里 80% 的套路。剩下的功能無(wú)非是列表查詢、狀態(tài)修改、刪除、統(tǒng)計(jì)套路都是同一個(gè)。這套項(xiàng)目值不值得學(xué)關(guān)鍵不在于它的功能有多炫而在于它把 Java Web 后端開(kāi)發(fā)最常用的一整套知識(shí)串了起來(lái)MVC 分層、ORM 框架、事務(wù)管理、文件上傳、權(quán)限控制、前后端聯(lián)調(diào)、部署啟動(dòng)。你把這個(gè)項(xiàng)目吃透自己做畢業(yè)設(shè)計(jì)的時(shí)候完全不需要再到處找模板只需要在這個(gè)基礎(chǔ)上改業(yè)務(wù)字段、加模塊就行——因?yàn)楣羌芤呀?jīng)在你腦子里。