做水果線上銷售管理系統(tǒng)這個(gè)項(xiàng)目單看標(biāo)題里的技術(shù)?！猄pringBoot、Vue、MyBatis、MySQL——很多人第一反應(yīng)是又是一套入門級(jí)電商 Demo。但真正在企業(yè)級(jí)場(chǎng)景里跑過一輪之后你才會(huì)發(fā)現(xiàn)這四件套組合起來做精品水果垂直電商碰上的問題比教科書里寫的多得多。水果不是標(biāo)準(zhǔn)工業(yè)品有季節(jié)屬性、有損耗率、有品級(jí)差異這些都會(huì)直接反映在系統(tǒng)設(shè)計(jì)和數(shù)據(jù)庫表結(jié)構(gòu)上。我最近基于這套完整源碼做了二次開發(fā)和本地部署跑通了從商品上架、會(huì)員下單到后臺(tái)訂單處理的完整流程記錄了全部操作細(xì)節(jié)和調(diào)試筆記。這篇文章把架構(gòu)思路、模塊設(shè)計(jì)、數(shù)據(jù)庫表結(jié)構(gòu)、部署步驟和真實(shí)踩坑經(jīng)歷完整拆開講一遍。適合兩類人一類是剛學(xué)完 SpringBoot 和 Vue 想做完整項(xiàng)目練手的開發(fā)者另一類是正在為生鮮電商或精品水果門店選型、想搞清楚一套真正可運(yùn)行的前后端分離系統(tǒng)內(nèi)部細(xì)節(jié)的朋友。1. 項(xiàng)目整體設(shè)計(jì)與架構(gòu)思路1.1 為什么是 SpringBoot Vue MyBatis 這套組合這套技術(shù)棧放在今天看不算新潮但勝在穩(wěn)定、可控、排查問題成本低而且完全夠撐起一個(gè)中小型企業(yè)的線上銷售業(yè)務(wù)。SpringBoot 解決的是后端基礎(chǔ)設(shè)施問題。內(nèi)嵌 Tomcat 意味著不用單獨(dú)部署 Web 容器java -jar跑起來就是一個(gè)完整的服務(wù)。配合 Maven 做依賴管理新增功能模塊時(shí)引入依賴、寫業(yè)務(wù)代碼就行不需要在一堆 XML 配置文件里反復(fù)打轉(zhuǎn)。做企業(yè)管理系統(tǒng)的團(tuán)隊(duì)基本都是這個(gè)套路招人容易交接成本低這是企業(yè)級(jí)項(xiàng)目最看重的東西。Vue 負(fù)責(zé)前端頁面交互。這套源碼用的是 Vue 2 加 Element UI 組件庫管理后臺(tái)的表單、表格、彈窗、權(quán)限菜單這些基本都是開箱即用。用戶端頁面按移動(dòng)端適配來寫對(duì)接到 H5 和小程序都比較方便。Vue 的響應(yīng)式數(shù)據(jù)機(jī)制在維護(hù)購物車數(shù)量、訂單狀態(tài)這類實(shí)時(shí)變動(dòng)數(shù)據(jù)時(shí)非常順手。MyBatis 是整套架構(gòu)里最值得聊的一環(huán)。很多人覺得 MyBatis 不如 JPA 省事但做電商系統(tǒng)其實(shí)恰恰需要 MyBatis 這種SQL 握在自己手里的方式。訂單報(bào)表、銷售統(tǒng)計(jì)、庫存匯總這類復(fù)雜查詢手寫 SQL 能精確控制 JOIN 關(guān)系、索引命中和使用函數(shù)出了問題直接拿 SQL 去數(shù)據(jù)庫客戶端執(zhí)行一遍就能定位。MyBatis 的 XML 映射文件也方便團(tuán)隊(duì)里經(jīng)驗(yàn)不同的開發(fā)者協(xié)作后端可以先把 SQL 寫好再交給前端聯(lián)調(diào)分工邊界非常清楚。MySQL 則是中小型項(xiàng)目最務(wù)實(shí)的選擇。免費(fèi)、資料多、運(yùn)維簡(jiǎn)單對(duì)事務(wù)支持和并發(fā)控制做得很成熟。用 InnoDB 引擎加上合理的事務(wù)隔離級(jí)別訂單支付的庫存扣減也不容易出并發(fā)問題。除非做到頭部電商那種規(guī)模否則 MySQL 加主從分離的方案完全能支撐很長一段時(shí)間。1.2 前后端分離的角色權(quán)限與模塊劃分邏輯這套系統(tǒng)的整體思路是管理端 用戶端雙端分離前后端通過 JSON 接口交互。管理端面向企業(yè)內(nèi)部角色核心功能包括商品管理、分類管理、訂單管理、會(huì)員管理、優(yōu)惠券管理、內(nèi)容公告管理和數(shù)據(jù)統(tǒng)計(jì)看板。每個(gè)角色通過不同菜單權(quán)限來控制可見范圍。比如運(yùn)營人員只能操作商品上下架和活動(dòng)配置財(cái)務(wù)人員只看得見訂單金額和退款數(shù)據(jù)客服能處理售后申請(qǐng)但沒有改價(jià)的權(quán)限。用戶端則面向 C 端消費(fèi)者包含首頁商品展示、分類導(dǎo)航、商品詳情、購物車、訂單結(jié)算、個(gè)人中心和售后申請(qǐng)這些常規(guī)電商閉環(huán)。權(quán)限這塊用的是 Token 認(rèn)證機(jī)制用戶登錄后拿到一個(gè)簽名 Token 存到本地每次請(qǐng)求帶在 Header 里。管理端和用戶端的登錄態(tài)互不干擾這樣也能避免 Session 共享在一臺(tái)服務(wù)器上負(fù)載增大時(shí)容易出的丟狀態(tài)問題。這里的設(shè)計(jì)邏輯是把展示層、業(yè)務(wù)層和數(shù)據(jù)訪問層拆開前端只負(fù)責(zé)頁面渲染和用戶交互后端專注業(yè)務(wù)規(guī)則和數(shù)據(jù)一致性數(shù)據(jù)庫負(fù)責(zé)最終的事務(wù)落盤。企業(yè)級(jí)系統(tǒng)最怕的就是把業(yè)務(wù)邏輯寫進(jìn)頁面腳本里后面維護(hù)就是一場(chǎng)災(zāi)難。這套源碼在分層這塊做得比較規(guī)矩Service 層承擔(dān)業(yè)務(wù)邏輯Controller 層只做參數(shù)接收和結(jié)果封裝看代碼的時(shí)候能很明顯感受到這種分層帶來的清晰度。2. 精品水果業(yè)務(wù)的定制化設(shè)計(jì)與核心模塊拆解2.1 商品模型不只是圖片加價(jià)格普通電商的商品表字段無非是標(biāo)題、主圖、價(jià)格、庫存。精品水果不一樣它在天然屬性上就多了好幾層維度。首先是品類屬性。水果的規(guī)格并不是單純的一件更需要描述果徑大小、單果重量、產(chǎn)地、成熟度這些維度。同一款車?yán)遄影垂麖娇梢苑譃?28mm、30mm、32mm 三個(gè)規(guī)格價(jià)格可能差出 40%。這套源碼的商品 SKU 表設(shè)計(jì)里預(yù)留了規(guī)格擴(kuò)展字段把這類屬性存成鍵值對(duì)結(jié)構(gòu)前端詳情頁按規(guī)格切換展示不同價(jià)格和庫存狀態(tài)實(shí)際運(yùn)營中非常實(shí)用。其次是品級(jí)字段。精品水果講究精選級(jí)一級(jí)果特級(jí)果的差異不同品級(jí)對(duì)應(yīng)不同的采購成本和售價(jià)。這類字段放在商品表的主層級(jí)就可以不需要拆到 SKU。通過一個(gè)枚舉字段維護(hù)運(yùn)營后臺(tái)上下架時(shí)可以快速選擇。再就是時(shí)令概念。水果是強(qiáng)季節(jié)性商品上架生命周期短很多品種只有 4 到 8 周的銷售窗口。系統(tǒng)里的商品表設(shè)計(jì)了上架開始時(shí)間和下架結(jié)束時(shí)間兩個(gè)字段到了時(shí)間自動(dòng)下架不需要運(yùn)營每天盯后臺(tái)手動(dòng)處理。另外還設(shè)計(jì)了預(yù)售標(biāo)記可以在水果還沒采摘完成時(shí)就先掛出去接受預(yù)訂這是水果電商創(chuàng)造現(xiàn)金流的一個(gè)常見玩法。商品模塊的圖片處理也值得注意。源碼里商品圖片上傳后會(huì)自動(dòng)保存一份縮略圖詳情頁列表和首頁推薦位加載的都是壓縮后的版本點(diǎn)進(jìn)詳情才加載原圖。這一步看似不起眼但對(duì)打開速度影響很大尤其是移動(dòng)端網(wǎng)絡(luò)環(huán)境參差不齊多幾張 3MB 的原圖在列表里拖速度是必然的。2.2 庫存與損耗水果電商的命門庫存模塊是精品水果系統(tǒng)里最需要下功夫的地方。工業(yè)品的庫存只需要管理進(jìn)銷存數(shù)字而水果管理庫存的同時(shí)還得處理損耗。整套系統(tǒng)設(shè)計(jì)了四類庫存動(dòng)向采購入庫、銷售出庫、內(nèi)部報(bào)損和盤點(diǎn)調(diào)整。每一筆都記錄流水月底對(duì)賬時(shí)能直接拉出損耗明細(xì)。比如一批芒果進(jìn)貨 1000 斤賣出去 860 斤報(bào)損 40 斤還有 100 斤庫存這時(shí)候系統(tǒng)里的數(shù)字和賬面上的成本能一一對(duì)上。沒有損耗流水的話毛利算出來永遠(yuǎn)是錯(cuò)的因?yàn)閷?shí)際上的壞果成本全被吞進(jìn)了庫存差異里。庫存預(yù)警是這個(gè)模塊的亮點(diǎn)設(shè)計(jì)。系統(tǒng)支持為每個(gè) SKU 設(shè)置安全庫存閾值和預(yù)警天數(shù)低于閾值時(shí)后臺(tái)看板高亮提醒連續(xù)幾天銷量低于預(yù)期時(shí)也能提前提示運(yùn)營調(diào)整營銷策略。水果不比耐用品放久了不是貶值問題而是直接變成損耗所以預(yù)警的價(jià)值比普通電商系統(tǒng)高得多。針對(duì)社區(qū)團(tuán)購和門店自提的場(chǎng)景系統(tǒng)還支持按門店查看獨(dú)立庫存。同一套商品在總倉和各門店各算各的庫存調(diào)撥后用調(diào)撥單來平衡門店差異。這個(gè)功能對(duì)于同時(shí)做線上商城和線下門店的企業(yè)非常關(guān)鍵算是線上線下一體化在系統(tǒng)層面的一個(gè)具體落地。2.3 訂單與營銷閉環(huán)決定復(fù)購率訂單模塊承擔(dān)的是整個(gè)交易的流轉(zhuǎn)中樞。典型流程是用戶加購、確認(rèn)訂單、支付、商家發(fā)貨、用戶簽收、評(píng)價(jià)售后。系統(tǒng)源碼把每一個(gè)節(jié)點(diǎn)都拆成了獨(dú)立狀態(tài)并且在訂單主表里記錄關(guān)鍵操作時(shí)間戳方便后續(xù)統(tǒng)計(jì)履約時(shí)效。營銷模塊則是提高客單價(jià)和復(fù)購率的核心武器。這套系統(tǒng)集成了優(yōu)惠券、拼團(tuán)、秒殺和積分兌換四類基礎(chǔ)玩法。優(yōu)惠券按滿減金額和適用分類配置拼團(tuán)在多人參團(tuán)后觸發(fā)優(yōu)惠價(jià)秒殺有獨(dú)立庫存和限購規(guī)則積分則是用戶在確認(rèn)收貨后按消費(fèi)金額按比例返還形成二次消費(fèi)的激勵(lì)鏈路。做水果生意的人尤其是做高端水果的復(fù)購率比首次下單更重要。因?yàn)榫匪膯蝺r(jià)高一個(gè)客戶一年如果有 6 次復(fù)購貢獻(xiàn)的利潤非?？捎^而這些營銷組件真正用起來直接決定平臺(tái)的活躍度。我在二次開發(fā)時(shí)對(duì)營銷模塊做了擴(kuò)展額外加了每日鮮價(jià)功能針對(duì)部分葉菜和當(dāng)日到貨的鮮果做時(shí)間階梯折扣。上午 9 點(diǎn)前 95 折中午 12 點(diǎn)前 9 折下午 4 點(diǎn)前 8 折閉店前清貨。這個(gè)功能讓我對(duì)源碼的擴(kuò)展性印象很深——只要在活動(dòng)表加一個(gè)時(shí)間階梯類型再配合定時(shí)任務(wù)更新價(jià)格現(xiàn)有接口基本不用動(dòng)就能跑起來。3. 數(shù)據(jù)庫表結(jié)構(gòu)與企業(yè)級(jí)細(xì)節(jié)解析3.1 核心表拆分與關(guān)鍵字段這套源碼的數(shù)據(jù)庫一共涉及 20 多張表核心表結(jié)構(gòu)中能看到不少企業(yè)級(jí)設(shè)計(jì)的痕跡。用戶表除了基礎(chǔ)賬號(hào)密碼外還包含會(huì)員等級(jí)字段、積分余額、累計(jì)消費(fèi)金額。會(huì)員等級(jí)是做精細(xì)化運(yùn)營的基礎(chǔ)等級(jí)決定了折扣和專屬價(jià)而累計(jì)消費(fèi)金額是計(jì)算等級(jí)升級(jí)的唯一依據(jù)。商品類目表用經(jīng)典的父類目 ID 自關(guān)聯(lián)結(jié)構(gòu)支持無限層級(jí)方便以后擴(kuò)展成多級(jí)分類。商品表則冗余了一個(gè)用于搜索的關(guān)鍵字字段因?yàn)樗a(chǎn)品的別名非常多像車?yán)遄佑纸袡烟页箝儆纸胁恢鹪谏唐啡哂嘧侄卫锞S護(hù)搜索別名可以避免聯(lián)表查詢。SKU 表主要承接規(guī)格和價(jià)格庫存。訂單表包含訂單編號(hào)、用戶 ID、訂單總價(jià)、優(yōu)惠金額、實(shí)付金額、支付方式、收貨地址快照、訂單狀態(tài)和各類時(shí)間戳。這里有一個(gè)很細(xì)的設(shè)計(jì)收貨地址不是關(guān)聯(lián)用戶地址表而是直接存一份快照在訂單里確保用戶之后改了默認(rèn)地址歷史訂單的發(fā)貨信息依然準(zhǔn)確。訂單明細(xì)表記錄了商品名稱、SKU 信息、單價(jià)、數(shù)量和實(shí)付小計(jì)。這個(gè)表也要做成快照式冗余不能只關(guān)聯(lián)商品 ID 去查歷史價(jià)格因?yàn)樯唐芬院箅S時(shí)調(diào)價(jià)如果關(guān)聯(lián)查詢歷史訂單金額和當(dāng)時(shí)商品價(jià)格就對(duì)不上了。3.2 訂單狀態(tài)機(jī)的設(shè)計(jì)思路訂單狀態(tài)是整個(gè)交易系統(tǒng)的靈魂源碼里通過一個(gè)狀態(tài)字段控制流程關(guān)鍵狀態(tài)包括待付款用戶提交訂單但沒支付待發(fā)貨支付成功等待商家操作已發(fā)貨商家發(fā)貨同步寫入物流單號(hào)已完成用戶確認(rèn)收貨訂單閉環(huán)已取消用戶超時(shí)未付取消或商家主動(dòng)關(guān)閉售后中退款或退貨申請(qǐng)通過初審后的中間狀態(tài)從數(shù)據(jù)庫設(shè)計(jì)的角度看狀態(tài)機(jī)最關(guān)鍵的做法是不做物理刪除只做狀態(tài)流轉(zhuǎn)每一步操作記錄操作日志表。訂單金額、狀態(tài)變化時(shí)間、操作人這些信息在生鮮電商處理客訴時(shí)價(jià)值極高。售后糾紛時(shí)直接拉操作日志誰在什么時(shí)間做了什么操作一目了然不需要翻聊天記錄。訂單號(hào)的設(shè)計(jì)同樣有講究。源碼里的訂單號(hào)是年月日時(shí)分秒 隨機(jī)碼的組合結(jié)構(gòu)長度 20 位左右同時(shí)滿足可讀性和唯一性。用數(shù)據(jù)庫自增 ID 做訂單號(hào)在單機(jī)時(shí)代沒問題但一旦以后要分庫分表跨庫唯一性就很難保證所以提前用時(shí)間加隨機(jī)數(shù)的策略本身就是一種前瞻考慮。4. 環(huán)境搭建與部署實(shí)操4.1 開發(fā)環(huán)境配置清單部署這套系統(tǒng)前先準(zhǔn)備好開發(fā)環(huán)境。我本機(jī)用的組合是JDK 1.8 或 11推薦 JDK 8兼容性最穩(wěn)Maven 3.6 以上Node.js 12 到 14 版本Vue CLI 基于 Webpack 4 的項(xiàng)目用太新的 Node 會(huì)出現(xiàn)兼容問題MySQL 5.7 或者 8.0兩個(gè)版本都能跑但配置細(xì)節(jié)略有不同開發(fā)工具建議用帶 Spring 插件和 Vue 插件的版本能用自帶的工具窗口直接調(diào) JSON 接口和打包前端工程第一次跑項(xiàng)目先把 MySQL 里建好數(shù)據(jù)庫字符集用 utf8mb4排序規(guī)則用 utf8mb4_general_ci。utf8mb4 不是可選項(xiàng)因?yàn)橛脩羰肇浀刂泛蜕唐访Q里經(jīng)常有生僻字和特殊符號(hào)舊版的 utf8 字符集存不全。執(zhí)行源碼附帶的 SQL 文件后確認(rèn)核心表都創(chuàng)建成功再進(jìn)入下一步。4.2 SpringBoot 后端配置與啟動(dòng)后端配置文件集中在application.yml需要改的核心參數(shù)如下spring: datasource: url: jdbc:mysql://localhost:3306/fruit_mall?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: yourpassword servlet: multipart: max-file-size: 10MB max-request-size: 20MB server: port: 8080數(shù)據(jù)庫連接串里的serverTimezoneAsia/Shanghai這個(gè)參數(shù)必須帶上。MySQL 8.0 默認(rèn)的時(shí)區(qū)跟中國本地時(shí)區(qū)不一致不帶的話啟動(dòng)時(shí)會(huì)直接報(bào)Server returns invalid time的錯(cuò)。MySQL 5.7 階段沒有這么嚴(yán)格但為了統(tǒng)一還是建議加上。上傳文件的大小限制也建議按業(yè)務(wù)量調(diào)整。水果商品詳情頁經(jīng)常要傳多角度實(shí)拍圖單張圖 5MB 很正常如果默認(rèn)限制太小運(yùn)營那邊上傳圖只會(huì)一直報(bào)錯(cuò)體驗(yàn)很糟糕。配置改好后執(zhí)行mvn clean package -DskipTests打包完成后 target 目錄下會(huì)生成 jar 包直接運(yùn)行java -jar fruit-mall-backend.jar看到 Spring Boot 的啟動(dòng)日志出現(xiàn)Started Application in xx seconds就說明啟動(dòng)成功。測(cè)一下登錄接口如果能正常返回 Token后端就算跑通了。4.3 Vue 前端構(gòu)建與反向代理聯(lián)調(diào)前端工程是標(biāo)準(zhǔn)的 Vue CLI 項(xiàng)目先在工程目錄下安裝依賴npm install如果網(wǎng)絡(luò)環(huán)境下載慢可以換成國內(nèi) npm 鏡像源。安裝完成后配置 Vue 的代理解決前后端聯(lián)調(diào)的跨域問題。在vue.config.js中做如下配置module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }這里的關(guān)鍵思路是開發(fā)環(huán)境下讓 Vue 的開發(fā)服務(wù)器把/api開頭的請(qǐng)求轉(zhuǎn)發(fā)到后端 8080 端口這樣瀏覽器里沒有跨域問題不需要后端額外開啟跨域過濾器。生產(chǎn)部署時(shí)則用 Nginx 做同樣的事情把前端靜態(tài)頁面和后端接口按路徑分開轉(zhuǎn)發(fā)。從源碼設(shè)計(jì)來看項(xiàng)目默認(rèn)就是這么規(guī)劃的前后端分離項(xiàng)目最標(biāo)準(zhǔn)的部署方式就是 Nginx 反向代理而不是把前端打包進(jìn)后端工程。后端啟動(dòng)、前端啟動(dòng)后訪問管理后臺(tái)地址用初始化賬號(hào)登錄能成功進(jìn)入控制臺(tái)就是前后端聯(lián)調(diào)成功。然后再打開用戶端頁面走一遍從選購到支付的完整流程確認(rèn)所有環(huán)節(jié)的數(shù)據(jù)都在數(shù)據(jù)庫中正常落表。5. 常見問題與排查技巧實(shí)錄5.1 跨域 Session 丟失問題前后端聯(lián)調(diào)階段最典型的問題是用戶登錄后下一個(gè)請(qǐng)求就提示未認(rèn)證。這個(gè)問題的根源在于 Token 沒有正常傳遞或者后端校驗(yàn)邏輯讀不到請(qǐng)求頭里的憑證。排查思路先看瀏覽器的開發(fā)者工具確認(rèn)請(qǐng)求頭里有沒有Authorization字段。如果前端代碼里做了攔截器統(tǒng)一注入但請(qǐng)求里沒有那就是攔截器本身沒生效。如果請(qǐng)求頭有 Token 但后端依然返回 401那就要檢查后端的攔截器可能默認(rèn)放行的路徑配置把需要攔截的也放過了或者 Token 校驗(yàn)邏輯在時(shí)間戳上有偏差。5.2 MySQL 時(shí)區(qū)報(bào)錯(cuò)5.7 升級(jí)到 8.0 后最常見的錯(cuò)誤就是數(shù)據(jù)庫連接失敗控制臺(tái)報(bào)時(shí)區(qū)相關(guān)的異常。這個(gè)坑解決辦法非常簡(jiǎn)單連接串里加上serverTimezoneAsia/Shanghai就好。另外確認(rèn)一下 MySQL 服務(wù)本身的時(shí)區(qū)設(shè)置或者直接設(shè)定數(shù)據(jù)庫連接為系統(tǒng)默認(rèn)時(shí)區(qū)。很多本地調(diào)試環(huán)境各種正常、上線就出問題大部分都是環(huán)境時(shí)區(qū)設(shè)置不一致導(dǎo)致的。5.3 圖片上傳后管理端回顯失敗這個(gè)問題在部署階段非常普遍原因通常是上傳路徑和訪問映射不一致。源碼里文件上傳默認(rèn)保存到本地某個(gè)目錄但管理端回顯圖片時(shí)是通過 URL 訪問靜態(tài)資源映射如果系統(tǒng)里配置的upload.path和靜態(tài)資源映射配的是兩個(gè)目錄那上去了也白搭。我的處理習(xí)慣是把上傳目錄寫到項(xiàng)目可配置項(xiàng)里啟動(dòng)時(shí)動(dòng)態(tài)創(chuàng)建目錄并確認(rèn)后端靜態(tài)資源配置目錄與之一致。成熟的方案是給 Nginx 單獨(dú)配一個(gè)/images/的靜態(tài)目錄上傳落盤到這個(gè)目錄訪問時(shí)直接由 Nginx 返回不走 Tomcat 應(yīng)用效率和穩(wěn)定性都更好。5.4 MyBatis 查詢結(jié)果為空卻沒有報(bào)錯(cuò)這個(gè)坑是最隱蔽的。運(yùn)行正常、不報(bào)錯(cuò)、但前端列表數(shù)據(jù)是空。排查發(fā)現(xiàn)原因是實(shí)體類屬性名和數(shù)據(jù)庫字段名映射不上。如果開啟了下劃線轉(zhuǎn)駝峰配置那要確認(rèn)配置對(duì)數(shù)據(jù)庫方言的支持情況如果沒開啟必須在 XML 文件里手動(dòng)寫好 resultMap 或者給字段加別名。這種問題沒有報(bào)錯(cuò)是因?yàn)?SQL 執(zhí)行成功了只是查詢結(jié)果的列名跟實(shí)體屬性名對(duì)不上MyBatis 默認(rèn)做了空值處理。解決方法是統(tǒng)一規(guī)范實(shí)體類字段和數(shù)據(jù)庫字段盡量用相同的命名風(fēng)格或者所有手寫 SQL 一律在 select 后面把字段改名成別名避免在 XML 里到處寫 resultMap。我后來在團(tuán)隊(duì)里定了一條規(guī)則寧可 SQL 里寫一堆別名也不要依賴 resultMap因?yàn)樵谧侄螖?shù)量多的時(shí)候出錯(cuò)率會(huì)明顯上升。5.5 Maven 依賴版本沖突引入額外工具包時(shí)Maven 依賴沖突是常見問題。Spring Boot 的父版本管理機(jī)制加上某些依賴自帶傳遞依賴可能導(dǎo)致同一個(gè) jar 出現(xiàn)多個(gè)版本運(yùn)行時(shí)報(bào)方法找不到或者類找不到。排查命令很簡(jiǎn)單mvn dependency:tree看依賴樹里有沒有同一個(gè) groupId 和 artifactId 出現(xiàn)多次有的話在 pom 里加排除排除掉不需要的傳遞依賴。這個(gè)操作不需要記很多細(xì)節(jié)關(guān)鍵是養(yǎng)成打包前檢查依賴樹的習(xí)慣能省掉大量線上運(yùn)行期的奇怪問題。6. 二次開發(fā)與功能擴(kuò)展的真實(shí)體會(huì)跑通這套源碼并不是終點(diǎn)用它去做業(yè)務(wù)落地才是真正的考驗(yàn)。我在這套系統(tǒng)基礎(chǔ)上做的第一個(gè)改造是把支付模塊從模擬狀態(tài)切換成真實(shí)第三方支付。源碼里默認(rèn)支付操作是直接模擬成功這方便了聯(lián)調(diào)演示但上線前必須接入真實(shí)的支付渠道。接入的關(guān)鍵點(diǎn)是處理好支付回調(diào)的驗(yàn)簽和冪等性——回調(diào)可能來很多次要保證訂單狀態(tài)只能從待付款流轉(zhuǎn)到待發(fā)貨一次不能因?yàn)橹貜?fù)回調(diào)把訂單狀態(tài)改出問題。第二個(gè)改造是做了配送時(shí)效倒計(jì)時(shí)。水果類商品講究時(shí)效承諾從用戶下單開始按門店距離計(jì)算配送時(shí)間前端倒計(jì)時(shí)顯示預(yù)計(jì) X 分鐘送達(dá)。這個(gè)功能表面看是提升用戶體驗(yàn)實(shí)際還倒逼了后端庫存核對(duì)邏輯要做成實(shí)時(shí)的因?yàn)橐呀?jīng)進(jìn)入履約流程的商品不能再被后臺(tái)取消庫存。第三個(gè)經(jīng)驗(yàn)來自運(yùn)營數(shù)據(jù)看板。源碼自帶的統(tǒng)計(jì)模塊能展示銷售額、訂單量、客單價(jià)這些基礎(chǔ)指標(biāo)。我做擴(kuò)展時(shí)額外接入了毛利統(tǒng)計(jì)結(jié)合入庫成本和損耗流水可以算出每個(gè) SKU 的真實(shí)毛利率。這個(gè)數(shù)據(jù)才是精品水果業(yè)務(wù)決策的核心——有些水果看著賣得火算上損耗其實(shí)是在虧錢有了這個(gè)看板運(yùn)營第二天就會(huì)去調(diào)整價(jià)格和采購策略。從整體來看SpringBoot 加 Vue 加 MyBatis 加 MySQL 這套組合的邊界在哪里、能撐多大業(yè)務(wù)我心里是比較有底的。前端頁面該拆組件就拆組件后端服務(wù)該拆模塊就拆模塊數(shù)據(jù)庫扛不住就加緩存、做讀寫分離這套體系的每一步演進(jìn)路徑都很清晰。對(duì)正在接觸這個(gè)項(xiàng)目的朋友我最后想說的是別急著改代碼先把源碼里的數(shù)據(jù)表關(guān)系圖吃透把訂單狀態(tài)流轉(zhuǎn)跑通把支付流程走一遍比改任何功能都有價(jià)值。我是把這套系統(tǒng)完整折騰了一遍之后才真正理解企業(yè)級(jí)電商系統(tǒng)為什么要把那么多細(xì)節(jié)做進(jìn)表結(jié)構(gòu)和狀態(tài)機(jī)里。等你把這些東西在腦子里形成一副完整的地圖以后碰到再復(fù)雜的業(yè)務(wù)需求都不會(huì)心虛。