簡(jiǎn)介一套面向生鮮電商場(chǎng)景的 Spring/Maven 項(xiàng)目源碼定位為本地版可直接導(dǎo)入 IntelliJ IDEA 構(gòu)建運(yùn)行適合開發(fā)者用于教學(xué)、二次開發(fā)或項(xiàng)目實(shí)戰(zhàn)練習(xí)。壓縮包共 434 個(gè)文件約 14.11MB其中 Java 源碼、XML 配置、class 編譯文件、JPG/PNG 圖片資源等一應(yīng)俱全后端業(yè)務(wù)與控制層、前端頁(yè)面素材、Maven 構(gòu)建配置均有覆蓋。壓縮包內(nèi)置依賴管理與構(gòu)建腳本能幫助快速搭建環(huán)境、屏蔽版本差異.gitignore 與 target、src 等目錄劃分也便于保持倉(cāng)庫(kù)整潔、理解項(xiàng)目結(jié)構(gòu)與編譯產(chǎn)物。已有 1021 人學(xué)習(xí)下載。整個(gè)項(xiàng)目?jī)?nèi)包含訂單、商品、購(gòu)物車、用戶及統(tǒng)一異常處理等業(yè)務(wù)模塊通過閱讀源碼可掌握這些核心模塊的實(shí)現(xiàn)思路以及 Spring Boot/Spring MVC 項(xiàng)目從零配置到啟動(dòng)運(yùn)行的整體流程適合正在學(xué)習(xí)電商系統(tǒng)開發(fā)、希望快速上手的中初級(jí)開發(fā)者。1. 慕慕生鮮本地版一套能離線跑起來的生鮮電商工程比預(yù)想中值錢把「慕慕生鮮項(xiàng)目源碼本地版」這串字扔進(jìn)搜索框的人多半是剛拿到某個(gè)壓縮包、解壓后面對(duì)一堆模塊目錄發(fā)懵的開發(fā)者和想復(fù)現(xiàn)項(xiàng)目的畢設(shè)選手。這個(gè)標(biāo)題說的不是某個(gè)網(wǎng)頁(yè)模板也不是幾段教學(xué)用的 CRUD 碎片而是一整套可在本機(jī)完整運(yùn)行的生鮮電商工程通常包含 C 端用戶端H5/小程序殼、商家端、管理后臺(tái)和配送端后端提供商品、訂單、庫(kù)存、營(yíng)銷、支付回調(diào)等接口。本地版的價(jià)值在于沒有云服務(wù)依賴、沒有真實(shí)短信和第三方支付通道用模擬支付和內(nèi)置賬號(hào)就能把一條真實(shí)下單鏈路從商品瀏覽走到訂單出庫(kù)。這篇筆記我按自己實(shí)際跑生鮮類電商源碼的習(xí)慣來寫先講本地版的技術(shù)選型和初始化順序再拆商品與訂單主鏈路接著解決前后端聯(lián)調(diào)最后給避坑清單和一個(gè)壓測(cè)驗(yàn)證技巧。新手跟著步驟能把這套東西跑起來熟手可以直接跳過前兩章去看第 4、5 章的端口沖突、Redis 序列化和事務(wù)失效問題。2. 本地版技術(shù)選型與初始化先把 JDK、MySQL、Redis 三件套理順2.1 為什么本地版普遍是「單體內(nèi)核 模塊化目錄」而不是微服務(wù)集群我見過不少剛接觸源碼的人一看到order-service、user-service這種目錄名就緊張以為必須在本地起 Nacos 集群、搞一堆注冊(cè)中心才能運(yùn)行。實(shí)際上去掉「分布式演示」需求后生鮮項(xiàng)目源碼的本地版通常是一個(gè) Spring Boot 單體應(yīng)用或者拆成 35 個(gè)可獨(dú)立啟動(dòng)的 Maven 模塊共用同一個(gè) MySQL 庫(kù)和同一個(gè) Redis。原因很樸素一套微服務(wù)全家桶在單機(jī)上光啟動(dòng)順序就能勸退一半人而本地版的定位是「開發(fā)者自己能跑通、能改、能交作業(yè)」單體聚合結(jié)構(gòu)最容易達(dá)成這個(gè)目標(biāo)。我一般會(huì)先看根目錄pom.xml或者build.gradle里的模塊劃分判斷后端是純單體還是多模塊。生鮮電商里「商品 訂單 庫(kù)存」強(qiáng)相關(guān)的域本地版剝掉消息隊(duì)列和分布式事務(wù)后用Transactional在單庫(kù)上把下單邏輯串起來反而是最穩(wěn)的方案。前端方面管理后臺(tái)用 Vue 2/3 或 React用戶端如果是 H5 就用同一套構(gòu)建產(chǎn)物如果是小程序則另有一套。2.2 初始化數(shù)據(jù)庫(kù)建庫(kù)、導(dǎo)入、初始化賬號(hào)的最短路徑拿到源碼第一件事不是mvn spring-boot:run而是先確認(rèn) MySQL 的版本和初始化 SQL 在哪。生鮮項(xiàng)目里數(shù)據(jù)庫(kù)腳本常見命名是sql/目錄下的init.sql、data.sql或h2文件夾。我建議按下面這組命令把數(shù)據(jù)庫(kù)初始化干凈避免后面因?yàn)榕f數(shù)據(jù)殘留導(dǎo)致賬號(hào)、庫(kù)存對(duì)不上。# 1. 啟動(dòng)本地 MySQL 并登錄以 root 為例 mysql -uroot -p # 2. 建庫(kù)字符集用 utf8mb4生鮮項(xiàng)目里商品名和用戶備注都有 emoji CREATE DATABASE IF NOT EXISTS mumu_fresh DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 3. 在 mysql 命令行內(nèi)執(zhí)行導(dǎo)入注意先切庫(kù) USE mumu_fresh; SOURCE /path/to/your/sql/init.sql; SOURCE /path/to/your/sql/data.sql; # 4. 驗(yàn)證核心表數(shù)量生鮮項(xiàng)目至少該看到十張以上業(yè)務(wù)表 SHOW TABLES;這段命令的作用是「把demo.sql 與初始化腳本喂給新庫(kù)」。utf8mb4不是玄學(xué)生鮮商品描述里經(jīng)常有「新鮮·甜」這類帶特殊符號(hào)的文本utf8mb3 在部分版本上會(huì)報(bào)Incorrect string value錯(cuò)誤。SOURCE路徑用絕對(duì)路徑最省事不要在 MySQL 里用相對(duì)路徑猜半天。導(dǎo)入完成后順手查一下user或member表有沒有內(nèi)置賬號(hào)常見做法是預(yù)置一個(gè)13800000000 / 123456之類的測(cè)試手機(jī)號(hào)密碼在data.sql里是 BCrypt 密文別指望能用明文查出來。2.3 后端配置文件里必須改的 6 個(gè)參數(shù)數(shù)據(jù)庫(kù)初始化完下一步是打開application.yml或application-local.yml搜datasource、redis、server.port三個(gè)關(guān)鍵詞。生鮮項(xiàng)目的本地版默認(rèn)配置經(jīng)常指向localhost:3306/mumu_fresh但密碼、端口、Redis 庫(kù) index 這些往往需要人工對(duì)齊。下面這張表是我每次必查的參數(shù)清單按修改優(yōu)先級(jí)排列配置項(xiàng)常見默認(rèn)值改完之后的作用spring.datasource.urljdbc:mysql://localhost:3306/mumu_fresh?useUnicodetruecharacterEncodingutf8數(shù)據(jù)庫(kù)地址和庫(kù)名不對(duì)啟動(dòng)即報(bào)Communications link failurespring.datasource.username/passwordroot / root與本地 MySQL 不一致時(shí)啟動(dòng)報(bào)Access deniedspring.redis.host/port/databaselocalhost / 6379 / 0Redis 連不上不影響啟動(dòng)但登錄驗(yàn)證碼、商品緩存會(huì)運(yùn)行時(shí)異常server.port8080容易被本地其他服務(wù)占用后面避坑章節(jié)會(huì)細(xì)說spring.servlet.multipart.max-file-size10MB后臺(tái)傳商品圖超過限制直接 500生鮮商品大圖常見 38MB建議調(diào)到 50MBcustom.pay.mock-enabledtrue本地版模擬支付開關(guān)改成 false 會(huì)跳真實(shí)支付網(wǎng)關(guān)本地必翻車改完配置文件后后端啟動(dòng)命令不用花哨直接在項(xiàng)目根目錄執(zhí)行# Maven 方式多模塊時(shí)先 -pl 指定模塊或直接到含 Application 類的模塊目錄 mvn spring-boot:run -Dspring-boot.run.profileslocal # 或者打完包再跑常用于確認(rèn)依賴完整 mvn clean package -DskipTests java -jar target/mumu-fresh.jar --spring.profiles.activelocal這段里--spring.profiles.activelocal是很多新手忽略的參數(shù)本地版源碼通常自帶application-dev.yml、application-prod.yml如果你直接裸跑可能讀到 prod 配置去連遠(yuǎn)程數(shù)據(jù)庫(kù)。啟動(dòng)日志里看到Tomcat started on port(s): 8080只是第一步還不代表業(yè)務(wù)跑通了最好再執(zhí)行curl http://localhost:8080/api/health或直接登錄后臺(tái)確認(rèn)配置真正生效。注意如果你的源碼是前后端分離的后端起不來時(shí)前端頁(yè)面空白屬于正?，F(xiàn)象先排查啟動(dòng)日志里最后三行異常不要急著改前端。3. 拆一條生鮮主鏈路商品緩存、購(gòu)物車、下單事務(wù)是怎么串起來的3.1 商品模塊的緩存策略本地版也值得保留 Redis 緩存層生鮮電商和普通商城最大的差別在商品模型上同一個(gè) SKU 可能有「斤」「份」「盒」多種單位價(jià)格隨促銷活動(dòng)浮動(dòng)庫(kù)存字段還要區(qū)分「可售庫(kù)存」和「鎖定庫(kù)存」。因此商品接口普遍是兩層結(jié)構(gòu)熱點(diǎn)分類和商品詳情放 Redis庫(kù)存和價(jià)格實(shí)時(shí)查 MySQL。本地版雖然流量不大但保留這個(gè)結(jié)構(gòu)能讓你后續(xù)壓測(cè)時(shí)看到緩存命中率對(duì)接口響應(yīng)時(shí)間的影響。以商品列表接口為例常見實(shí)現(xiàn)是「先讀緩存、未命中再查庫(kù)回填」public ListProductVO listCategoryProducts(Long categoryId) { String cacheKey fresh:category: categoryId; // 1. 先查緩存 String cached redisTemplate.opsForValue().get(cacheKey); if (StringUtils.hasText(cached)) { return JSON.parseArray(cached, ProductVO.class); } // 2. 緩存未命中查數(shù)據(jù)庫(kù)并回填 ListProductVO list productMapper.selectByCategoryId(categoryId); // 回填時(shí)加一個(gè) 5 分鐘過期生鮮商品價(jià)格變動(dòng)頻率不高但促銷時(shí)會(huì)即時(shí)改價(jià) redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(list), 5, TimeUnit.MINUTES); return list; }這段邏輯不復(fù)雜但有兩個(gè)參數(shù)值得解釋過期時(shí)間用 5 分鐘而不是 30 分鐘是因?yàn)樯r品類早晚市會(huì)調(diào)價(jià)緩存太久會(huì)讓用戶看到「昨日價(jià)格」導(dǎo)致下單時(shí)價(jià)格校驗(yàn)不一致另外fresh:category:這個(gè) key 前綴是管理后臺(tái)改價(jià)時(shí)主動(dòng)失效緩存用的如果項(xiàng)目里沒有對(duì)應(yīng)的delete操作那你改完后臺(tái)價(jià)格后要等緩存過期才能在前端看到變化。管理后臺(tái)的改價(jià)接口里我一般習(xí)慣主動(dòng)刪緩存而不是等它過期# 常見做法后臺(tái)更新商品后調(diào)用緩存刪除接口或工具清理 redis-cli KEYS fresh:category:* | xargs redis-cli DEL這只是個(gè)兜底操作實(shí)際源碼里會(huì)封裝成RedisService.deleteByPrefix()。生鮮項(xiàng)目里「商品改價(jià) → 緩存清理 → C 端生效」這條鏈路是面試和答辯時(shí)最常被追問的點(diǎn)建議你本地跑通后親手試一次改價(jià)流程。3.2 下單接口的庫(kù)存扣減本地版怎么在不引入 MQ 的情況下防超賣下單是生鮮系統(tǒng)的核心也是最容易「翻車」的地方。本地版雖然沒有高并發(fā)流量但如果把庫(kù)存扣減寫成交互式「先查庫(kù)存、再 UPDATE」并發(fā)壓測(cè)時(shí)照樣能超賣。更穩(wěn)妥的方案是把庫(kù)存扣減放在一條 SQL 或一個(gè) Redis Lua 腳本里完成保證原子性。我在本地驗(yàn)證過一套精簡(jiǎn)實(shí)現(xiàn)下單接口先校驗(yàn)商品上下架和用戶狀態(tài)隨后調(diào)用庫(kù)存服務(wù)扣減最后生成訂單流水并發(fā)送模擬支付回調(diào)。核心庫(kù)存語(yǔ)句長(zhǎng)這樣Transactional(rollbackFor Exception.class) public Long createOrder(CreateOrderRequest req) { // 1. 原子扣減庫(kù)存只有剩余庫(kù)存足夠時(shí)才扣成功 int updated stockMapper.deductStock(req.getSkuId(), req.getQuantity()); if (updated 0) { throw new BizException(ErrorCode.STOCK_NOT_ENOUGH); } // 2. 創(chuàng)建訂單主表和明細(xì)表 Order order buildOrderFromRequest(req); orderMapper.insert(order); orderItemMapper.insertBatch(order.getId(), req.getItems()); // 3. 返回訂單號(hào)等待模擬支付回調(diào) return order.getId(); }deductStock對(duì)應(yīng)的 SQL 是防超賣的關(guān)鍵常見寫法是帶條件的 UPDATEUPDATE sku_stock SET sold sold #{quantity}, version version 1 WHERE sku_id #{skuId} AND (total - sold) #{quantity}這段 SQL 的邏輯說明total - sold quantity是數(shù)據(jù)庫(kù)層的硬校驗(yàn)比「先 SELECT 再 UPDATE」少一個(gè)競(jìng)態(tài)窗口。updated 0時(shí)說明庫(kù)存不足直接拋異?；貪L整個(gè)事務(wù)訂單不會(huì)產(chǎn)生。這里有一個(gè)重要參數(shù)version字段是悲觀開發(fā)習(xí)慣保留的樂觀鎖位用于后臺(tái)人工調(diào)整庫(kù)存時(shí)避免互相覆蓋不是下單鏈路必須的但如果源碼表里有這個(gè)字段你寫別的更新 SQL 時(shí)最好帶上它。模擬支付是本地版的典型設(shè)計(jì)。真實(shí)生鮮項(xiàng)目里用戶支付后會(huì)收到微信/支付寶異步回調(diào)本地版沒有外網(wǎng)回調(diào)地址所以普遍做法是提供一個(gè)「模擬支付接口」訂單創(chuàng)建后前端帶著訂單號(hào)調(diào)一次后端直接把訂單狀態(tài)置為已支付并進(jìn)入配送流程。# 模擬支付接口GET 或 POST 都可本地自測(cè)用 POST curl -X POST http://localhost:8080/api/pay/mock \ -H Content-Type: application/json \ -d {orderNo:202501011200001,payType:alipay,amount:36.50}生鮮項(xiàng)目里訂單狀態(tài)一般有待支付、已支付、備貨中、配送中、已完成、已取消。本地版把「?jìng)湄浿小沟健概渌椭小棺龀啥〞r(shí)任務(wù)掃表模擬真實(shí)履約節(jié)奏。你調(diào)試時(shí)可手動(dòng)改訂單狀態(tài)字段不建議頻繁跑定時(shí)任務(wù)等狀態(tài)推進(jìn)。3.3 用戶端與后臺(tái)的數(shù)據(jù)約定JSON 字段命名不是隨便定的生鮮電商的 C 端和后臺(tái)共用一套后端接口但不同端對(duì)字段的訴求不同。C 端商品詳情需要sales銷量和freshtime上架時(shí)間后臺(tái)列表需要costPrice成本價(jià)和stockWarning預(yù)警值。同一個(gè)ProductVO里兩種角色字段都返回是很常見的這在本地版源碼里幾乎成慣例。理解這個(gè)約定比看懂代碼更重要你在本地改后端時(shí)如果只給 C 端加一個(gè)「同品類推薦」字段要保證后臺(tái)接口不報(bào)錯(cuò)最佳做法是新增 DTO 而不是在現(xiàn)有 VO 上硬加。生鮮項(xiàng)目源碼里經(jīng)常出現(xiàn)AppProductDetailVO和AdminProductVO兩份類就是為這個(gè)原因拆的。注意如果你發(fā)現(xiàn)某個(gè)接口返回的 JSON 里缺少前端要的字段別急著給前端說「后端沒有」先去后端模塊搜同名字段常常是JsonIgnore注解把它藏在了管理端實(shí)體上本地聯(lián)調(diào)時(shí)改動(dòng)實(shí)體要謹(jǐn)慎確認(rèn)兩邊都不受影響再刪注解。4. 前端、管理后臺(tái)與本地接口聯(lián)調(diào)端口、跨域、Token 三個(gè)硬骨頭4.1 本地版前端代理的正確配法別把 API 地址寫死在代碼里生鮮項(xiàng)目源碼的前端部分常見有兩種形態(tài)一種是 Vue 工程里統(tǒng)一走.env.development的環(huán)境變量另一種是直接打成靜態(tài)文件放在后端resources/static下。后者的聯(lián)調(diào)最簡(jiǎn)單——啟動(dòng)后端后直接訪問http://localhost:8080即可前端請(qǐng)求走同源不存在跨域問題。前者則需要配置開發(fā)代理以 Vite 工程為例// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, // 后端接口統(tǒng)一前綴是 /api前端不需要額外透?jìng)?rewrite: (path) path.replace(/^\/api/, ) } } } })這個(gè)配置解決的是「前端 5173 端口頁(yè)面調(diào)后端 8080 接口」的跨域問題。changeOrigin: true是關(guān)鍵它讓后端收到的 Host 頭來自localhost:8080否則有些后端框架基于 Host 做校驗(yàn)時(shí)會(huì)拒絕請(qǐng)求。rewrite那段要看后端實(shí)際的RequestMapping有沒有/api前綴如果后端 Controller 自帶/api/fresh/goods那 rewrite 就要去掉否則會(huì)變成二次拼接導(dǎo)致 404。管理后臺(tái)的端口一般和用戶端不同常見做法是 5173 跑 C 端、5174 跑后臺(tái)或者讓后臺(tái)和后端直接同源。如果你本地起后臺(tái)時(shí)發(fā)現(xiàn)登錄頁(yè)請(qǐng)求全部 404先按這個(gè)順序排查瀏覽器 F12 看 Network 里請(qǐng)求 URL 的端口 → 看是 5174 還是 8080 → 回vite.config.js檢查 target 是否指對(duì)了端口。4.2 Token 認(rèn)證本地怎么處理登錄態(tài)和權(quán)限控制的最小閉環(huán)生鮮項(xiàng)目里 C 端用戶和管理員是兩套認(rèn)證體系。C 端走手機(jī)號(hào) 短信驗(yàn)證碼本地版用萬(wàn)能驗(yàn)證碼123456繞過短信通道后臺(tái)走賬號(hào)密碼。Token 用 JWT 是主流做法登錄成功后前端把 token 存到localStorage請(qǐng)求攔截器統(tǒng)一附帶Authorization: Bearer token。本地調(diào)試時(shí)最常遇到的認(rèn)證問題是「后臺(tái)頁(yè)面一直跳登錄頁(yè)」。原因幾乎都是 token 過期時(shí)間太短生鮮項(xiàng)目源碼默認(rèn)設(shè)置常見是 720 分鐘但有的版本只給了 30 分鐘。調(diào)試階段我一般直接改配置# application-local.yml custom: jwt: # 調(diào)成 7 天避免聯(lián)調(diào)一上午就要重新登錄三次 expire-minutes: 10080 admin-expire-minutes: 10080這個(gè)參數(shù)屬于本地聯(lián)調(diào)優(yōu)化配置不是源碼里默認(rèn)放出來的甚至custom.jwt前綴本身都可能是jwt.secret加jwt.ttl的組合。你搜expire或Token關(guān)鍵字定位到配置類后把過期時(shí)間調(diào)大即可。別忘了同時(shí)檢查 Redis 里是否存在token:blacklist之類的登出邏輯如果存在改配置后要重啟一次后端和 Redis否則舊 token 還在黑名單里。4.3 本地版靜態(tài)文件與圖片上傳商品圖裂了十有八九是路徑問題生鮮項(xiàng)目的圖片處理是本地上手第二常見的問題。后臺(tái)添加商品時(shí)上傳圖片默認(rèn)存本地磁盤的/upload/文件夾但前端訪問的是http://localhost:8080/files/xxx.jpg。如果源碼里沒有把/upload/**映射成靜態(tài)資源或者路徑里帶file://前端圖片就會(huì)裂。常見做法是加一個(gè) WebMvc 配置Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { // 把本地磁盤物理路徑映射到 /files/** 訪問 registry.addResourceHandler(/files/**) .addResourceMapping(/files/**) .addResourceLocations(file: uploadPath /); } }這段配置里file:前綴必須保留前面我有一次寫成classpath:把圖片丟到 jar 包內(nèi)部結(jié)果項(xiàng)目一重啟圖片就全部丟失。商品圖還好生鮮項(xiàng)目的營(yíng)業(yè)執(zhí)照、身份證上傳件丟失就麻煩多了走本地測(cè)試時(shí)建議單獨(dú)建一個(gè)data/uploads目錄不要和源碼目錄混在一起方便打包時(shí)排除。注意本地版經(jīng)常把上傳路徑寫死在配置文件的絕對(duì)路徑如/Users/yourname/uploads這個(gè)路徑一旦別人拷走源碼就會(huì)失效。你拿到本地版若是圖片上傳后報(bào)FileNotFoundException第一反應(yīng)應(yīng)該是改上傳根路徑而不是去看業(yè)務(wù)代碼。5. 慕慕生鮮本地版高頻避坑5 條血淚經(jīng)驗(yàn)與排查套路5.1 啟動(dòng)報(bào)「端口被占用」但 netstat 找不到是哪個(gè)進(jìn)程現(xiàn)象mvn spring-boot:run啟動(dòng)到一半報(bào)Port 8080 was already in use執(zhí)行netstat -ano | grep 8080卻看不到占用進(jìn)程或者看到的是宿主機(jī)某個(gè) PID 但用任務(wù)管理器還殺不掉。原因多數(shù)情況是上一次啟動(dòng)的后端進(jìn)程沒有真正退出特別是 IDE 里點(diǎn)紅色停止按鈕時(shí)Spring Boot 的子進(jìn)程比如內(nèi)嵌 Tomcat可能還掛在后臺(tái)。另一種隱蔽情況是 Docker 里裝了 Nacos 或 MySQL 映射了 8080 端口netstat未必直接顯示。解決先用lsof -i :8080看完整進(jìn)程如果是 java 進(jìn)程就kill -9如果發(fā)現(xiàn)是 Docker 端口映射直接改本地server.port換成 8081 更快。我的習(xí)慣是本地調(diào)試端口統(tǒng)一走 8081避開系統(tǒng)上各種代理工具默認(rèn)的 8080省得每次翻車都去排查占用來源。5.2 數(shù)據(jù)庫(kù)連接正常但所有查詢都報(bào)「Table doesnt exist」現(xiàn)象啟動(dòng)正常登錄接口返回 500日志里報(bào)Table mumu_fresh.sys_user doesnt exist但你明明導(dǎo)入了 SQL。原因初始化腳本里可能帶了DROP TABLE IF EXISTS而data.sql里的表名和你導(dǎo)入的庫(kù)名大小寫不一致。Linux 上 MySQL 表名區(qū)分大小寫Windows 不區(qū)分本機(jī)是 macOS 也區(qū)分。更常見的原因是把init.sql導(dǎo)入到了另一個(gè)庫(kù)比如項(xiàng)目默認(rèn)連mumu_fresh你卻在mumu_fresh_test里導(dǎo)了數(shù)據(jù)。解決檢查application-local.yml里jdbc:mysql://localhost:3306/后面的庫(kù)名再進(jìn) MySQL 執(zhí)行SHOW TABLES FROM 對(duì)應(yīng)庫(kù)名確認(rèn)sys_user或user表存在。如果表名確實(shí)對(duì)不上重新導(dǎo)入一次初始化腳本導(dǎo)入時(shí)先USE數(shù)據(jù)庫(kù)名。生鮮項(xiàng)目存在多套 SQL 的情況不少init.sql和data.sql都要導(dǎo)只導(dǎo)一個(gè)就會(huì)出現(xiàn)「管理端能登錄但首頁(yè)數(shù)據(jù)全部空白」的怪問題。5.3 Redis 緩存里的值是亂碼登錄驗(yàn)證碼接口能用但商品詳情反序列化報(bào)錯(cuò)現(xiàn)象前后端都起來了驗(yàn)證碼能正常顯示但商品列表接口報(bào)JSON parse error: Cannot deserialize instance of ... out of START_ARRAY token。原因本地版源碼里如果 RedisTemplate 沒顯式指定Jackson2JsonRedisSerializer或GenericJackson2JsonRedisSerializer默認(rèn) JDK 序列化會(huì)把對(duì)象存成帶類名的一長(zhǎng)串二進(jìn)制。如果改密碼時(shí)后端寫緩存用的序列化器和讀緩存時(shí)用的不一致讀出來的字符串前面會(huì)多一串\xAC\xED之類的字節(jié)JSON 直接解析失敗。解決找到 RedisTemplate 的配置類統(tǒng)一設(shè)置序列化器Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); // key 用字符串序列化可讀性好方便 redis-cli 排查 template.setKeySerializer(new StringRedisSerializer()); // value 用 JSON 序列化跨語(yǔ)言友好避免 JDK 序列化亂碼 template.setValueSerializer(new GenericJackson2JsonRedisSerializer()); // hash 結(jié)構(gòu)同樣設(shè)置生鮮項(xiàng)目購(gòu)物車常用 hash template.setHashKeySerializer(new StringRedisSerializer()); template.setHashValueSerializer(new GenericJackson2JsonRedisSerializer()); template.afterPropertiesSet(); return template; }設(shè)置完成后把 Redis 里舊 key 清掉否則老數(shù)據(jù)會(huì)被新反序列化器再坑一次。執(zhí)行redis-cli FLUSHDB只清緩存庫(kù)不影響 MySQL本地調(diào)試放心用。這個(gè)坑在「驗(yàn)證碼能用但詳情頁(yè)崩」的場(chǎng)景里極具迷惑性我把它列為本地版最值得提前預(yù)防的序列化問題。5.4 下單后訂單狀態(tài)停在「待支付」模擬支付接口卻查不到訂單現(xiàn)象用戶端能下單訂單列表能看到待支付訂單但調(diào)用模擬支付接口后提示「訂單不存在」或「訂單狀態(tài)不可支付」。原因這套生鮮源碼里 C 端用戶的下單訂單和后臺(tái)看到的訂單可能不在同一張表常見設(shè)計(jì)是order表與order_manage視圖分離另一種可能是訂單號(hào)字段在模擬支付接口里用的是orderNo但真正落庫(kù)的字段叫outTradeNo或orderSn兩邊字段名對(duì)不上導(dǎo)致按訂單號(hào)查不到。解決先拿前端下單接口的返回 JSON看訂單號(hào)在里面對(duì)應(yīng)的字段名是什么再去后端搜模擬支付接口的入?yún)?duì)象定義。生鮮項(xiàng)目源碼本地版經(jīng)常把mockPay接口做成獨(dú)立的 Controller方法簽名里不一定是orderNo搜MockPayController或mockPay關(guān)鍵字直接定位。字段名不匹配時(shí)在后端做個(gè)兼容處理接收orderNo和orderSn兩個(gè)入?yún)⑷∪我环强罩等ゲ橛唵巍＿@個(gè)改動(dòng)不影響線上邏輯純本地調(diào)試友好。5.5 凌晨定時(shí)任務(wù)把訂單全部變成「已取消」一覺醒來數(shù)據(jù)沒了現(xiàn)象頭天晚上下單測(cè)試第二天打開后臺(tái)發(fā)現(xiàn)所有「已支付」訂單變成了「已取消」而庫(kù)存也回補(bǔ)了。原因生鮮項(xiàng)目源碼里定時(shí)任務(wù)常寫「每分鐘掃描一次未支付訂單超時(shí) 30 分鐘自動(dòng)取消」。本地版的模擬支付延遲到第二天操作時(shí)訂單超時(shí)被你本地電腦的睡眠時(shí)間覆蓋掉了。常見定時(shí)任務(wù)參數(shù)在Scheduled(cron 0 */1 * * * ?)配合order.expire.minutes30里改成 0 可以臨時(shí)關(guān)閉超時(shí)取消。解決本地測(cè)試期間把超時(shí)時(shí)間調(diào)成 1440 分鐘或者直接注釋掉OrderTimeoutCancelTask的Scheduled注解。但注意生鮮項(xiàng)目的定時(shí)任務(wù)不止這一個(gè)還有自動(dòng)確認(rèn)收貨、庫(kù)存預(yù)警等任務(wù)改之前先看類名是否清晰別誤關(guān)核心任務(wù)。我的習(xí)慣是本地開發(fā)一律把任務(wù)類掃描路徑排除等真正要測(cè)定時(shí)任務(wù)效果時(shí)再手動(dòng)調(diào)用一次任務(wù)里的execute()方法用手動(dòng)觸發(fā)代替真實(shí)調(diào)度排查問題更快。6. 用 JMeter 壓測(cè)一個(gè)本地下單接口驗(yàn)證并發(fā)扣庫(kù)存到底穩(wěn)不穩(wěn)本地版跑通之后最值得做的驗(yàn)證不是「頁(yè)面能不能打開」而是「這個(gè)訂單主鏈路在并發(fā)下會(huì)不會(huì)出問題」。生鮮電商的高頻場(chǎng)景很集中首頁(yè)流量打到商品查詢、營(yíng)銷活動(dòng)流量打到下單。前者有緩存扛著后者的庫(kù)存扣減 SQL 是真實(shí)考驗(yàn)。我習(xí)慣用 JMeter 跑一個(gè) 100 并發(fā) × 50 次的「下單 模擬支付」腳本看庫(kù)存是否對(duì)得上。JMeter 里建一個(gè)線程組線程數(shù)設(shè) 100Ramp-Up Period 設(shè) 5 秒循環(huán)次數(shù) 50。添加 HTTP 請(qǐng)求到http://localhost:8080/api/order/create請(qǐng)求體是 JSON記得加一個(gè) HTTP Header Manager 放Authorization: Bearer token。下單接口的響應(yīng)里拿到訂單號(hào)后再用正則表達(dá)式提取器把訂單號(hào)喂給下一個(gè)模擬支付請(qǐng)求形成一條完整鏈路。跑完之后判斷結(jié)果的指標(biāo)有三個(gè)Error %是否為 0p95響應(yīng)時(shí)間是否在 500ms 內(nèi)最后一個(gè)關(guān)鍵步驟是查數(shù)據(jù)庫(kù)-- 下單前置庫(kù)存為 5000壓測(cè)總請(qǐng)求 5000 次成功 5000 單 -- 檢查庫(kù)存表的 sold 字段是否剛好等于 5000 SELECT sku_id, total, sold, (total - sold) AS remaining FROM sku_stock WHERE sku_id 10086; -- 順便核對(duì)訂單表的已支付數(shù)量和 sold 保持同步 SELECT COUNT(*) AS paid_count FROM order WHERE sku_id 10086 AND status PAID;如果sold remaining ! total說明庫(kù)存扣減存在并發(fā)問題回去檢查你在deductStock的 UPDATE 語(yǔ)句里是不是少了(total - sold) #{quantity}這個(gè)條件。如果壓測(cè)時(shí)出現(xiàn)「庫(kù)存足夠但下單失敗」的報(bào)錯(cuò)那是updated 0判斷太嚴(yán)格檢查事務(wù)隔離級(jí)別下是否有行鎖競(jìng)爭(zhēng)超時(shí)。生鮮項(xiàng)目源碼的本地版如果默認(rèn)帶sold字段進(jìn)緩存壓測(cè)時(shí)先清 Redis 里的商品庫(kù)存緩存避免緩存里的庫(kù)存數(shù)和數(shù)據(jù)庫(kù)對(duì)不上。一個(gè)更細(xì)的技巧是持續(xù)觀察壓測(cè)中的數(shù)據(jù)庫(kù)連接數(shù)。生鮮項(xiàng)目源碼里HikariCP連接池默認(rèn)配置常見是maximum-pool-size: 10100 并發(fā)進(jìn)來時(shí)連接池會(huì)排隊(duì)這時(shí)的 p95 會(huì)飆升但不至于報(bào)錯(cuò)。如果你想模擬更真實(shí)的線上表現(xiàn)把maximum-pool-size調(diào)到 20、connection-timeout調(diào)到 3000ms然后再壓一次對(duì)比數(shù)據(jù)你能直觀看到連接池參數(shù)對(duì)吞吐量的影響這也是面試時(shí)能拿得出手的本地驗(yàn)證數(shù)據(jù)。最后補(bǔ)一句我的習(xí)慣性動(dòng)作每次壓測(cè)前把 MySQL 和 Redis 都做一次快照或者FLUSHDB 重新導(dǎo)入data.sql保證壓測(cè)結(jié)果不被上次的臟數(shù)據(jù)污染。生鮮項(xiàng)目的庫(kù)存金額直接影響訂單金額臟數(shù)據(jù)會(huì)讓報(bào)表數(shù)字對(duì)不上排查成本遠(yuǎn)高于重新初始化 30 秒的成本。這些坑我基本都踩過一遍按這套順序跑下來你拿到手的任何一套生鮮本地版源碼都能在半天內(nèi)從黑匣子變成可控工程。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取