我當(dāng)年第一次接到二手交易平臺(tái)這類(lèi)需求時(shí)心里想的是這不就是個(gè)帶圖片的CRUD嗎等真正把一個(gè)能用的版本交付出去才發(fā)現(xiàn)商品上下架、訂單狀態(tài)流轉(zhuǎn)、圖片存儲(chǔ)、用戶登錄鑒權(quán)每一個(gè)環(huán)節(jié)拆開(kāi)都能寫(xiě)一篇排坑記錄。這個(gè)項(xiàng)目作為Spring Boot Vue 3的全棧練手或者畢業(yè)設(shè)計(jì)非常典型但也正因?yàn)榈湫秃芏嗳俗龀鰜?lái)的東西只是能跑離能用差得很遠(yuǎn)。這篇文章我會(huì)按照自己實(shí)際做過(guò)的方案來(lái)講從需求邊界、數(shù)據(jù)庫(kù)設(shè)計(jì)、后端接口、前端頁(yè)面到聯(lián)調(diào)部署每個(gè)部分都帶上當(dāng)時(shí)踩過(guò)的坑和最終保留的代碼寫(xiě)法。如果你正準(zhǔn)備動(dòng)手做類(lèi)似的項(xiàng)目可以直接把這套思路搬過(guò)去比從零瞎試要省很多時(shí)間。1. 先從需求說(shuō)起什么樣的二手交易平臺(tái)才算能用很多人一想到電商系統(tǒng)就恨不得把淘寶全部功能塞進(jìn)去購(gòu)物車(chē)、優(yōu)惠券、秒殺、評(píng)價(jià)體系全上。二手交易平臺(tái)如果按這個(gè)思路來(lái)半個(gè)月能做完表結(jié)構(gòu)就不錯(cuò)了。我建議把需求收斂成三個(gè)核心角色的最小閉環(huán)買(mǎi)家、賣(mài)家、管理員。買(mǎi)家的操作路徑是逛、看、買(mǎi)。逛就是首頁(yè)和分類(lèi)頁(yè)的商品列表看是進(jìn)入商品詳情頁(yè)買(mǎi)則是下單并且能查到自己買(mǎi)過(guò)什么。賣(mài)家的操作路徑是發(fā)、改、賣(mài)。發(fā)是發(fā)布新商品改是編輯商品信息或調(diào)整上下架狀態(tài)賣(mài)是能看到訂單被誰(shuí)拍下。管理員做的事情更偏向?qū)徍撕椭卫肀热绨堰`規(guī)商品下架、把惡意用戶禁用這部分做簡(jiǎn)單一點(diǎn)能操作就行。這樣一條鏈路走下來(lái)數(shù)據(jù)庫(kù)里最少需要五張核心表用戶表、分類(lèi)表、商品表、訂單表、收藏表外加一張輪播圖表做首頁(yè)運(yùn)營(yíng)位。登錄注冊(cè)用JWT做無(wú)狀態(tài)鑒權(quán)圖片上傳存本地磁盤(pán)搜索引擎都不需要上直接靠MySQL的LIKE查詢加分類(lèi)篩選就能滿足九成場(chǎng)景。我這里還要強(qiáng)調(diào)一個(gè)經(jīng)常被忽略的點(diǎn)交易狀態(tài)。二手商品的訂單不是標(biāo)準(zhǔn)電商那種待付款-待發(fā)貨-待收貨-已完成因?yàn)槎纸灰淄鶗?huì)在線下溝通比如買(mǎi)家先咨詢?cè)俑犊罨蛘呦闰?yàn)貨再走平臺(tái)。所以訂單狀態(tài)不要設(shè)計(jì)成一套固定的線性流程要在訂單表里放一個(gè)status字段取值包括待付款、待發(fā)貨、待收貨、已完成、已取消給后續(xù)的協(xié)商退款留出空間。需求范圍一旦定死后面每一步開(kāi)發(fā)都有明確的收口標(biāo)準(zhǔn)。那些額外的東西比如站內(nèi)信、舉報(bào)系統(tǒng)、數(shù)據(jù)統(tǒng)計(jì)大屏全部放到二期再做先確保從注冊(cè)到交易完成這條路暢通。2. 環(huán)境與腳手架Spring Boot版本選擇和數(shù)據(jù)訪問(wèn)方案二手交易平臺(tái)這種項(xiàng)目后端框架選型上最容易糾結(jié)的兩件事Spring Boot用2.x還是3.x數(shù)據(jù)持久層用Spring Data JPA還是MyBatis-Plus。先給結(jié)論。如果沒(méi)有特別強(qiáng)烈的理由畢業(yè)設(shè)計(jì)和練手項(xiàng)目?jī)?yōu)先選Spring Boot 2.7.18配合JDK 1.8。原因很實(shí)際市面上絕大多數(shù)教程、開(kāi)源代碼、問(wèn)題解決方案都基于這套組合遇到報(bào)錯(cuò)搜一下基本都有答案。Spring Boot 3.x雖然已經(jīng)不算新東西但它強(qiáng)制要求JDK 17及以上一些老版本的依賴(lài)組件和新版本之間會(huì)有兼容性坑對(duì)于以跑通項(xiàng)目為核心目標(biāo)的場(chǎng)景來(lái)說(shuō)沒(méi)有必要冒這個(gè)險(xiǎn)。當(dāng)然如果你打算用Spring Boot 3走更前沿的技術(shù)棧那就把JDK、IDE、Maven倉(cāng)庫(kù)源一次性檢查好不要等項(xiàng)目寫(xiě)到一半才升級(jí)。數(shù)據(jù)訪問(wèn)層我強(qiáng)烈推薦MyBatis-Plus。JPA上手輕快但在二手交易平臺(tái)這種需要寫(xiě)多表聯(lián)查、動(dòng)態(tài)篩選的場(chǎng)景里JPA的規(guī)范方法名和復(fù)雜查詢之間需要一個(gè)適應(yīng)的過(guò)程很多人寫(xiě)著寫(xiě)著就跑了原生SQL。MyBatis-Plus的BaseMapper提供的selectPage、selectList能覆蓋八成簡(jiǎn)單操作復(fù)雜查詢直接寫(xiě)XML里的SQL語(yǔ)句可控性高得多也符合國(guó)內(nèi)多數(shù)企業(yè)的技術(shù)棧習(xí)慣。創(chuàng)建Spring Boot項(xiàng)目時(shí)有個(gè)細(xì)節(jié)依賴(lài)不要在創(chuàng)建時(shí)一把梭全勾上只需要勾Spring Web、MySQL Driver、Lombok這三個(gè)其他依賴(lài)比如MyBatis-Plus、JWT工具、Hutool都通過(guò)手動(dòng)添加依賴(lài)坐標(biāo)的方式引入。這樣做的原因是Maven的依賴(lài)傳遞經(jīng)常產(chǎn)生版本沖突手動(dòng)管理反而更容易定位問(wèn)題。下面這份是我的pom.xml核心依賴(lài)清單直接抄也行dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.18/version /dependency版本號(hào)我故意寫(xiě)成了你順手就能用的具體版本不要upgrade到最新。尤其是Hutool和MyBatis-Plus新版本偶爾會(huì)把某些工具方法標(biāo)記為廢棄照著老教程抄代碼時(shí)會(huì)編譯報(bào)錯(cuò)沒(méi)必要為了追新把自己繞進(jìn)去。3. 數(shù)據(jù)庫(kù)設(shè)計(jì)五張核心表的結(jié)構(gòu)和狀態(tài)字段怎么定數(shù)據(jù)庫(kù)建模是這種項(xiàng)目最關(guān)鍵、也最容易被追著返工的部分。以我踩過(guò)的坑來(lái)看表結(jié)構(gòu)設(shè)計(jì)失誤導(dǎo)致的返工是整個(gè)項(xiàng)目所有返工里成本最高的所以我建議哪怕你是先寫(xiě)代碼再補(bǔ)庫(kù)的流派也先把表結(jié)構(gòu)畫(huà)出個(gè)草稿。用戶表的核心字段不算多id、username、passwordBCrypt加密后的結(jié)果、nickname、avatar、phone、role用戶/管理員、status正常/禁用、create_time。這里有個(gè)容易被忽視的點(diǎn)用戶頭像默認(rèn)值要處理好前端很多人會(huì)把空字符串當(dāng)成無(wú)效圖片導(dǎo)致img顯示裂圖后端可以在插入用戶時(shí)直接給一個(gè)默認(rèn)頭像路徑。分類(lèi)表更簡(jiǎn)單id、name、parent_id、sort_order。支持兩級(jí)分類(lèi)就夠用一級(jí)是數(shù)碼/服飾/圖書(shū)/生活二級(jí)是手機(jī)/電腦/耳機(jī)這種粒度。不要設(shè)計(jì)成無(wú)限極分類(lèi)一來(lái)管理后臺(tái)選擇麻煩二來(lái)查詢性能和非必要的遞歸邏輯沒(méi)有收益。商品表是整個(gè)系統(tǒng)的絕對(duì)核心我需要重點(diǎn)說(shuō)它的設(shè)計(jì)。首先是必須包含的字段id、user_id賣(mài)家、category_id、title、description、price、original_price、images、status0在售/1已售/2下架/3違規(guī)、view_count、create_time、update_time。圖片字段存什么格式是個(gè)細(xì)節(jié)問(wèn)題自己測(cè)的時(shí)候用JSON數(shù)組字符串最方便比如[/images/upload/xxx.jpg,/images/upload/yyy.jpg]不要用逗號(hào)拼接字符串后端解析JSON比split逗號(hào)可靠得多。商品表的索引設(shè)置也非常關(guān)鍵。實(shí)際使用中的高頻查詢是按分類(lèi)和關(guān)鍵字篩選、按時(shí)間排序、按銷(xiāo)量排序。所以至少要建立(category_id, status)聯(lián)合索引以及create_time單列索引。數(shù)據(jù)量小的時(shí)候索引感知不強(qiáng)等列表里塞了上千條商品數(shù)據(jù)加了索引和沒(méi)加索引的響應(yīng)時(shí)間差別非常明顯。訂單表我踩過(guò)一個(gè)印象深刻的坑。最初設(shè)計(jì)時(shí)只有一個(gè)訂單號(hào)、買(mǎi)家ID、商品ID、金額、狀態(tài)結(jié)果買(mǎi)家拍下多個(gè)商品時(shí)因?yàn)槊總€(gè)商品是獨(dú)立訂單快遞費(fèi)、批量溝通就全亂套了。二手交易平臺(tái)的訂單設(shè)計(jì)其實(shí)分成兩種路徑單一商品即時(shí)拍下想用一個(gè)訂單號(hào)關(guān)聯(lián)多個(gè)商品的話就需要中間表。我的建議是主訂單表和訂單項(xiàng)表分開(kāi)設(shè)計(jì)主訂單表存total_price、status、create_time、consignee信息訂單項(xiàng)表存order_id、product_id、product_title、product_price。這套結(jié)構(gòu)后續(xù)擴(kuò)展購(gòu)物車(chē)、收藏夾合并下單都很自然。收藏表相對(duì)獨(dú)立id、user_id、product_id、create_time然后加唯一索引(user_id, product_id)避免同一個(gè)人重復(fù)收藏同一件商品。這個(gè)唯一索引在MyBatis-Plus里配合INSERT IGNORE或者先查后插都很好用。像圖片上傳這種功能本地存磁盤(pán)路徑就足夠支撐學(xué)習(xí)和演示了。正式商用或云部署時(shí)可以考慮對(duì)象存儲(chǔ)但業(yè)務(wù)代碼里只要把存儲(chǔ)邏輯封裝成獨(dú)立的FileStorageService接口后續(xù)替換存儲(chǔ)供應(yīng)商只需要改一個(gè)實(shí)現(xiàn)類(lèi)不影響Controller和Service層。我給這個(gè)項(xiàng)目留的接口大概是這樣的思路Controller接收MultipartFile交給FileStorageService返回URL字符串Service層把URL拼進(jìn)商品images字段。后面文章講到文件上傳時(shí)會(huì)給出具體的代碼寫(xiě)法。4. Spring Boot分層實(shí)現(xiàn)Controller要薄、Service要厚、事務(wù)要跟對(duì)方法后端代碼的組織方式我見(jiàn)過(guò)太多人把整個(gè)項(xiàng)目的核心邏輯堆在Controller里一個(gè)方法寫(xiě)完100多行看著熱鬧后面想改一個(gè)細(xì)節(jié)就牽一發(fā)動(dòng)全身。二手交易平臺(tái)這種規(guī)模的企業(yè)級(jí)分層應(yīng)該是Controller只做參數(shù)接收和結(jié)果包裝、Service做業(yè)務(wù)邏輯、Mapper做數(shù)據(jù)操作。先展示一個(gè)典型的商品發(fā)布接口看Controller的縮水版PostMapping public ApiResultLong publish(RequestBody Validated ProductPublishDTO dto, RequestAttribute(userId) Long userId) { Long productId productService.publishProduct(userId, dto); return ApiResult.success(productId); }Controller里不出現(xiàn)任何關(guān)于商品價(jià)格校驗(yàn)、狀態(tài)流轉(zhuǎn)、圖片列表解析的邏輯。這些全部下沉到Service層。有人可能覺(jué)得這樣多此一舉但等你要給發(fā)布接口加一個(gè)用戶當(dāng)天發(fā)布商品數(shù)量限制或者敏感詞過(guò)濾時(shí)就明白Service層多點(diǎn)擴(kuò)展點(diǎn)的好處了。真正容易出問(wèn)題的是Service層的事務(wù)控制。商品上架加訂單創(chuàng)建就是一個(gè)典型的多表操作場(chǎng)景。買(mǎi)家點(diǎn)擊購(gòu)買(mǎi)后端要做的事至少有兩件查詢商品是否存在且status等于在售把商品status改成已售并插入一條訂單記錄。這兩步必須在同一個(gè)事務(wù)里執(zhí)行否則可能出現(xiàn)商品被改成已售但訂單沒(méi)生成的臟數(shù)據(jù)。正確姿勢(shì)是在Service方法上打Transactional注解注意這個(gè)注解要打在public方法上并且不能從同類(lèi)內(nèi)部繞過(guò)代理調(diào)用。Transactional(rollbackFor Exception.class) public Long createOrder(Long buyerId, Long productId) { Product product productMapper.selectById(productId); if (product null || product.getStatus() ! ProductStatus.ON_SALE.getValue()) { throw new BusinessException(商品不存在或已下架); } product.setStatus(ProductStatus.SOLD.getValue()); productMapper.updateById(product); Order order new Order(); order.setBuyerId(buyerId); order.setSellerId(product.getUserId()); order.setProductId(productId); order.setAmount(product.getPrice()); order.setStatus(OrderStatus.PENDING_PAYMENT.getValue()); orderMapper.insert(order); return order.getId(); }這里rollbackFor Exception.class值得多說(shuō)一句。Spring的事務(wù)默認(rèn)只在RuntimeException下回滾如果你手滑拋了Exception類(lèi)型的異常事務(wù)不會(huì)回滾數(shù)據(jù)就出了大問(wèn)題。顯式指定rollbackFor算是防御性編程的慣例。再講一個(gè)關(guān)于接口返回的通用規(guī)范。大部分項(xiàng)目會(huì)統(tǒng)一用一個(gè)Result類(lèi)包裝返回?cái)?shù)據(jù)但很多新手會(huì)把狀態(tài)碼返回寫(xiě)得很隨意前端對(duì)接時(shí)只能對(duì)著文檔一個(gè)一個(gè)猜。我習(xí)慣定義成三件套code200成功400業(yè)務(wù)失敗401未登錄500系統(tǒng)異常、message可讀提示文本、data載荷數(shù)據(jù)。前端axios攔截器里判斷code不等于200時(shí)直接彈錯(cuò)誤提示語(yǔ)這套模式在前后端分離項(xiàng)目里復(fù)用性極高。商品列表接口的分頁(yè)查詢也是需要展開(kāi)細(xì)說(shuō)的點(diǎn)。MyBatis-Plus的selectPage配合LambdaQueryWrapper可以非常優(yōu)雅地完成條件拼接public PageResultProductVO pageProducts(int page, int size, Long categoryId, String keyword) { PageProduct p new Page(page, size); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(Product::getStatus, ProductStatus.ON_SALE.getValue()) .eq(categoryId ! null, Product::getCategoryId, categoryId) .and(StringUtils.hasText(keyword), w - w.like(Product::getTitle, keyword).or().like(Product::getDescription, keyword)) .orderByDesc(Product::getCreateTime); IPageProduct result productMapper.selectPage(p, wrapper); return PageResult.of(result.getRecords(), result.getTotal(), page, size); }這段代碼里有兩個(gè)細(xì)節(jié)值得注意。第一個(gè)是eq方法的condition重載categoryId為null時(shí)條件自動(dòng)失效避免NullPointerException。第二個(gè)是keyword為空時(shí)整個(gè)and塊不拼接這個(gè)用condition參數(shù)實(shí)現(xiàn)比動(dòng)態(tài)拼SQL字符串安全得多也符合MyBatis-Plus的官方推薦用法。后端最后還要提一下JWT登錄鑒權(quán)的落地方式。很多項(xiàng)目用的方案是寫(xiě)一個(gè)攔截器繼承HandlerInterceptorAdapter在preHandle里解析Header中的token把userId放進(jìn)Request attribute供Controller取用。注冊(cè)、登錄接口用AnonymousAccess注解跳過(guò)攔截器或者干脆在攔截器里維護(hù)一個(gè)白名單路徑集合。這個(gè)方案雖然比Spring Security輕量但并發(fā)和安全性上對(duì)畢業(yè)設(shè)計(jì)和練手項(xiàng)目完全夠用還不用被Security的過(guò)濾器鏈繞暈。5. 商品發(fā)布里的兩個(gè)隱藏難點(diǎn)圖片上傳和富文本信息商品發(fā)布是買(mǎi)家和賣(mài)家都直接接觸的核心操作如果做不好整個(gè)平臺(tái)的使用體驗(yàn)會(huì)打折。先講圖片上傳。前端用一個(gè)Element Plus的Upload組件就能搞定配置action屬性指向后端接口。后端的Controller接收文件并落盤(pán)代碼寫(xiě)起來(lái)不長(zhǎng)PostMapping(/upload) public ApiResultString upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { throw new BusinessException(上傳文件為空); } String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String filename UUID.randomUUID().toString().replace(-, ) ext; String dateDir new SimpleDateFormat(yyyyMMdd).format(new Date()); File dir new File(UPLOAD_DIR dateDir); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir, filename)); return ApiResult.success(/uploads/ dateDir / filename); }這里面有幾個(gè)坑我實(shí)際都踩過(guò)。文件擴(kuò)展名必須通過(guò)lastIndexOf截取完整后綴不要用用戶上傳的原始文件名防止路徑穿越。文件名用UUID重命名可以避免同名文件互相覆蓋還能順手抹掉一些非法字符。按日期歸檔的好處是后續(xù)維護(hù)磁盤(pán)時(shí)按天清理很方便。還有一個(gè)大家?guī)缀醵紩?huì)忽略的坑Spring Boot默認(rèn)上傳單文件大小限制是1MB商品主圖稍微拍得清晰一點(diǎn)就超了。在application.yml里必須顯式改掉spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB另一個(gè)坑是上傳目錄和靜態(tài)資源映射。默認(rèn)情況下Spring Boot不會(huì)把你上傳到項(xiàng)目磁盤(pán)的文件路徑暴露成可訪問(wèn)的URL前端拿到/uploads/20250604/xxx.jpg根本加載不出來(lái)跨域問(wèn)題還在其次。正確做法是配置一個(gè)WebMvcConfigurer把本地磁盤(pán)目錄映射成虛擬路徑Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/uploads/**) .addResourceLocations(file: uploadDir /); } }配置完之后還要做一次自測(cè)直接在前端地址欄輸入圖片URL如果能打開(kāi)圖片說(shuō)明映射生效否則排查路徑末尾的斜杠和絕對(duì)路徑寫(xiě)法。富文本信息這個(gè)點(diǎn)很多二手交易項(xiàng)目用Textarea草草了事。但實(shí)際上二手商品的賣(mài)點(diǎn)高度依賴(lài)詳細(xì)的描述信息比如瑕疵、轉(zhuǎn)手原因、購(gòu)買(mǎi)渠道。我的方案是用一個(gè)極簡(jiǎn)的markdown編輯器或者純文本多行輸入框前端存markdown文本詳情頁(yè)面再用markdown渲染組件轉(zhuǎn)換成HTML展示。這樣數(shù)據(jù)庫(kù)存的是文本、體積小、可檢索頁(yè)面渲染效果也夠精致。不要為了高級(jí)感引入重型富文本編輯器編輯器生成的HTML嵌入到Vue頁(yè)面里還有XSS風(fēng)險(xiǎn)還需要額外的消毒處理性價(jià)比不高。6. Vue 3前端組織方式從頁(yè)面拆解到接口封裝前端腳手架推薦Vite Vue 3 Pinia Vue Router Element Plus這組合是當(dāng)前Vue 3生態(tài)里最省心的一套。Vite相比Webpack的啟動(dòng)速度和熱更新體驗(yàn)好得一截Element Plus作為UI組件庫(kù)表單、表格、彈窗這種后臺(tái)系統(tǒng)的基礎(chǔ)件它都有不用自己造輪子。文件目錄建議這樣組織src ├── api │ ├── product.js │ ├── order.js │ └── user.js ├── views │ ├── home │ │ └── Home.vue │ ├── product │ │ ├── Detail.vue │ │ ├── Publish.vue │ │ └── List.vue │ ├── order │ │ └── OrderList.vue │ ├── user │ │ ├── Login.vue │ │ ├── Register.vue │ │ └── Center.vue │ └── admin │ ├── UserManage.vue │ └── ProductAudit.vue ├── router │ └── index.js ├── stores │ └── user.js └── utils ├── request.js └── auth.js這個(gè)目錄結(jié)構(gòu)的好處是頁(yè)面視圖、接口層、狀態(tài)管理彼此隔離改接口字段只動(dòng)api目錄改頁(yè)面布局只動(dòng)views目錄互不干擾。項(xiàng)目規(guī)模不大不需要引入過(guò)多的模塊深層次抽象。接口封裝這一步我最想讓新手注意的是一次性把a(bǔ)xios實(shí)例配置到位。通常我們會(huì)在utils/request.js里創(chuàng)建axios實(shí)例統(tǒng)一設(shè)置baseURL、請(qǐng)求頭加請(qǐng)求攔截器和響應(yīng)攔截器。響應(yīng)攔截器里要做的事情包括業(yè)務(wù)狀態(tài)碼判斷、401統(tǒng)一跳轉(zhuǎn)登錄頁(yè)、錯(cuò)誤message自動(dòng)彈出。這塊代碼寫(xiě)一次能省后面幾十次重復(fù)的錯(cuò)誤處理。我分享一下核心部分// utils/request.js import axios from axios import { ElMessage } from element-plus import router from /router import { getToken, clearToken } from ./auth const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token getToken() if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response { const res response.data if (res.code 401) { clearToken() router.push(/login) ElMessage.error(登錄狀態(tài)已失效請(qǐng)重新登錄) return Promise.reject(new Error(Unauthorized)) } if (res.code ! 200) { ElMessage.error(res.message || 請(qǐng)求失敗) return Promise.reject(new Error(res.message || Error)) } return res.data }, error { ElMessage.error(error.response?.data?.message || 網(wǎng)絡(luò)異常) return Promise.reject(error) } ) export default request使用這個(gè)封裝時(shí)業(yè)務(wù)代碼里調(diào)用接口拿到的是響應(yīng)攔截器處理后的data數(shù)據(jù)比如const res await productApi.pageProducts(params)res里直接就是后端返回的業(yè)務(wù)數(shù)據(jù)對(duì)象省去了res.data.data這種垃圾代碼。Vue 3的組件寫(xiě)法我想強(qiáng)調(diào)的是用script setup這個(gè)語(yǔ)法糖。它把組件內(nèi)代碼收斂得非常干凈不用再糾結(jié)export default { setup() {} }的縮進(jìn)層級(jí)問(wèn)題。下面是一個(gè)商品列表卡片組件的核心部分script setup import { ref, onMounted } from vue import { getProducts } from /api/product const products ref([]) const loading ref(false) onMounted(async () { loading.value true try { const res await getProducts({ page: 1, size: 12 }) products.value res.records } finally { loading.value false } }) /script這種寫(xiě)法對(duì)新手非常友好狀態(tài)用ref和reactive頁(yè)面的響應(yīng)式邏輯都在setup里平鋪不需要記憶大量生命周期API。如果對(duì)TypeScript也熟悉可以把const products refProductItem[]([])加上泛型能增強(qiáng)團(tuán)隊(duì)協(xié)作的健壯性。不過(guò)純JavaScript寫(xiě)法也完全沒(méi)問(wèn)題。頁(yè)面級(jí)的路由守衛(wèi)也值得花心思設(shè)計(jì)。Vue Router提供的beforeEach全局守衛(wèi)里要做兩件事檢查目標(biāo)路由是否需要登錄檢查token是否存在。不需要鑒權(quán)的頁(yè)面白名單建議在路由meta里標(biāo)記一次router.beforeEach((to, from, next) { if (to.meta.requiresAuth !getToken()) { next({ path: /login, query: { redirect: to.fullPath } }) } else { next() } })等你把物流信息、買(mǎi)家留言這些后續(xù)功能加進(jìn)來(lái)時(shí)路由守衛(wèi)的代碼不用改動(dòng)擴(kuò)展性很好。7. 聯(lián)調(diào)階段的高頻坑位跨域、日期格式和會(huì)話狀態(tài)前后端分開(kāi)開(kāi)發(fā)的最大痛點(diǎn)就是聯(lián)調(diào)。這一步踩的坑往往能消耗掉比寫(xiě)代碼更多的時(shí)間?？缬騿?wèn)題是最先冒出來(lái)的。前端運(yùn)行在localhost:5173后端運(yùn)行在localhost:8080端口不同就會(huì)被瀏覽器的同源策略攔截。后端加一個(gè)CORS配置類(lèi)可以一次性解決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); } }加完之后如果用axios調(diào)用還報(bào)跨域不要慌先確認(rèn)是否存在Access-Control-Allow-Origin響應(yīng)頭。另外注意使用了allowCredentials(true)后allowedOrigins不能寫(xiě)*所以用allowedOriginPatterns傳遞匹配模式否則會(huì)被瀏覽器攔下來(lái)。這是很細(xì)節(jié)的坑我見(jiàn)到好幾個(gè)人改完配置依然報(bào)錯(cuò)都是栽在這一行。日期格式是第二個(gè)高頻坑。前端拿到的時(shí)間戳往往沒(méi)有格式化好頁(yè)面上顯示出一長(zhǎng)串?dāng)?shù)字。最簡(jiǎn)單可靠的方案是后端實(shí)體類(lèi)的時(shí)間字段上加JsonFormat注解統(tǒng)一輸出格式。Jackson默認(rèn)的日期序列化格式不是我們可讀的顯式指定后就穩(wěn)定了JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8) private LocalDateTime createTime;還有一個(gè)相關(guān)但容易被忽略的問(wèn)題兩種情況下的數(shù)據(jù)庫(kù)時(shí)區(qū)和應(yīng)用時(shí)區(qū)不一致會(huì)出現(xiàn)時(shí)間差8小時(shí)。解決方法是連接字符串里加serverTimezoneAsia/Shanghai并且JVM啟動(dòng)參數(shù)帶上-Duser.timezoneAsia/Shanghai。上線前哪怕費(fèi)點(diǎn)事也要檢查一遍這個(gè)坑排起來(lái)更隱蔽。會(huì)話狀態(tài)的坑則集中在登錄態(tài)上。前端登錄成功后保存token到localStorageVue Router把token通過(guò)請(qǐng)求頭傳給后端后端用攔截器去驗(yàn)證token有效性。這整套閉環(huán)如果中間哪一環(huán)斷了最典型的表現(xiàn)是登錄成功了但一刷新頁(yè)面就回到登錄頁(yè)。要排查的地方集中在utils/auth.js的getToken取值邏輯和axios請(qǐng)求頭是否正確傳遞這兩處定位清楚基本能解決九成問(wèn)題。聯(lián)調(diào)階段我自己最推薦的做法是準(zhǔn)備一份接口文檔表。把所有接口的路徑、方法、請(qǐng)求參數(shù)、返回結(jié)構(gòu)寫(xiě)清楚前后端各拿一份推進(jìn)效率會(huì)高很多。這不算花架子因?yàn)閮蛇呁瑫r(shí)開(kāi)發(fā)時(shí)接口字段變動(dòng)如果沒(méi)有同步記錄半天時(shí)間就浪費(fèi)在扯皮上了。8. 本地跑通全流程的驗(yàn)證清單和部署備忘項(xiàng)目開(kāi)發(fā)到一個(gè)可交付的狀態(tài)后一定要按真實(shí)用戶的操作路徑從頭到尾走一遍。我梳理了一個(gè)驗(yàn)證清單照著過(guò)一遍基本能撐起項(xiàng)目的完整性注冊(cè)一個(gè)新用戶用同一個(gè)用戶名再注冊(cè)一次確認(rèn)有重復(fù)用戶名提示。登錄后進(jìn)入個(gè)人中心看到默認(rèn)頭像正常加載。發(fā)布一件商品帶三張圖片確認(rèn)詳情頁(yè)圖片左右切換正常、縮略圖無(wú)裂圖。商品列表按分類(lèi)篩選確認(rèn)分頁(yè)加載正常翻頁(yè)后數(shù)據(jù)不重復(fù)、不丟失。商品詳情頁(yè)點(diǎn)擊立即購(gòu)買(mǎi)確認(rèn)商品狀態(tài)變?yōu)橐咽圪u(mài)家的賣(mài)出的寶貝列表出現(xiàn)這筆訂單。訂單列表里能看到買(mǎi)家和賣(mài)家的訂單記錄狀態(tài)流轉(zhuǎn)符合預(yù)期。收藏一件商品取消收藏再重復(fù)收藏確認(rèn)沒(méi)有重復(fù)數(shù)據(jù)。管理員后臺(tái)禁用某個(gè)用戶被禁用用戶再次調(diào)用需要登錄的接口時(shí)返回401。所有涉及金額的頁(yè)面確認(rèn)數(shù)字只保留兩位小數(shù)沒(méi)有精度問(wèn)題。這套流程走完前端報(bào)錯(cuò)、后端異常、數(shù)據(jù)庫(kù)臟數(shù)據(jù)基本都會(huì)被揪出來(lái)。邊跑邊修效果比寫(xiě)完就交差了事好太多。部署方面如果只是本地演示或答辯后端可以打包成Jar直接java -jar xxx.jar前端打包后把dist目錄交給Nginx托管再通過(guò)nginx反向代理/api到后端服務(wù)端口。配置文件里把前端目錄指到dist反向代理的路徑記得加個(gè)斜杠替換server { listen 80; server_name localhost; root /opt/fe/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/; } location /uploads/ { alias /opt/be/uploads/; } }Nginx這里有兩個(gè)細(xì)節(jié)要核對(duì)。第一proxy_pass http://127.0.0.1:8080/;末尾的斜杠會(huì)讓路徑中的/api前綴被剝掉請(qǐng)求轉(zhuǎn)到后端就是干凈的接口路徑否則會(huì)出現(xiàn)404。第二商品圖片如果上傳在后端本地目錄Nginx的location /uploads/必須能映射到那個(gè)目錄否則列表頁(yè)和數(shù)據(jù)詳情頁(yè)的圖片全部加載不出來(lái)。我在生產(chǎn)環(huán)境調(diào)整這個(gè)配置就花了半個(gè)下午因?yàn)槁窂嚼镆粋€(gè)斜杠的問(wèn)題圖片裂了一整屏。如果上云服務(wù)器建議把數(shù)據(jù)庫(kù)單獨(dú)部署或用阿里云RDS這類(lèi)托管服務(wù)圖片對(duì)象存儲(chǔ)是后續(xù)的優(yōu)化方向不著急一開(kāi)始用本地磁盤(pán)完全沒(méi)問(wèn)題。寶塔面板在單人運(yùn)維場(chǎng)景下挺省事的可視化地管理Nginx配置和進(jìn)程守護(hù)部署門(mén)檻能低不少。9. 幾個(gè)后續(xù)值得加的功能點(diǎn)以及我的擴(kuò)展順序建議一個(gè)基礎(chǔ)可用的二手交易平臺(tái)跑通后往哪個(gè)方向加功能最能提升完整度我的個(gè)人順序是第一個(gè)值得加的是消息通知。買(mǎi)家對(duì)商品有疑問(wèn)賣(mài)家想要議價(jià)如果沒(méi)有站內(nèi)信就只能靠手機(jī)號(hào)聯(lián)系平臺(tái)價(jià)值會(huì)大打折扣。簡(jiǎn)易實(shí)現(xiàn)方案是在數(shù)據(jù)庫(kù)加一張message表買(mǎi)賣(mài)雙方發(fā)消息時(shí)各插入一條記錄列表頁(yè)按會(huì)話維度查詢頁(yè)面輪詢刷新。等后續(xù)數(shù)據(jù)量大了再升級(jí)成WebSocket推送。第二個(gè)是搜索功能的加強(qiáng)。MySQL的LIKE查詢?cè)谏唐窐?biāo)題和描述字段量級(jí)較小的時(shí)候夠用。如果商品數(shù)據(jù)量上來(lái)了可以考慮引入Elasticsearch或者輕量的方案。但畢業(yè)設(shè)計(jì)和練手項(xiàng)目在數(shù)據(jù)量有限的情況下用數(shù)據(jù)庫(kù)索引加全文索引就能撐住不建議為了炫技把搜索中間件一上來(lái)就納入架構(gòu)復(fù)雜度會(huì)成倍增加。第三個(gè)是管理后臺(tái)的數(shù)據(jù)統(tǒng)計(jì)。在后臺(tái)首頁(yè)放一組簡(jiǎn)單的運(yùn)營(yíng)數(shù)字今日新增用戶、今日發(fā)布商品、總成交量。SQL里寫(xiě)幾個(gè)COUNT函數(shù)就行配合ECharts畫(huà)兩條趨勢(shì)折線整個(gè)后臺(tái)的觀感立刻不一樣。我見(jiàn)過(guò)很多二手平臺(tái)的管理后臺(tái)就是數(shù)據(jù)表格堆砌給用戶看的數(shù)據(jù)維度不夠直觀。這些擴(kuò)展點(diǎn)的共同特點(diǎn)是不改變現(xiàn)有表結(jié)構(gòu)和業(yè)務(wù)閉環(huán)屬于在主干上添加枝葉每多一個(gè)功能都能讓項(xiàng)目的完整性和面試/答辯時(shí)的講稿厚度增加一節(jié)。做完這個(gè)項(xiàng)目后我最大的體會(huì)是二手交易平臺(tái)聽(tīng)起來(lái)平凡但它把用戶認(rèn)證、文件存儲(chǔ)、狀態(tài)機(jī)設(shè)計(jì)、前后端分離聯(lián)調(diào)、部署運(yùn)維全部串起來(lái)了是那種能逼著你把常規(guī)工程問(wèn)題過(guò)一遍的好項(xiàng)目。跟著這套方案走一次踩過(guò)其中的坑之后再遇到同類(lèi)業(yè)務(wù)需求的把握度會(huì)高很多。最后分享一個(gè)實(shí)操建議開(kāi)發(fā)前先把Postman里的接口集合建好。每寫(xiě)完一個(gè)后端接口就順手把請(qǐng)求用例保存進(jìn)去前端聯(lián)調(diào)時(shí)拿真實(shí)的響應(yīng)數(shù)據(jù)做頁(yè)面效果比純前端mock數(shù)據(jù)要穩(wěn)。我見(jiàn)過(guò)太多人項(xiàng)目寫(xiě)完接口沒(méi)有測(cè)試記錄改了個(gè)字段都不知道哪些前端頁(yè)面要跟著改。接口集合這個(gè)好習(xí)慣能讓整個(gè)聯(lián)調(diào)過(guò)程從容不少。