1. 項目概述與整體設(shè)計思路1.1 這個系統(tǒng)到底解決了什么問題先聊聊我做這個項目時的真實感受。校園失物招領(lǐng)這件事聽起來簡單實際上一旦人多起來就特別混亂。我在學(xué)校時見過線下失物招領(lǐng)處的桌子堆滿水杯、雨傘、校園卡失主找一圈翻不到撿到東西的同學(xué)登記完也不知道東西最后有沒有物歸原主。管理老師的臺賬更是一本厚厚的Excel查詢、統(tǒng)計全靠手工效率低到讓人崩潰。所以當時決定把校園失物管理系統(tǒng)作為畢業(yè)設(shè)計時我給自己定的目標不是交一份作業(yè)而是真正能把失物登記、招領(lǐng)管理、認領(lǐng)審核、消息通知、數(shù)據(jù)統(tǒng)計這些環(huán)節(jié)全部線上化形成一套完整的業(yè)務(wù)閉環(huán)。這個系統(tǒng)最終做出來后覆蓋了三個核心用戶角色普通學(xué)生、管理員比如失物招領(lǐng)處的老師以及系統(tǒng)層面的維護人員。從功能上看它做的事情可以概括為三件第一讓撿到東西的人能在幾分鐘內(nèi)完成失物登記并拍照上傳第二讓丟了東西的人能通過關(guān)鍵詞搜索、分類篩選快速鎖定可能找到自己物品的招領(lǐng)信息第三讓管理員能統(tǒng)一審核每一條認領(lǐng)申請防止錯領(lǐng)、冒領(lǐng)。這些聽起來簡單但真正落地時涉及的表結(jié)構(gòu)設(shè)計、權(quán)限控制、狀態(tài)流轉(zhuǎn)、文件上傳、前后端聯(lián)調(diào)每一個環(huán)節(jié)都值得拆開細講。1.2 技術(shù)選型為什么是Spring Boot Vue現(xiàn)在很多同學(xué)做畢設(shè)一上來就問哪個技術(shù)棧最火我個人的看法是對于校園失物管理系統(tǒng)這種典型的CRUD業(yè)務(wù)系統(tǒng)Spring Boot Vue是目前最穩(wěn)妥、資料最全、面試也能講出東西的組合。下面我從三個角度分析一下為什么是這個組合。第一是隔離性。前端Vue負責頁面渲染和交互后端Spring Boot只提供RESTful接口兩邊通過JSON通信。這意味著開發(fā)時可以并行推進我在做后端的時候前端同學(xué)可以拿Mock數(shù)據(jù)先寫頁面效率翻倍。而且以后就算要換個前端框架后端接口不受任何影響。第二是生態(tài)成熟度。Spring Boot在Java后端領(lǐng)域基本是事實標準內(nèi)置Tomcat、自動配置、開箱即用省掉了一大堆XML配置。Vue在前端框架中以學(xué)習曲線平緩著稱配合Element UI組件庫兩天就能把后臺管理頁面的框架搭建起來。對于畢業(yè)設(shè)計這種周期緊湊的項目來說再也不需要去啃那些陳舊過時的SSH集成文檔了。第三是面試有話說。Spring Boot的自動配置原理、起步依賴機制、Vue的響應(yīng)式數(shù)據(jù)綁定、組件通信、路由守衛(wèi)……這些知識點掰開揉碎都能講很久。我后面在面試時被問到談?wù)勀惝厴I(yè)設(shè)計的技術(shù)難點直接就能把認領(lǐng)審核的狀態(tài)流轉(zhuǎn)、圖片上傳的處理流程拿出來講比背八股文不知道強了多少倍。1.3 功能模塊劃分與權(quán)限設(shè)計整個系統(tǒng)在功能上劃分為兩大端用戶端和管理端。用戶端面向所有在校學(xué)生功能包括用戶注冊登錄、掛失信息發(fā)布、招領(lǐng)信息發(fā)布、搜索與分類篩選、在線認領(lǐng)申請、個人中心管理我發(fā)布的、我認領(lǐng)的。管理端面向管理員功能包括成員管理用戶禁用/啟用、掛失管理、招領(lǐng)管理、認領(lǐng)審核、公告發(fā)布、數(shù)據(jù)統(tǒng)計面板。這里我重點講講權(quán)限設(shè)計。用戶端和管理員雖然登錄入口是一樣的但進入系統(tǒng)后看到的菜單和可操作接口完全不同。我在后端通過攔截器加Token校驗的方式做了兩層控制第一層是登錄校驗所有的 /api/** 接口除了注冊登錄外都要求請求頭攜帶Token否則直接返回401第二層是角色校驗只有管理員Token才能訪問 /admin/** 的接口普通用戶訪問時返回403。前端的配合是在路由配置里加了meta標記{ path: /admin, component: Layout, meta: { requiresAdmin: true }, children: [...] }然后在全局前置守衛(wèi)里校驗用戶信息里的role字段。前后端雙重校驗保證就算有人繞過前端直接調(diào)用接口后端也會攔截住這一點對答辯時的安全性質(zhì)詢尤其關(guān)鍵。2. 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計與后端核心實現(xiàn)2.1 遵循高內(nèi)聚低耦合的數(shù)據(jù)庫設(shè)計數(shù)據(jù)庫是整個系統(tǒng)的地基。我在設(shè)計時把核心表拆成了六張用戶表user、掛失表lost_item、招領(lǐng)表found_item、認領(lǐng)申請記錄表claim_record外加留言表message和公告表notice。用戶表是基礎(chǔ)字段包含id、用戶名、密碼BCrypt加密存儲、昵稱、學(xué)號/工號、聯(lián)系電話、角色0學(xué)生 1管理員、狀態(tài)0正常 1禁用、創(chuàng)建時間。注意密碼一定不能明文存Spring Security自帶的BCryptPasswordEncoder可以拿來直接用。掛失表和招領(lǐng)表結(jié)構(gòu)類似都包含物品名稱、物品分類、物品描述、丟失/拾取地點、丟失/拾取時間、圖片URL、聯(lián)系QQ或微信、狀態(tài)、發(fā)布人ID、發(fā)布時間。區(qū)別在于業(yè)務(wù)性質(zhì)和狀態(tài)流轉(zhuǎn)不同掛失信息的物品是等待被認領(lǐng)的而招領(lǐng)信息里的物品是等待失主來認領(lǐng)的。這里我反而建議把失物和招領(lǐng)拆成兩張表不要圖省事合并因為后續(xù)擴展場景、統(tǒng)計口徑完全不一樣。認領(lǐng)申請記錄表是關(guān)鍵表。兩個外鍵分別指向失主或者拾主用戶ID、招領(lǐng)/掛失物品ID外加申請說明、申請時間、處理狀態(tài)0待審核 1已通過 2已駁回、審核備注、審核時間。這張表承載了系統(tǒng)最重要的業(yè)務(wù)邏輯建議所有新建表都加上create_time和update_time字段別問為什么做過的都懂。2.2 Spring Boot工程結(jié)構(gòu)要怎么搭才不亂工程結(jié)構(gòu)這塊因為是一個單體項目我建議用經(jīng)典的分層架構(gòu)Controller - Service - Mapper三層。不過在實際寫的時候三層之間最好加一層DTO/VO的轉(zhuǎn)換不要在Controller層直接暴露出數(shù)據(jù)庫實體字段。舉一個很重要的例子我們查詢招領(lǐng)列表時最多返回物品信息加發(fā)布人昵稱但絕對不應(yīng)該把發(fā)布人的密碼字段序列化出去。所以我專門寫了ItemVO類只包含前端需要的字段并在Service層完成從Entity到VO的轉(zhuǎn)換。核心的pom.xml依賴只需要這幾個起步依賴就足夠了spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok、spring-boot-starter-validation。配一個application.yml的示例server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/campus_lost_found?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 10MB max-request-size: 50MB mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImplMyBatis Plus用起來確實省心BaseMapper已經(jīng)把單表的增刪改查全都封裝好了我們只需要在Service里寫業(yè)務(wù)邏輯。但有一點必須說明MyBatis Plus的駝峰映射默認是開啟的如果你的數(shù)據(jù)庫字段是下劃線風格比如create_time實體類是駝峰風格createTime它幫我們自動轉(zhuǎn)換完全不用額外配置。2.3 核心業(yè)務(wù)邏輯認領(lǐng)審核的狀態(tài)流轉(zhuǎn)認領(lǐng)審核是整個系統(tǒng)業(yè)務(wù)邏輯最復(fù)雜的部分我用一個狀態(tài)機來管理。所謂狀態(tài)機本質(zhì)上就是把業(yè)務(wù)狀態(tài)的變化提煉成一個單向流轉(zhuǎn)圖讓代碼的每一次狀態(tài)變更都有據(jù)可依而不是隨手亂改。拿招領(lǐng)物品被認領(lǐng)這個流程舉例。拾主發(fā)布一條招領(lǐng)信息后物品狀態(tài)是待認領(lǐng)。學(xué)生在詳情頁看到物品點擊認領(lǐng)申請按鈕填寫自己的憑證說明比如校園卡號、物品特征這時系統(tǒng)會生成一條claim_record記錄狀態(tài)是待審核同時物品本身狀態(tài)不變。管理員在后臺看到待審核的申請后點通過claim_record狀態(tài)變成已通過物品狀態(tài)變成待領(lǐng)取隨后失主線下拿到物品拾主或者管理員在系統(tǒng)里點擊確認物品狀態(tài)才最終變成已完成。如果管理員審核不通過claim_record狀態(tài)變?yōu)橐疡g回物品狀態(tài)恢復(fù)為待認領(lǐng)。業(yè)務(wù)上還有一個比較關(guān)鍵的約束同一件物品只能有一條審核通過的認領(lǐng)記錄。這個約束我在claim_record表上做了一個聯(lián)合唯一索引防止并發(fā)情況下出現(xiàn)同一件物品被多個人同時認領(lǐng)成功的問題。我給出一個簡化版的Service代碼Transactional public boolean claimItem(Long userId, Long foundItemId, String claimReason) { // 1. 校驗物品是否存在且狀態(tài)為待認領(lǐng) FoundItem item foundItemMapper.selectById(foundItemId); if (item null || item.getStatus() ! 0) { throw new RuntimeException(物品不存在或已被認領(lǐng)); } // 2. 檢查用戶是否已經(jīng)認領(lǐng)過該物品 Integer count claimRecordMapper.selectCount( new LambdaQueryWrapperClaimRecord() .eq(ClaimRecord::getUserId, userId) .eq(ClaimRecord::getFoundItemId, foundItemId) .eq(ClaimRecord::getStatus, 0)); if (count 0) { throw new RuntimeException(請勿重復(fù)申請); } // 3. 插入認領(lǐng)申請記錄 ClaimRecord record new ClaimRecord(); record.setUserId(userId); record.setFoundItemId(foundItemId); record.setClaimReason(claimReason); record.setStatus(0); claimRecordMapper.insert(record); return true; }這里有幾個細節(jié)需要特別提醒。第一非查詢接口建議都加上Transactional事務(wù)注解這樣一旦中間拋異常數(shù)據(jù)庫不會留下臟數(shù)據(jù)。第二業(yè)務(wù)狀態(tài)在代碼中不要寫死數(shù)字建議用一個枚舉類比如ItemStatusEnum、ClaimStatusEnum管理閱讀起來清晰也不容易出錯。第三LambdaQueryWrapper的寫法比普通的字符串QueryWrapper安全因為它是編譯期檢查字段名不會出現(xiàn)拼錯字段導(dǎo)致運行時報錯的問題。2.4 圖片上傳與訪問路徑處理失物照片和招領(lǐng)照片是系統(tǒng)的核心信息載體但在Spring Boot中實現(xiàn)圖片上傳有幾個坑必須要說。我當時的實現(xiàn)方式是這樣的controller接收MultipartFile文件校驗非空、校驗大小限制10MB以內(nèi)、校驗擴展名只允許jpg/png/gif/webp然后用UUID生成新文件名避免重名。保存路徑采用本地磁盤存儲springBoot啟動時在用戶目錄下創(chuàng)建一個upload文件夾文件按日期分子目錄存放比如2025/01/15/xxxxx.jpg。文件上傳成功后把相對訪問路徑比如 /upload/2025/01/15/xxx.jpg存入數(shù)據(jù)庫的img字段。接下來要讓前端能訪問到這個圖片必須配置靜態(tài)資源映射。在Spring Boot中只需要實現(xiàn)WebMvcConfigurer接口重寫addResourceHandlers方法Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath System.getProperty(user.dir) File.separator upload File.separator; registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); }一個最容易踩的坑是開發(fā)時直接用了前端Vue的8080端口或者后端的8080端口當你把圖片url寫死為localhost時部署到服務(wù)器后全是裂圖。這里最穩(wěn)妥的做法是后端接口返回圖片時只返回相對路徑 /upload/xxx.jpg由前端根據(jù)當前環(huán)境拼接完整的訪問前綴。比如我在Vue中封裝一個全局變量開發(fā)環(huán)境寫 http://localhost:8080生產(chǎn)環(huán)境就改成服務(wù)器地址。3. Vue前端架構(gòu)與頁面交互實現(xiàn)3.1 前端工程化搭建與Axios封裝前端我用的Vue 2如果現(xiàn)在重新做我會直接用Vue 3 Vite但對于畢設(shè)來說Vue 2的生態(tài)最穩(wěn)、資料最多React的同學(xué)請繞道。在創(chuàng)建工程時直接用Vue CLI腳手架vue create campus-lost-found然后安裝Vue Router、Vuex/A PiniaVue 2用Vuex 3UI組件庫選擇Element UI。Element UI對Vue 2的支持非常成熟Table、Form、DatePicker這些組件拿來即用管理后臺的開發(fā)效率直接起飛。網(wǎng)絡(luò)請求這塊強烈建議在axios實例上做統(tǒng)一封裝而不是每個組件里直接調(diào)用axios。我在src/utils/request.js里創(chuàng)建了一個axios實例設(shè)置了baseURL為 /api然后加請求攔截器和響應(yīng)攔截器。請求攔截器里從localStorage拿Token放到請求頭Authorization。響應(yīng)攔截器里統(tǒng)一處理錯誤碼401跳登錄頁403提示無權(quán)限500提示服務(wù)器異常。后端約定的響應(yīng)格式是{ code: 200, message: success, data: { } }攔截器里直接return response.data.data讓業(yè)務(wù)代碼拿到的直接就是真正的數(shù)據(jù)對象代碼干凈很多。另外很多新手容易忽略的是axios默認不會攜帶Cookie如果你用JWT方案其實關(guān)系不大但如果你用Session方案一定要在axios配置里加上 withCredentials: true。3.2 頁面模塊劃分與前端路由設(shè)計前端頁面我劃分成兩大類面向普通用戶的C端頁面和面向管理員的后臺頁面。C端頁面包括登錄注冊頁、首頁招領(lǐng)信息流、掛失大廳失物信息流、物品詳情頁、發(fā)布頁、個人中心我發(fā)布的、我認領(lǐng)的、我的留言。管理端頁面包括工作臺數(shù)據(jù)統(tǒng)計、招領(lǐng)審核列表、掛失列表、用戶管理、公告管理。前端路由要配合后端權(quán)限做控制。C端的頁面游客也可以訪問但發(fā)布信息和認領(lǐng)申請必須登錄管理端的頁面必須有管理員身份才能進入。我用Vue Router的全局前置守衛(wèi)實現(xiàn)router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next({ path: /login, query: { redirect: to.fullPath } }) return } if (to.meta.requiresAdmin) { const role localStorage.getItem(role) if (role ! 1) { next({ path: /403 }) return } } next() })一個比較關(guān)鍵的體驗優(yōu)化是登錄之后不要簡單地跳回首頁而是用redirect參數(shù)記錄用戶原本想訪問的頁面登錄成功后直接跳回去。這個小細節(jié)對用戶體驗的提升非常明顯也是我入職之后帶新人時經(jīng)常強調(diào)的點。3.3 發(fā)布表單與圖片多圖上傳的實現(xiàn)細節(jié)發(fā)布招領(lǐng)信息頁面是整個系統(tǒng)使用頻率最高的功能之一它的核心是表單校驗和圖片上傳。Element UI的Form組件自帶校驗規(guī)則我在數(shù)據(jù)里定義了rulesrules: { title: [{ required: true, message: 請?zhí)顚懳锲访Q, trigger: blur }], category: [{ required: true, message: 請選擇物品類型, trigger: change }], location: [{ required: true, message: 請?zhí)顚懯叭〉攸c, trigger: blur }], description: [{ required: true, message: 請?zhí)顚懳锲访枋? trigger: blur }] }上傳組件用的是el-upload這里特別要說的是不要用el-upload默認的action上傳方式而是設(shè)置 :auto-uploadfalse手動把文件讀到FormData里和表單數(shù)據(jù)一起提交給后端。這樣做的好處是接口只需要一個避免圖片先傳、表單后傳導(dǎo)致的數(shù)據(jù)不一致問題。如果需要支持同時上傳多張圖片可以遍歷文件列表把多個文件append到同一個FormData中。核心代碼示意const formData new FormData() formData.append(title, form.title) formData.append(category, form.category) formData.append(location, form.location) formData.append(description, form.description) for (const file of fileList) { formData.append(files, file.raw) } // 注意這里不能直接設(shè)置 Content-Type: application/json axios.post(/api/found/add, formData, { headers: { Content-Type: multipart/form-data } })踩過好幾次坑后的心得是用FormData傳文件時千萬不能讓axios自動序列化否則后端會解析不到文件字段。同時后端多文件的接收參數(shù)名要和前端append的key保持一致。4. 前后端聯(lián)調(diào)核心場景實操復(fù)盤4.1 從發(fā)布招領(lǐng)信息到列表展示的完整鏈路我把系統(tǒng)里最核心的一條鏈路完整走一遍方便你照著測試。假設(shè)我現(xiàn)在拾到了一張校園卡登錄系統(tǒng)后進入發(fā)布招領(lǐng)信息頁面填寫物品類型為證件類標題為一食堂門口拾到校園卡地點填第一食堂描述補充卡套是藍色的應(yīng)該是某某學(xué)院的同學(xué)上傳兩張照片后點擊提交。前端做的事情是把表單數(shù)據(jù)整理成FormData發(fā)給 POST /api/found/add。后端的流程是攔截器校驗登錄狀態(tài)Controller接收參數(shù)并做參數(shù)校驗Service層把圖片文件保存到服務(wù)器磁盤、生成訪問URL然后把物品信息插入數(shù)據(jù)庫found_item表。返回結(jié)果中帶上新創(chuàng)建的物品ID。然后我回到首頁首頁加載時調(diào)用 GET /api/found/list?page1size10keyword校園卡。后端Service層先根據(jù)條件分頁查詢再把每條記錄的發(fā)布人昵稱關(guān)聯(lián)查出來組裝成ItemVO最后返回分頁對象。前端拿到數(shù)據(jù)后渲染成卡片列表。整個鏈路測試通過就說明最核心的寫入-查詢鏈路是通的正。4.2 認領(lǐng)申請到管理員審核的流程演示接下來模擬失主來認領(lǐng)。另一個學(xué)生登錄系統(tǒng)后在首頁搜索校園卡找到剛才那條招領(lǐng)信息點進詳情頁調(diào)出認領(lǐng)申請彈窗。彈窗里要填寫聯(lián)系方式、認領(lǐng)說明比如我的卡號尾號是8821應(yīng)該有校園卡卡套。提交后調(diào)用 POST /api/claim/add后端創(chuàng)建一條狀態(tài)為待審核的認領(lǐng)記錄同時給這條招領(lǐng)信息增加一條處理中的標記。管理員登錄后臺在認領(lǐng)審核列表中看到這條申請記錄。審核列表頁面的核心是數(shù)據(jù)回顯和操作按鈕。管理員點擊查看詳情能夠看到物品的照片與描述、申請人的學(xué)號與聯(lián)系方式、認領(lǐng)理由。這些數(shù)據(jù)來自三個表的信息拼裝后端用一個ClaimDetailVO搞定。確認沒問題后審核通過此時物品狀態(tài)從待認領(lǐng)變成待領(lǐng)取。失主線下領(lǐng)走物品之后管理員再點一次確認完成整個流程結(jié)束。這個流程在聯(lián)調(diào)時最容易出現(xiàn)的問題就是狀態(tài)更新不及時。比如用戶申請成功后前端頁面還顯示著待認領(lǐng)這是因為詳情頁是在申請成功之前請求的數(shù)據(jù)沒有刷新。解決方案就是申請成功后跳轉(zhuǎn)回列表頁或重新拉取詳情數(shù)據(jù)不要停留在舊的狀態(tài)里。4.3 管理后臺的統(tǒng)計報表與導(dǎo)出功能管理后臺除了審核之外還有一塊很重要的能力是數(shù)據(jù)統(tǒng)計。我在工作臺頁面用ECharts做了兩個可視化圖表一個是近六個月的招領(lǐng)信息發(fā)布趨勢折線圖一個是物品分類占比餅圖。后端提供兩個統(tǒng)計接口分別是 GET /admin/stats/trend 和 GET /admin/stats/category。趨勢圖的實現(xiàn)是統(tǒng)計最近六個月每個月新增的招領(lǐng)和掛失數(shù)量前端用ECharts的Line圖展示雙折線。分類占比則是從物品表里按category分組聚合前端用Pie圖展示。說句實話畢業(yè)設(shè)計里圖表功能是加分項但也是最容易翻車的因為接口數(shù)據(jù)結(jié)構(gòu)和圖表組件的數(shù)據(jù)要求經(jīng)常對不上。我的經(jīng)驗是不急著寫圖表組件先定好接口的返回結(jié)構(gòu)用Postman把接口調(diào)試好然后再寫前端。餅圖的數(shù)據(jù)格式是 [{name: 證件類, value: 35}]折線圖的數(shù)據(jù)格式是 {months: [2024-08, ...], lost: [..], found: [..]}后端設(shè)計返回結(jié)構(gòu)時就要和前端對齊。5. 常見問題排查與避坑指南5.1 跨域問題導(dǎo)致的接口請求失敗前后端分離項目最常見的問題就是跨域。如果在瀏覽器控制臺看到 blocked by CORS policy 或者 Access to XMLHttpRequest has been blocked基本就是跨域問題。解決辦法有很多種最推薦的是在后端寫一個CorsConfig配置類統(tǒng)一放行Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }這里幾個要點allowedOriginPatterns() 配合 allowCredentials(true) 一定要這樣寫直接 allowedOrigins() 再配合 credentials 會有兼容性問題。還有如果項目里引入了Spring Security跨域配置還要在SecurityConfiguration里也放行OPTIONS請求否則預(yù)檢請求過不去。另一種辦法是開發(fā)時用Vue CLI的代理功能在vue.config.js里配置proxy轉(zhuǎn)發(fā)把 /api 前綴的請求轉(zhuǎn)發(fā)到后端的8080端口。但要注意這只在開發(fā)環(huán)境生效生產(chǎn)環(huán)境還是要靠后端處理跨域。5.2 圖片上傳成功但訪問404這個問題的典型場景是上傳接口返回了文件相對路徑但瀏覽器訪問 http://localhost:8080/upload/xxx.jpg 時404。排查步驟按照我的經(jīng)驗分三步走。第一步確認文件是否真的保存到了磁盤指定目錄?？梢栽谙到y(tǒng)的用戶目錄或項目根目錄下檢查是否有upload文件夾以及文件是否存在。第二步確認靜態(tài)資源映射是否生效。在配置類里加了addResourceHandlers之后還要確認這個配置類組件有沒有被Spring掃描到。如果配置類放在了子包外面Spring Boot默認是掃描不到這是一個很低級但很容易犯的錯。第三步檢查路徑匹配。比如攔截器里是否對 /upload/** 路徑做了攔截把圖片請求給攔截下來返回了401或404。我遇到過最隱蔽的一種情況是文件路徑里的Linux和Windows差異。開發(fā)時在Windows下寫的是 File.separator 拼路徑部署到Linux服務(wù)器后路徑分隔符雖然自動變成/但應(yīng)用權(quán)限不夠?qū)е挛募]能寫入服務(wù)器目錄。這種情況通常看應(yīng)用報錯日志Permission denied字樣非常明顯。5.3 Long類型主鍵返回前端精度丟失這個坑非常經(jīng)典我當時排查了大半天。情況是這樣的我用MyBatis Plus默認的ASSIGN_ID策略生成雪花ID作為數(shù)據(jù)表主鍵這個ID長度超過JavaScript的Number最大安全整數(shù)2^53-1。前端從接口收到ID后最后一位的精度丟失變成了幾個0。在列表頁點擊某個物品想查看詳情時傳回給后端的ID已經(jīng)不是真實ID了結(jié)果查不到數(shù)據(jù)。解決辦法很簡單在Jackson序列化時把Long類型轉(zhuǎn)成String類型給前端一個字符串形式的ID。兩種實現(xiàn)方式一種是在配置里配置全局的ToStringSerializer另一種是在實體類的ID字段上加注解 JsonSerialize(using ToStringSerializer.class)。我推薦第二種只在需要的主鍵字段上加避免影響其它Long字段的語義。5.4 新手最容易犯的10個低級錯誤這里把我這幾年看到的、自己做過的錯誤整理成一張速查表建議收藏錯誤描述具體表現(xiàn)正確做法數(shù)據(jù)庫表名和實體類名不一致啟動時報Table找不到用TableName注解顯式指定表名前端請求參數(shù)名和后端不一致接口返回參數(shù)為null統(tǒng)一使用DTO層規(guī)范字段命名未處理空指針列表頁獲取某個對象的名稱時報500關(guān)鍵查詢用Optional或判空MyBatis Plus分頁插件未配置分頁查詢不生效返回所有數(shù)據(jù)配置MybatisPlusInterceptor加PaginationInnerInterceptor密碼明文存儲數(shù)據(jù)庫里密碼直接可見使用BCrypt加密存儲刪除數(shù)據(jù)用物理刪除誤刪后無法恢復(fù)邏輯刪除字段deletedMyBatis Plus支持前端上傳文件未限制類型用戶上傳一個.exe文件后端和前端都校驗文件擴展名查詢接口不處理時間參數(shù)時區(qū)時間相差8小時JDBC連接串加serverTimezoneAsia/Shanghai缺少全局異常處理器一個異常導(dǎo)致整個系統(tǒng)報錯用RestControllerAdvice統(tǒng)一處理后端接口不返回統(tǒng)一格式前端每個接口都要判斷狀態(tài)碼定義統(tǒng)一Result類code/message/data5.5 答辯時容易被追問的5個系統(tǒng)設(shè)計問題最后分享一個實際經(jīng)歷。答辯時老師一般不會讓你現(xiàn)場敲代碼更多的是針對系統(tǒng)的設(shè)計合理性提問。我總結(jié)幾個高頻問題和你應(yīng)該準備的回答思路第一個問題是數(shù)據(jù)庫表為什么這樣設(shè)計回答時抓住三點主鍵用雪花ID保證全局唯一所有表都有創(chuàng)建時間和更新時間字段方便后期維護核心關(guān)聯(lián)字段建立外鍵索引保證查詢效率。第二個問題是如果并發(fā)量變大系統(tǒng)哪里會成為瓶頸這個問題是送分題你可以說目前本地部署的學(xué)生訪問量不大數(shù)據(jù)庫是主要瓶頸可以采用分庫分表方案同時把圖片上傳到對象存儲服務(wù)引入Redis做熱點數(shù)據(jù)的緩存。第三個問題是密碼傳輸安全如何保證回答思路是前端用HTTPS對外部署時密碼傳輸時可以加鹽加密后端使用BCrypt算法存儲摘要數(shù)據(jù)庫泄露也無法反推出明文密碼。第四個問題是你和別人做的一樣你的亮點是什么不要謙虛明確說出來清晰的認領(lǐng)狀態(tài)機設(shè)計、前后端權(quán)限雙重校驗、ECharts統(tǒng)計報表、統(tǒng)一的異常處理體系這些就是你的亮點。第五個問題是系統(tǒng)上線部署需要哪些環(huán)境答Java運行環(huán)境、MySQL數(shù)據(jù)庫、Node.js構(gòu)建前端、Nginx做靜態(tài)資源服務(wù)器和反向代理有Docker的話可以直接容器化部署。我做完這個項目之后最大的感受是校園失物管理系統(tǒng)表面上是常見的增刪改查但真正把一個業(yè)務(wù)閉環(huán)做完、做順需要的是前后端聯(lián)調(diào)的全局觀。很多同學(xué)在做畢設(shè)時容易陷入一個誤區(qū)就是文檔寫得天花亂墜代碼卻沒有跑通。這套系統(tǒng)如果能真正做到可以演示、可以答辯、可以部署它就不只是一個畢業(yè)設(shè)計的源碼而是一份完整的全棧實戰(zhàn)經(jīng)驗。我遇到過好幾次驗收的時候管理員從發(fā)布到審核完整體驗一遍流程通暢時那種成就感比拿到優(yōu)秀畢設(shè)證書還爽。