1. 選題思路與整體技術架構(gòu)1.1 為什么點餐系統(tǒng)適合做畢業(yè)設計這幾年指導過的畢業(yè)設計里點餐系統(tǒng)幾乎是“常青樹”選題。原因很直接業(yè)務模型完整但不過度復雜恰好覆蓋了前后端分離開發(fā)的大部分核心知識點。一個用戶能注冊登錄、瀏覽菜品、加購物車、下單付款管理員能維護菜品、處理訂單這套流程足夠撐起一篇有含金量的論文又不會像電商系統(tǒng)那樣為了湊復雜度硬塞一堆用不上的模塊。關鍵要清楚點餐系統(tǒng)不是“做個網(wǎng)頁賣飯”它的本質(zhì)是一套交易系統(tǒng)的簡化模型。要處理的核心問題包括用戶身份認證、商品數(shù)據(jù)管理、訂單狀態(tài)流轉(zhuǎn)、庫存一致性、支付回調(diào)處理模擬即可、并發(fā)場景下的數(shù)據(jù)安全。把這些點想明白寫論文和答辯時才有東西可講不是對著界面截圖干說“我做了個網(wǎng)站”。技術棧選SpringBootVue是目前最穩(wěn)妥的組合。SpringBoot生態(tài)成熟、資料多、招人問得多Vue對新手友好、組件化開發(fā)直觀。前后端分離也是真實企業(yè)開發(fā)的主流形態(tài)做完這套東西拿得出手的技能棧比用JSPServlet老方案的同學明顯扎實一截。1.2 整體架構(gòu)和模塊劃分系統(tǒng)按常見的“用戶端管理端”雙端設計這是點餐系統(tǒng)的標準切法。用戶端核心模塊包括注冊登錄、菜品瀏覽與分類篩選、購物車管理、訂單提交與支付模擬、訂單歷史查詢、個人資料修改。管理端核心模塊包括管理員登錄、菜品CRUD增刪改查、分類管理、訂單處理接單/完成/取消、簡單的數(shù)據(jù)統(tǒng)計。前后端如何劃分是重點。SpringBoot只負責提供RESTful API接口不返回任何頁面Vue負責渲染界面、交互邏輯、路由跳轉(zhuǎn)。兩邊通過JSON格式的數(shù)據(jù)交互。這里要特別強調(diào)一個觀念前端是“展示層輕邏輯”后端是“數(shù)據(jù)層核心業(yè)務規(guī)則”。比如“下單”這個動作前端做的事情是收集購物車數(shù)據(jù)、請求下單接口、展示結(jié)果而“庫存是否足夠”“訂單狀態(tài)是否允許取消”這類規(guī)則判斷必須放在后端絕不能依賴前端傳參或前端判斷。數(shù)據(jù)庫設計上核心表不用多但每張都要有存在價值。我通常建議至少五張表用戶表user、菜品分類表category、菜品表dish、訂單表orders、訂單明細表order_detail外加購物車表cart和可選的地址表address。重點說下訂單和訂單明細為什么要拆兩張表一個訂單包含多個菜品如果把菜品信息直接塞進訂單表一個字段存多個菜品ID查詢、統(tǒng)計、修改都極其痛苦。拆成明細表后訂單主表只存訂單總額、狀態(tài)、時間這些訂單級信息明細表每個菜品一行記錄綁訂單ID。這也是工作中最基礎的表設計訓練。1.3 技術選型背后的取舍邏輯單純羅列技術棧沒有意義重要的是知道為什么這么選。后端SpringBoot選2.x版本而不是3.x主要考慮生態(tài)兼容性。3.x要求JDK17起步很多教材、博客、開源工具還停留在舊版本畢設階段沒必要在這上面給自己挖坑。SpringBoot 2.7.x JDK8或JDK11穩(wěn)定且資料多出問題一搜就有答案。持久層框架在MyBatis-Plus和Spring Data JPA之間我更推薦MyBatis-Plus。原因很實際點餐系統(tǒng)的SQL大多是單表CRUD和簡單的多表聯(lián)查MyBatis-Plus的BaseMapper直接幫你把增刪改查寫完了省下大量重復代碼。條件構(gòu)造器做動態(tài)查詢也很順手。JPA雖然開發(fā)效率同樣不低但關聯(lián)關系配置和懶加載的坑對新手不夠友好調(diào)試成本高。前端Vue選Vue2還是Vue3要慎重。如果現(xiàn)在開始做建議直接上Vue3 Element Plus。Vue3是當前主流Vue2生態(tài)已經(jīng)停止維護做畢設沒必要用馬上過時的技術。組合式API剛開始寫可能不習慣但堅持寫兩周就會覺得比選項式API更適合邏輯復用。配套的Element Plus做后臺管理界面非?？毂砀?、表單、彈窗都是現(xiàn)成組件顏值也在線。數(shù)據(jù)庫無腦選MySQL版本8.0以上。開發(fā)環(huán)境用Navicat或DataGrip管理數(shù)據(jù)庫本地跑就行不需要單獨裝服務器。2. 后端核心模塊設計與關鍵細節(jié)2.1 用戶認證從Session到JWT用戶認證是幾乎所有系統(tǒng)第一個要解決的問題。點餐系統(tǒng)用戶端要登錄管理端也必須登錄但兩者權(quán)限不同這就涉及權(quán)限區(qū)分。傳統(tǒng)做法是SessionCookie服務器存會話返回一個SessionId給瀏覽器。前后端分離的架構(gòu)下更推薦用JWTJSON Web Token。核心邏輯是用戶登錄成功后后端用密鑰生成一個包含用戶信息的加密Token返回給前端前端每次請求帶著Token后端驗簽確認身份。這樣做的好處是服務器無狀態(tài)不用維護會話記錄非常適合多端瀏覽器、手機接入的場景缺點是Token如果被盜用在過期之前都能被使用所以一定要設置合理的過期時間。具體實現(xiàn)用現(xiàn)成工具不需要自己手寫加密邏輯。引入jjwt依賴寫一個JwtUtil工具類包含三個核心方法生成Token、解析Token、判斷Token是否有效。Token里放什么信息有講究我習慣只放用戶ID、用戶名、角色不放密碼等敏感數(shù)據(jù)。權(quán)限控制怎么做是關鍵。寫一個攔截器實現(xiàn)HandlerInterceptor接口在preHandle方法里從請求頭取Authorization字段解析Token成功了放行失敗了返回401狀態(tài)碼。然后寫一個WebMvcConfigurer配置類注冊攔截器并指定攔截路徑——管理端接口全攔截用戶端部分接口攔截。有一個常見問題是前后端聯(lián)調(diào)時前端因為響應攔截器處理不當Token失效時頁面不跳轉(zhuǎn)登錄頁而是停留在當前頁面報錯這個后面排查部分會提到。2.2 菜品管理與文件上傳的取舍菜品管理是管理端最基礎的功能核心是CRUD加上傳菜品圖片。大多數(shù)學生在這里犯的第一個錯誤是沒有區(qū)分“邏輯刪除”和“物理刪除”。刪除菜品如果直接從數(shù)據(jù)庫DELETE數(shù)據(jù)的完整性就破壞了。比如用戶已經(jīng)下過單訂單詳情關聯(lián)了菜品ID菜品被刪了訂單歷史查詢就會關聯(lián)失敗。生產(chǎn)環(huán)境幾乎都是邏輯刪除——給表加一個status字段1表示正常、0表示刪除刪除操作只是把status改成0查詢時默認過濾掉。MyBatis-Plus支持TableLogic注解配置后deleteById方法自動變成update語句非常方便。圖片上傳這塊SpringBoot接收MultipartFile保存到本地指定目錄然后返回圖片的URL路徑。這里要注意兩點一個是保存路徑不要寫死絕對路徑用配置項維護方便換環(huán)境另一個是URL映射配置。默認情況下SpringBoot訪問不到本地磁盤的文件需要寫一個配置類繼承WebMvcConfigurer重寫addResourceHandlers方法把虛擬路徑/api/image/**映射到真實存儲目錄。這個坑幾乎每個學生都踩一次報404或圖片不顯示八成就是這里沒配。菜品分頁查詢直接使用MyBatis-Plus的Page對象配合LambdaQueryWrapper做條件篩選。管理端查詢可以按分類篩選、按狀態(tài)篩選、按名稱模糊查詢這些條件組合也是前端篩選組件的數(shù)據(jù)來源。需要注意分頁參數(shù)要單獨封裝一個PageQuery對象而不是Map接收這樣前端傳參結(jié)構(gòu)清晰后端參數(shù)校驗也好做。2.3 購物車與訂單事務與狀態(tài)機購物車其實就是一個臨時存儲數(shù)據(jù)的過程表結(jié)構(gòu)相對固定主鍵、用戶ID、菜品ID、數(shù)量、加購時間。還要冗余一個菜品名稱和單價字段這樣購物車列表展示時不需要聯(lián)查菜品表性能好萬一菜品被刪了也不影響購物車歷史數(shù)據(jù)的展示。訂單模塊是整個系統(tǒng)的重量級模塊也是最容易出問題的部分。下單接口的流程是前端傳來購物車數(shù)據(jù)后端校驗每個菜品是否存在、狀態(tài)是否正常然后計算總價創(chuàng)建訂單主記錄再循環(huán)插入訂單明細最后清空購物車。這里必須加事務注解Transactional保證“創(chuàng)建訂單、插入明細、清空購物車”三個操作要么全部成功、要么全部失敗。不加事務的后果就是訂單建了明細沒插進去或者明細插了購物車沒清掉演示的時候特別尷尬。庫存扣減也是畢設答辯容易追問的點。我當時做的是下單時判斷菜品是否還有庫存夠則扣減不夠則提示菜品已售罄。這個邏輯看起來沒問題但并發(fā)場景下會出問題——兩個用戶同時下單同一個菜都查到了庫存為1都執(zhí)行扣減結(jié)果庫存變成-1。解決方案是扣庫存時要使用樂觀鎖加一個version字段執(zhí)行update時要帶上版本條件影響行數(shù)為0則說明已經(jīng)被別人改過了報錯重試。雖然畢設項目的并發(fā)量達不到這么極端但把這套邏輯說出來答辯時就是加分項。訂單狀態(tài)我用一個整數(shù)類型status字段表示定義一個狀態(tài)枚舉類1表示待支付、2表示已支付/待接單、3表示制作中/已接單、4表示已完成、5表示已取消、6表示已退款。為什么不用字符串一方面存儲空間小查詢快另一方面狀態(tài)定義集中在枚舉類里不會出現(xiàn)各處魔法數(shù)字滿天飛的情況。狀態(tài)流轉(zhuǎn)必須有嚴格的規(guī)則比如已完成的訂單不能再取消已取消的不能再接單這些判斷邏輯放在Service層接口層不做任何業(yè)務判斷。2.4 數(shù)據(jù)統(tǒng)計怎么做到簡單但有用管理端首頁放幾個數(shù)據(jù)卡片是很多畢設的標配。銷量統(tǒng)計、營業(yè)額、熱銷菜品排名這些數(shù)據(jù)看起來復雜其實SQL幾行就能寫出來。關鍵是用對聚合函數(shù)和分組。日營業(yè)額就是按日期分組求和訂單金額限定訂單狀態(tài)不是“已取消”的。熱銷菜品要關聯(lián)訂單明細表按菜品ID分組SUM數(shù)量倒序排LIMIT取前十。注意做統(tǒng)計查詢時日期范圍通常用前端傳參控制后端只負責接收開始日期和結(jié)束日期在Service層組裝SQL條件。這個模塊不需要做得太重簡單幾組圖表就夠。真正想加分的話可以做一張每日訂單量趨勢圖前端用ECharts的折線圖展示后端寫一個接口返回最近七天的訂單數(shù)和營業(yè)額。講明白“按時間粒度聚合”的思路就是一篇可圈可點的設計說明。3. 前端工程與核心界面實現(xiàn)3.1 Vue3工程結(jié)構(gòu)和基礎設施搭建前端工程用Vite構(gòu)建比Webpack快的不是一點半點配置也極簡。項目結(jié)構(gòu)我習慣分四塊src/api放接口請求封裝、src/router放路由配置、src/store放全局狀態(tài)、src/views放頁面組件另外src/components放公共組件、src/utils放工具函數(shù)。路由設計要區(qū)分用戶端和管理端。用戶端包括登錄注冊頁、點餐首頁、菜品分類頁、購物車頁、訂單確認頁、訂單列表頁、個人中心頁管理端包括登錄頁、系統(tǒng)布局頁側(cè)邊欄頂欄、菜品管理頁、分類管理頁、訂單管理頁、數(shù)據(jù)統(tǒng)計頁。這里要注意嵌套路由的用法管理端子頁面都套在一個Layout組件下面?zhèn)冗厵诤晚敊诓挥弥貜蛯?。路由守衛(wèi)是每個前端項目必須處理的環(huán)節(jié)。Vue Router提供了beforeEach導航守衛(wèi)在跳轉(zhuǎn)之前判斷用戶是否有權(quán)訪問目標路由。邏輯是檢查目標路由的meta是否需要登錄需要的話再檢查本地存儲有沒有Token沒有就跳登錄頁。如果是管理端路由還要額外檢查用戶角色是否為管理員。這個邏輯看起來不復雜但它決定了前端的“第一道安全門”雖然不是真正的安全但至少攔住手動改路由路徑的直訪。Axios請求封裝要統(tǒng)一處理BaseURL、請求頭注入、響應狀態(tài)碼分發(fā)做到全項目只維護一份HTTP邏輯。請求攔截器里從localStorage取Token塞進Authorization頭響應攔截器里統(tǒng)一處理401跳轉(zhuǎn)登錄、500彈錯誤提示。有個容易忽略的細節(jié)上傳圖片用的是multipart/form-data格式和普通JSON請求的Content-Type不一樣封裝時要單獨留出上傳方法別讓統(tǒng)一攔截器把請求頭搞亂。3.2 Element Plus快速搭建后臺界面Element Plus對管理端開發(fā)效率提升非常明顯。表格用el-table、表單用el-form、彈窗用el-dialog、提示用el-message基本覆蓋了管理端90%的場景。菜品管理頁是最典型的CRUD頁面結(jié)構(gòu)上分成三個區(qū)域頂部搜索篩選欄、中間表格區(qū)、底部或彈窗表單區(qū)。表格列綁定數(shù)據(jù)字段狀態(tài)列用el-tag組件顯示不同顏色操作列放編輯和刪除按鈕刪除時二次確認彈窗是必須的防止手滑誤刪。新增和編輯共用一個彈窗表單彈窗打開時判斷是新增還是編輯模式編輯模式需要把當前行數(shù)據(jù)回填到表單提交時區(qū)分調(diào)create接口還是update接口。這個“一窗兩用”的設計很常見理解了它其他管理頁面基本是一個套路。用戶端點餐頁面則更注重交互設計。左側(cè)是分類導航欄點擊切換右側(cè)菜品列表每個菜品卡片顯示圖片、名稱、描述、價格右下角一個“加入購物車”按鈕。列表數(shù)據(jù)量大的時候可以加一個關鍵詞搜索框做前端本地過濾請求后端搜索接口也是可以的但畢設場景下前端過濾就夠了體驗還更流暢。購物車頁面我用表格形態(tài)展示左側(cè)菜品信息中間數(shù)量增減器右側(cè)小計金額底部總計金額和結(jié)算按鈕。數(shù)量變化要實時計算總價Vue的計算屬性是最合適的方案——不需要監(jiān)聽每個變更事件數(shù)據(jù)變了視圖自動更新。3.3 狀態(tài)管理與Vuex/Pinia的使用邊界很多同學對狀態(tài)管理庫的使用邏輯從一開始就是錯的把能塞進狀態(tài)的數(shù)據(jù)全塞進去結(jié)果代碼里到處是store文件引用來引用去數(shù)據(jù)流向變得特別難排查。以點餐系統(tǒng)為例真正需要放進全局狀態(tài)的數(shù)據(jù)只有兩個用戶登錄信息Token和用戶基本資料、購物車數(shù)據(jù)多頁面共享。其他數(shù)據(jù)比如當前選中的分類、搜索關鍵詞、訂單列表都屬于局部狀態(tài)放在組件內(nèi)部管理就好。全局狀態(tài)太多是新手項目變亂的根源一定要克制。Vue3項目推薦Pinia。它的API比Vuex簡潔得多不需要寫mutation這種東西直接定義state、getters、actions就行了。購物車store里定義items數(shù)組actions提供addItem、removeItem、updateCount、clear四個方法。頁面組件里調(diào)用這些action數(shù)據(jù)自動全局同步——首頁加購的菜品切到購物車頁就在列表里了。徹底搞懂“什么數(shù)據(jù)該放store、什么數(shù)據(jù)不該放”之后前端的代碼組織能力會上一個臺階。3.4 移動端適配要不要做點餐系統(tǒng)的使用場景天然偏向手機所以移動端適配不做說不過去。但畢設精力有限全手寫響應式工作量不小。折中方案是用戶端使用Vant組件庫。Vant是移動端Vue組件庫按鈕、彈層、表單、布局全部按移動端尺寸設計直接引入使用界面天然適配手機屏幕。管理端保留Element Plus做桌面端。這樣兩套UI庫分工明確用戶端的“點餐感”也強演示時用瀏覽器開發(fā)者工具切到手機尺寸看效果視覺沖擊力比桌面網(wǎng)頁好很多。Vant的van-list支持下拉加載更多配合后端分頁接口菜品較多的場景下做無限滾動列表體驗非常好。這里要記住一個原則分頁參數(shù)頁碼、每頁條數(shù)由前端傳入后端只負責按參數(shù)返回數(shù)據(jù)不要在前端硬編碼“一次性加載全部”。4. 前后端聯(lián)調(diào)、部署與避坑指南4.1 跨域到底是怎么一回事前后端分離開發(fā)最折磨人的問題之一就是跨域。前端跑在localhost:5173后端跑在localhost:8080端口不同瀏覽器就會攔截跨域請求。原理層面要說清楚瀏覽器的同源策略要求協(xié)議、域名、端口三者一致才能正常發(fā)起Ajax請求。前后端分離環(huán)境下端口必然不一致所以必須解決跨域。解決方式有三種網(wǎng)關轉(zhuǎn)發(fā)、Nginx反向代理、后端配置CORS。畢設場景最簡單有效的是后端配置CORS——寫一個WebMvcConfigurer配置類重寫addCorsMappings方法設置允許的來源、請求頭、請求方法、是否攜帶憑證即可。允許來源可以寫成前端地址或者通配符但要注意如果前端請求攜帶了自定義請求頭比如Authorization必須把對應頭部加進允許列表否則瀏覽器會報預檢失敗。聯(lián)調(diào)環(huán)境直接把allowedOriginPatterns設為全允許開發(fā)省心上線前再收緊。4.2 聯(lián)調(diào)階段的接口規(guī)范約定前后端分離項目里接口文檔是兩撥人協(xié)作的“契約”。正規(guī)項目用Swagger自動生成畢設項目寫一份簡潔的接口說明文檔也完全夠用關鍵是把請求路徑、請求方式、請求參數(shù)、返回數(shù)據(jù)結(jié)構(gòu)寫清楚。返回格式強烈建議統(tǒng)一。我用的標準格式是code整數(shù)狀態(tài)碼、message提示信息、data數(shù)據(jù)主體。所有接口成功時code為200業(yè)務錯誤返回特定業(yè)務碼比如菜品庫存不足返回50001系統(tǒng)異常返回500。前端Axios響應攔截器里統(tǒng)一判斷code成功就返回data給頁面失敗就彈出message頁面代碼不用每個接口都寫一遍錯誤處理。聯(lián)調(diào)階段最常遇到的鬼問題就是字段名對不上。前端List里拿到的字段叫createTime后端JSON里的字段名卻是create_time頁面渲染全是undefined。規(guī)范的做法是后端統(tǒng)一返回駝峰命名SpringBoot默認Jackson配置已經(jīng)做了這個轉(zhuǎn)換如果因為某些特殊配置變了建議核實一下序列化配置。4.3 構(gòu)建打包與本地部署演示答辯或者給導師演示時直接跑npm run dev加后端IDE啟動是不太穩(wěn)的——萬一現(xiàn)場網(wǎng)絡有問題、端口被占、環(huán)境變量缺失就手忙腳亂了。正確姿勢是構(gòu)建出可獨立運行的部署包。前端執(zhí)行npm run build產(chǎn)物在dist目錄。后端執(zhí)行mvn package產(chǎn)物是jar包。部署方案有兩種第一種簡單粗暴把dist目錄下的文件復制到SpringBoot項目的src/main/resources/static目錄下重新打包這樣jar包自帶前端頁面單機運行只要執(zhí)行java -jar xxx.jar就能訪問系統(tǒng)第二種是把前端靜態(tài)文件扔給Nginx處理API請求反向代理到后端8090端口。畢設演示用第一種方案就好省去配置Nginx的時間和現(xiàn)場出問題的概率。后來我知道可以在后端配一個Controller把未匹配的前端路由轉(zhuǎn)發(fā)到index.html能解決Vue路由history模式刷新404的問題本地演示確實穩(wěn)。部署環(huán)境注意MySQL也要跟著一起。最穩(wěn)妥的做法是把建表SQL和數(shù)據(jù)初始化腳本整理成單獨的.sql文件新環(huán)境一鍵導入避免手敲數(shù)據(jù)。4.4 答辯現(xiàn)場的前后端分離講解技巧答辯時講前后端分離重點不是背概念而是用自己項目的實際內(nèi)容說明白“分離”的價值。我當時是這么講的前端負責渲染和交互后端負責業(yè)務邏輯和數(shù)據(jù)安全兩者通過標準HTTP接口通信。舉一個具體的例子購物車結(jié)算時前端只是把購物車的菜品列表發(fā)給后端后端要校驗菜品是否存在、價格是否正確、庫存是否夠——規(guī)則的權(quán)力在后端前端沒有決策權(quán)。數(shù)據(jù)流可以從用戶點擊“提交訂單”按鈕開始前端調(diào)用后端下單接口后端校驗、落庫、返回訂單編號前端跳轉(zhuǎn)支付模擬頁支付成功后前端輪詢或直接跳轉(zhuǎn)到訂單列表頁看到新狀態(tài)。理清這一條主鏈路整個項目的邏輯就講透了。再強調(diào)一個容易被問倒但其實是送分題的點為什么不用Session而用JWT。把“服務端無狀態(tài)、多端復用、解耦集群會話”這幾個核心優(yōu)勢表達清楚就夠了。如果被追問JWT的缺點就承認它無法服務端主動失效、密鑰需要妥善保管這些不是致命傷但對新手的誠實度是加分項。5. 擴展方向與實戰(zhàn)經(jīng)驗總結(jié)5.1 三個值得做的擴展點畢設做到能用只是第一步如果想要更好的成績或者為以后面試攢項目亮點下面三個方向值得考慮。接入真實支付雖然復雜但可以作為一個“模擬支付”模塊來設計。前端點擊支付時彈出一個確認框點擊確認后調(diào)用后端支付接口后端直接修改訂單狀態(tài)為已支付。整個過程中把支付網(wǎng)關的對接流程畫進論文的時序圖里說明真實場景是第三方支付平臺回調(diào)通知后修改訂單狀態(tài)這就能體現(xiàn)出你對“異步回調(diào)”的理解。這種設計論文里價值很高。引入Redis做緩存也值得寫進加分項。菜品列表是讀多寫少的典型場景把高頻訪問的菜品數(shù)據(jù)緩存到Redis設置合理的過期時間數(shù)據(jù)變更時手動清除相關緩存。如果答辯時能說清楚緩存穿透和緩存雪崩的基本概念哪怕項目沒有全部實現(xiàn)也是一段漂亮的拓展內(nèi)容。用戶端加強餐品評價功能包括評分、文字評價、圖片上傳再配合一個按評分排序的接口就是一個完整的功能閉環(huán)。訂單完成后才能評價評分數(shù)據(jù)同步展示在菜品詳情頁邏輯上不復雜但業(yè)務完整度提升很大。5.2 開發(fā)時間投入與節(jié)奏建議給正在做類似項目的同學一個時間參考數(shù)據(jù)庫設計兩天、后端接口十五天、前端頁面十天、聯(lián)調(diào)測試五天。這是對于每天三到五個小時投入的估算。數(shù)據(jù)庫表設計階段多花點時間非常值得模型想清楚了后端寫起來就是搬磚模型設計的毛病會一直拖累到項目做完。寫代碼時要有版本管理意識。哪怕一個人開發(fā)也建議用Git管理每天提交一次刪掉寫壞了的功能不至于回不了頭畢業(yè)論文里的技術敘述也更誠實。日志打印從一開始就做。關鍵方法入口打印參數(shù)異常打印堆棧。調(diào)試時省下的時間遠超寫日志的時間成本。很多同學出問題找不到原因就是因為全程沒有任何日志輸出斷點調(diào)試一多又理不清調(diào)用鏈。5.3 從畢設到作品集這個項目做完、論文寫完只是起點。把它整理進簡歷的時候記得寫清楚項目亮點——前后端分離架構(gòu)、JWT認證、事務管理、樂觀鎖、統(tǒng)一接口規(guī)范、分模塊開發(fā)。面試問到項目時把自己遇到的真實問題隱藏最深的坑往往是圖片上傳返回404、Token過期不跳轉(zhuǎn)、并發(fā)下單庫存超賣和解決過程講出來比背一堆概念有用得多。分享一個很實在的心得代碼能力靠寫但也靠改。一遍寫通的項目其實收獲有限把沒做好的模塊重新梳理、擴展、美化才是把畢設價值榨干的正確方式。祝你們能順利完成有問題評論區(qū)聊。