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