同行們最近完成了一套基于Spring Boot的寵物店管理系統(tǒng)從需求調(diào)研到表結(jié)構(gòu)設(shè)計(jì)再到前后端聯(lián)調(diào)、打包部署整個(gè)過(guò)程踩了不少坑也總結(jié)出一些可以直接復(fù)用的經(jīng)驗(yàn)。寵物店這種業(yè)務(wù)場(chǎng)景很有代表性——它既有進(jìn)銷存的庫(kù)存邏輯又有會(huì)員充值、服務(wù)預(yù)約這類偏C端的功能還有寵物檔案這種強(qiáng)行業(yè)屬性的數(shù)據(jù)非常適合拿來(lái)練手或接私活。這篇文章我會(huì)把整個(gè)系統(tǒng)的設(shè)計(jì)思路、核心表結(jié)構(gòu)、關(guān)鍵代碼實(shí)現(xiàn)以及我在項(xiàng)目里實(shí)際遇到過(guò)的問(wèn)題和排查過(guò)程都寫出來(lái)希望對(duì)正在做同類項(xiàng)目或者準(zhǔn)備用Spring Boot搭建中小型管理系統(tǒng)的朋友有所幫助。1. 項(xiàng)目設(shè)計(jì)與技術(shù)選型為什么用Spring Boot做這類系統(tǒng)最合適1.1 寵物店的實(shí)際業(yè)務(wù)到底在管什么很多人在動(dòng)手寫代碼之前習(xí)慣先畫(huà)ER圖、先建工程但我的習(xí)慣是先弄清楚店里每天到底要發(fā)生哪些事。就拿一家中等規(guī)模的寵物店來(lái)說(shuō)日常業(yè)務(wù)基本上逃不出這幾條線第一是寵物檔案。寵物店不是單純的賣貨很多服務(wù)是圍繞寵物本身展開(kāi)的比如洗澡、美容、寄養(yǎng)、驅(qū)蟲(chóng)、疫苗。每一只寵物都需要記錄名字、品種、年齡、體重、是否絕育、疫苗情況、主人聯(lián)系方式。這個(gè)數(shù)據(jù)不建立好后面的預(yù)約和服務(wù)記錄都是空中樓閣。第二是商品庫(kù)存和銷售。寵物店會(huì)賣貓糧狗糧、零食、玩具、驅(qū)蟲(chóng)藥、貓砂這類快消品。這里就涉及采購(gòu)入庫(kù)、零售出庫(kù)、庫(kù)存預(yù)警以及批號(hào)效期管理——尤其是寵物藥品效期管理做得不好容易出大事。第三是會(huì)員與儲(chǔ)值。寵物店非常依賴回頭客所以幾乎家家都有會(huì)員卡和儲(chǔ)值贈(zèng)送的玩法。儲(chǔ)值余額、消費(fèi)扣款、充值記錄、積分累計(jì)這些都需要系統(tǒng)支撐而且錢有關(guān)的東西最容易扯皮所以流水記錄必須清晰。第四是服務(wù)預(yù)約。洗澡、美容、護(hù)理這類項(xiàng)目客單價(jià)高需要和店員的時(shí)間綁定預(yù)約之后就涉及排班和到店確認(rèn)。有些店還有寄養(yǎng)服務(wù)需要記錄入店時(shí)間、離店時(shí)間、每日喂養(yǎng)情況。把這四條業(yè)務(wù)線理清楚之后你會(huì)發(fā)現(xiàn)這本質(zhì)上就是個(gè)標(biāo)準(zhǔn)的進(jìn)銷存會(huì)員管理系統(tǒng)的組合沒(méi)有什么特別炫技的地方。但正因?yàn)闃I(yè)務(wù)面覆蓋廣用Spring Boot這種“約定大于配置”的框架來(lái)落地是最舒服的它自帶starter機(jī)制數(shù)據(jù)庫(kù)、緩存、權(quán)限、文件上傳這些能力都可以通過(guò)依賴快速集成省去大量XML配置的重復(fù)勞動(dòng)。1.2 技術(shù)選型的三個(gè)關(guān)鍵考量技術(shù)棧我最終敲定為Spring Boot 2.7.x MyBatis-Plus MySQL 8.0 Redis Vue 2/3前后端分離。這里逐個(gè)說(shuō)下選擇理由。Spring Boot版本我特意選了2.7系列沒(méi)有直接追新用3.x。原因很簡(jiǎn)單3.x基于Jakarta命名空間部分老版本的MyBatis-Plus、生成器工具和網(wǎng)上的大部分教程都不兼容新手照著踩坑會(huì)非常痛苦。2.7雖然沒(méi)有3.x新但勝在穩(wěn)定、生態(tài)兼容性好對(duì)于管理系統(tǒng)這種對(duì)穩(wěn)定性要求遠(yuǎn)高于新特性的項(xiàng)目來(lái)說(shuō)夠用而且放心。持久層選擇MyBatis-Plus核心原因是它的代碼生成器配合Wrapper查詢能讓CRUD開(kāi)發(fā)量減少一半。寵物店管理系統(tǒng)的表數(shù)量大概在15到20張每張表都要寫基礎(chǔ)增刪改查如果用原生MyBatis手寫XML工作量會(huì)淹沒(méi)在重復(fù)勞動(dòng)里而MyBatis-Plus的BaseMapper已經(jīng)把這些內(nèi)置好了。對(duì)于多表關(guān)聯(lián)查詢我依然選擇手寫XML避免因?yàn)闉E用MP的嵌套查詢導(dǎo)致性能問(wèn)題。Redis在這個(gè)項(xiàng)目里不是必需品但我還是引入進(jìn)來(lái)了主要用來(lái)做三件事登錄token的存儲(chǔ)、首頁(yè)看板數(shù)據(jù)的緩存、以及商品庫(kù)存的緩存扣減。尤其是會(huì)員儲(chǔ)值余額的查詢每次下單都要讀用Redis扛住熱點(diǎn)訪問(wèn)后數(shù)據(jù)庫(kù)的壓力會(huì)小很多。前端部分考慮到很多做Spring Boot開(kāi)發(fā)的人的前端水平停留在能用的階段我建議采用Vue Element UI的經(jīng)典組合最后打包成靜態(tài)文件放進(jìn)Spring Boot的resources目錄這樣部署時(shí)只需要一個(gè)jar包省去配置Nginx的環(huán)節(jié)。這個(gè)方案我實(shí)測(cè)下來(lái)非常省心適合中小項(xiàng)目和個(gè)人開(kāi)發(fā)者。1.3 系統(tǒng)模塊劃分單體應(yīng)用也要有清晰邊界雖然這是個(gè)單體項(xiàng)目但代碼結(jié)構(gòu)上我還是按照“職責(zé)分包”的思路來(lái)劃分而不是controller/service/mapper三層打天下。最終包結(jié)構(gòu)如下com.petshop ├── common # 通用模塊統(tǒng)一返回體、異常處理、常量、工具類 ├── config # 配置類MyBatis-Plus、Redis、跨域、攔截器 ├── controller # 控制層按業(yè)務(wù)模塊細(xì)分 ├── service # 業(yè)務(wù)層接口 實(shí)現(xiàn) ├── mapper # 持久層接口 ├── entity # 數(shù)據(jù)庫(kù)實(shí)體 ├── dto # 前端交互對(duì)象請(qǐng)求參數(shù)、響應(yīng)視圖 ├── vo # 視圖對(duì)象組合查詢結(jié)果 └── job # 定時(shí)任務(wù)庫(kù)存預(yù)警、寄養(yǎng)到期提醒按業(yè)務(wù)模塊劃分controller我分成了PetController、ProductController、StockController、MemberController、RechargeController、OrderController、AppointmentController、DashboardController這么幾個(gè)。這里有個(gè)經(jīng)驗(yàn)想分享很多初學(xué)者喜歡建一個(gè)CommonController放所有接口圖省事。但等接口數(shù)量超過(guò)50個(gè)之后維護(hù)成本會(huì)急劇上升別人接手根本不知道某個(gè)接口該去哪里找。按業(yè)務(wù)劃分controller配合統(tǒng)一返回體Result類定位問(wèn)題會(huì)快很多這也是后期維護(hù)少掉頭發(fā)的重要原因。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)核心表結(jié)構(gòu)和建表時(shí)的取舍2.1 表關(guān)系梳理15張表怎么組織整個(gè)數(shù)據(jù)庫(kù)我最終拆成了15張表按業(yè)務(wù)域歸類成四組。寵物檔案組有寵物品種表、寵物信息表。商品與庫(kù)存組有商品分類表、商品信息表、庫(kù)存流水表、批次表。會(huì)員與營(yíng)銷組有會(huì)員表、會(huì)員儲(chǔ)值流水表、積分明細(xì)表。交易與預(yù)約組有商品訂單表、訂單明細(xì)表、服務(wù)項(xiàng)目表、預(yù)約單表、寄養(yǎng)記錄表。每個(gè)業(yè)務(wù)域之間通過(guò)外鍵邏輯關(guān)聯(lián)并不在數(shù)據(jù)庫(kù)層面強(qiáng)加物理外鍵這個(gè)后面會(huì)解釋原因。在設(shè)計(jì)的時(shí)候我踩了一個(gè)比較典型的坑一開(kāi)始把寵物表和會(huì)員表做成強(qiáng)關(guān)聯(lián)認(rèn)為寵物必須屬于某個(gè)會(huì)員。后來(lái)發(fā)現(xiàn)寵物店的實(shí)際場(chǎng)景里經(jīng)常有非會(huì)員帶寵物來(lái)洗澡、買藥你總不能逼人家先辦會(huì)員。于是我把寵物表的主人字段改成了owner_name、owner_phone兩個(gè)冗余字段非會(huì)員也能建寵物檔案會(huì)員則額外關(guān)聯(lián)member_id。這個(gè)改動(dòng)讓我意識(shí)到表結(jié)構(gòu)設(shè)計(jì)不能完全照搬理論上的范式要充分考慮線下門店的真實(shí)操作習(xí)慣。提示做業(yè)務(wù)系統(tǒng)設(shè)計(jì)時(shí)“歸屬”關(guān)系往往是變化的盡量把強(qiáng)關(guān)聯(lián)改成弱關(guān)聯(lián)用冗余字段降低耦合度后期改動(dòng)成本會(huì)小很多。2.2 核心表現(xiàn)場(chǎng)實(shí)現(xiàn)建表SQL可以直接參考我挑幾張最核心的表來(lái)展示DDL這些都是在實(shí)際項(xiàng)目里驗(yàn)證過(guò)的結(jié)構(gòu)。寵物信息表是整個(gè)系統(tǒng)的地基它的設(shè)計(jì)直接影響洗護(hù)、寄養(yǎng)功能的聯(lián)動(dòng)。最關(guān)鍵的字段是pet_type、sterilization_status和vaccine_status這三個(gè)字段直接決定服務(wù)端是否有權(quán)限接單。比如部分美容項(xiàng)目對(duì)未絕育寵物有額外收費(fèi)規(guī)則疫苗信息則影響寄養(yǎng)區(qū)域的分配。CREATE TABLE pet_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主鍵, pet_name VARCHAR(50) NOT NULL COMMENT 寵物名, pet_type TINYINT NOT NULL COMMENT 寵物類型1貓 2狗 3其他, breed_name VARCHAR(50) COMMENT 品種名稱, birthday DATE COMMENT 出生日期, weight DECIMAL(5,2) COMMENT 體重kg, sterilization_status TINYINT DEFAULT 0 COMMENT 絕育0未 1已, vaccine_status TINYINT DEFAULT 0 COMMENT 疫苗0未完成 1已完成, allergy_info VARCHAR(255) COMMENT 過(guò)敏史, owner_name VARCHAR(50) NOT NULL COMMENT 主人姓名, owner_phone VARCHAR(20) NOT NULL COMMENT 主人聯(lián)系電話, member_id BIGINT COMMENT 關(guān)聯(lián)會(huì)員ID, remark VARCHAR(500), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deleted TINYINT DEFAULT 0 COMMENT 邏輯刪除 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT寵物信息表;邏輯刪除字段deleted我?guī)缀跏敲繌埍矶技拥倪@對(duì)門店場(chǎng)景特別重要。員工誤刪一條寵物檔案如果真物理刪除了后續(xù)主人帶寵物來(lái)消費(fèi)時(shí)所有歷史記錄都對(duì)不上連疫苗記錄都沒(méi)了非常麻煩。用邏輯刪除后還能通過(guò)回收站功能找回來(lái)。商品表的設(shè)計(jì)需要注意的一個(gè)細(xì)節(jié)是單位換算。寵物食品和藥品經(jīng)常有“?！焙汀昂小钡牟町愇业淖龇ㄊ窃谏唐繁砝锛右粋€(gè)sale_unit字段同時(shí)設(shè)定stock_warning_line作為庫(kù)存預(yù)警閾值。庫(kù)存預(yù)警不是寫死在代碼里的而是每個(gè)商品單獨(dú)設(shè)置比如皇家貓糧可以設(shè)置10袋預(yù)警體內(nèi)驅(qū)蟲(chóng)藥可以設(shè)置5盒預(yù)警。庫(kù)存流水表是容易被忽略的。很多初版系統(tǒng)只更新商品表的庫(kù)存數(shù)字不做流水記錄一旦盤點(diǎn)對(duì)不上賬完全無(wú)法追溯。我的做法是每一次入庫(kù)、出庫(kù)、盤點(diǎn)調(diào)整都必須往stock_log表里寫一條記錄包含變更前數(shù)量、變更后數(shù)量、操作類型和關(guān)聯(lián)業(yè)務(wù)單號(hào)。這套機(jī)制在后面的對(duì)賬和排查問(wèn)題時(shí)幫了大忙。2.3 為什么要放棄物理外鍵這是個(gè)在老程序員之間經(jīng)常爭(zhēng)論的話題我的個(gè)人選擇是所有表之間的關(guān)聯(lián)都靠應(yīng)用層邏輯維護(hù)數(shù)據(jù)庫(kù)不建物理外鍵。原因其實(shí)很實(shí)際。寵物店管理系統(tǒng)面向的是門店員工誤操作在所難免如果強(qiáng)外鍵約束存在刪除一條主表數(shù)據(jù)時(shí)報(bào)錯(cuò)會(huì)讓員工完全摸不著頭腦。更重要的是MyBatis-Plus做分頁(yè)查詢和邏輯刪除時(shí)物理外鍵還會(huì)造成不少額外困擾比如邏輯刪除的ID還被引用時(shí)外鍵約束本身并不認(rèn)deleted字段。放棄物理外鍵并不代表放棄數(shù)據(jù)一致性核心的一致性靠事務(wù)和業(yè)務(wù)代碼來(lái)保證。我在代碼里處理關(guān)聯(lián)數(shù)據(jù)時(shí)始終遵循先查后改、事務(wù)包裹的原則加上統(tǒng)一的異常處理數(shù)據(jù)出錯(cuò)的風(fēng)險(xiǎn)完全可控。3. 環(huán)境搭建與框架配置這一步穩(wěn)了后面全順3.1 Maven依賴和版本選型實(shí)戰(zhàn)項(xiàng)目構(gòu)建工具我用的是Maven版本選型這塊我直接貼最終的pom核心依賴方便參考。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent properties java.version1.8/java.version mybatis-plus.version3.5.3.1/mybatis-plus.version hutool.version5.8.22/hutool.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version${mybatis-plus.version}/version /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-generator/artifactId version${mybatis-plus.version}/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version${hutool.version}/version /dependency /dependencies這里要提醒一下many people遇到過(guò)一個(gè)典型的噩夢(mèng)就是Spring Boot版本和MyBatis-Plus版本不兼容。如果你的Spring Boot是3.x那么MyBatis-Plus需要引入mybatis-plus-spring-boot3-starter而不是mybatis-plus-boot-starter這個(gè)差異非常隱蔽很多人栽在這里。我的建議是老老實(shí)實(shí)用2.7.x版本線這是目前網(wǎng)上教程覆蓋最全、問(wèn)題排查最容易的版本組合。Java版本我沒(méi)有追高依然使用JDK 8。對(duì)于這個(gè)項(xiàng)目來(lái)說(shuō)JDK 8完全夠用而且不用擔(dān)心服務(wù)器上沒(méi)有高版本運(yùn)行時(shí)。用JDK 8還能兼容大部分老項(xiàng)目的部署環(huán)境實(shí)用性最強(qiáng)。3.2 application.yml配置里的幾個(gè)細(xì)節(jié)Spring Boot的配置看似簡(jiǎn)單但實(shí)際有非常多的細(xì)節(jié)決定系統(tǒng)是否好用。我貼出核心配置段落并逐條解釋。server: port: 8080 servlet: context-path: /api spring: datasource: url: jdbc:mysql://localhost:3306/pet_shop?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowMultiQueriestrue username: root password: root redis: host: localhost port: 6379 mybatis-plus: mapper-locations: classpath:mapper/**/*.xml type-aliases-package: com.petshop.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0允許SQL查詢尾部分號(hào)和多條語(yǔ)句的allowMultiQueriestrue這個(gè)參數(shù)是我在線下踩過(guò)坑之后特意加上的不過(guò)在此建議在明確需要時(shí)才開(kāi)放避免SQL注入面擴(kuò)大。MyBatis-Plus的邏輯刪除配置必須在global-config.db-config里聲明logic-delete-field: deleted同時(shí)實(shí)體類字段上加TableLogic注解兩者缺一不可。如果不加MP的deleteById只是普通刪除查數(shù)據(jù)時(shí)deleted1的臟數(shù)據(jù)會(huì)混進(jìn)來(lái)。log-impl我保留了一個(gè)StdOutImpl開(kāi)發(fā)階段能看到完整的SQL日志但線上一定要關(guān)掉否則日志文件會(huì)爆炸而且會(huì)暴露表結(jié)構(gòu)信息。3.3 統(tǒng)一返回體和全局異常提升接口規(guī)范性的王道統(tǒng)一返回體我定義了一個(gè)Result類核心結(jié)構(gòu)是code、message、data三個(gè)字段。所有controller的返回值都統(tǒng)一用這個(gè)結(jié)構(gòu)包裝前端只需要解析固定格式即可不用每個(gè)接口都定制。Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }全局異常處理我用了一個(gè)RestControllerAdvice類把參數(shù)校驗(yàn)異常、業(yè)務(wù)異常、系統(tǒng)異常分層處理。業(yè)務(wù)異常我自定義了一個(gè)BizException在service層檢測(cè)到不合理狀態(tài)時(shí)直接拋出由全局處理器統(tǒng)一捕獲并返回給前端。這樣controller的參數(shù)校驗(yàn)、service的業(yè)務(wù)校驗(yàn)、dao的SQL異常全部都能在統(tǒng)一的入口處理掉返回給前端的錯(cuò)誤信息也能保證格式整齊。注意不要把SQL異常等系統(tǒng)異常信息原樣拋給前端既泄露底層結(jié)構(gòu)又讓用戶看不懂。全局異常里對(duì)系統(tǒng)級(jí)異常必須打日志同時(shí)返回“系統(tǒng)繁忙請(qǐng)稍后再試”這樣的通用信息。4. 核心功能模塊實(shí)操?gòu)慕涌谠O(shè)計(jì)到代碼落地4.1 寵物檔案模塊一行代碼帶出多維聯(lián)動(dòng)寵物檔案模塊的接口設(shè)計(jì)并不復(fù)雜核心就是CRUD但有幾個(gè)細(xì)節(jié)直接決定系統(tǒng)是否好用。第一個(gè)是查詢接口必須支持多條件組合包括寵物類型、品種、主人姓名、手機(jī)號(hào)、會(huì)員狀態(tài)。前臺(tái)店員最常用的場(chǎng)景是客戶打電話來(lái)預(yù)約店員只記得“張姐的柯基”這時(shí)候要能通過(guò)模糊查詢快速定位到寵物離職率高、新員工上手快是門店軟件的普遍需求。第二個(gè)細(xì)節(jié)是詳情接口要一次性返回帶出所有關(guān)聯(lián)信息包括寵物照片、主人聯(lián)系方式、最近的服務(wù)記錄、未完成的寄養(yǎng)訂單。這里我通過(guò)自定義SQL聯(lián)表查詢實(shí)現(xiàn)避免前端在一次展示頁(yè)面上發(fā)五六次請(qǐng)求。第三方接口設(shè)計(jì)方面我添加了預(yù)約服務(wù)時(shí)校驗(yàn)寵物疫苗狀態(tài)的邏輯未完成疫苗的寵物不允許預(yù)約寄養(yǎng)或者需要彈窗提醒。這個(gè)邏輯就寫在業(yè)務(wù)service里前端同步做交互限制后端做二次校驗(yàn)雙保險(xiǎn)。寵物檔案的service層我用到了事務(wù)注解Transactional(rollbackFor Exception.class)因?yàn)閯?chuàng)建寵物同時(shí)要寫寵物表和寵物照片表任何一個(gè)失敗都要整體回滾。一個(gè)非常容易踩的坑是Transactional默認(rèn)只回滾RuntimeException如果業(yè)務(wù)代碼拋出的是自定義Exception子類默認(rèn)不回滾所以必須顯式聲明rollbackFor Exception.class。4.2 商品與庫(kù)存模塊庫(kù)存扣減的并發(fā)安全問(wèn)題商品模塊引入了一個(gè)非?，F(xiàn)實(shí)的場(chǎng)景雙11、節(jié)假日促銷時(shí)多個(gè)人同時(shí)下單搶同一個(gè)貓糧商品庫(kù)存只有3件結(jié)果訂單生成了5件庫(kù)存變成負(fù)數(shù)。這個(gè)問(wèn)題是所有進(jìn)銷存系統(tǒng)的經(jīng)典難題。我的解決思路是采用原子更新加樂(lè)觀鎖控制。在庫(kù)存扣減的SQL語(yǔ)句上不使用先查后改的方式而是直接在update語(yǔ)句中做條件判斷UPDATE product_info SET stock stock - #{count} WHERE id #{productId} AND stock #{count}這條SQL保證了扣庫(kù)存和檢查庫(kù)存是原子操作不會(huì)出現(xiàn)超賣。同時(shí)配合Transactional整個(gè)訂單生成和庫(kù)存扣減在一個(gè)事務(wù)里完成。如果update影響行數(shù)為0說(shuō)明庫(kù)存不足直接拋出業(yè)務(wù)異常。高并發(fā)場(chǎng)景下訂單量非常大時(shí)單條update會(huì)成為數(shù)據(jù)庫(kù)熱行競(jìng)爭(zhēng)瓶頸可以引入Redis的預(yù)扣庫(kù)存方案。但在寵物店這種門店級(jí)系統(tǒng)里單條update已經(jīng)足夠引入Redis緩存方案反而要考慮緩存和數(shù)據(jù)庫(kù)一致性問(wèn)題得不償失。根據(jù)實(shí)際業(yè)務(wù)量選擇合適的技術(shù)方案這是我在做系統(tǒng)設(shè)計(jì)時(shí)反復(fù)給自己強(qiáng)調(diào)的原則。庫(kù)存預(yù)警我用Spring Boot自帶定時(shí)任務(wù)Scheduled實(shí)現(xiàn)每天凌晨檢查一次商品表把stock低于stock_warning_line的商品列表整理出來(lái)通過(guò)企業(yè)微信機(jī)器人Webhook推送通知店長(zhǎng)。定時(shí)任務(wù)最大的坑是默認(rèn)單線程串行執(zhí)行如果有多個(gè)定時(shí)任務(wù)在相同時(shí)間點(diǎn)觸發(fā)其中一個(gè)阻塞全部影響。我特意通過(guò)配置類設(shè)置了線程池讓不同任務(wù)互不干擾。4.3 會(huì)員儲(chǔ)值與訂單模塊金額相關(guān)必須流水可溯會(huì)員儲(chǔ)值模塊是寵物店系統(tǒng)里最敏感的模塊涉及到真金白銀設(shè)計(jì)核心就一條每次變動(dòng)必須留痕。我的表結(jié)構(gòu)是member_account和member_recharge_log兩張表。會(huì)員表的balance字段只做展示和校驗(yàn)真正的余額變動(dòng)全部通過(guò)流水表來(lái)記錄。充值業(yè)務(wù)發(fā)生時(shí)事務(wù)內(nèi)做兩件事更新會(huì)員余額插入一條type充值 的流水記錄。消費(fèi)扣款時(shí)同樣插入一條type消費(fèi) 的流水記錄同時(shí)關(guān)聯(lián)到訂單id。這里有一個(gè)實(shí)際業(yè)務(wù)中反復(fù)出現(xiàn)的需求儲(chǔ)值贈(zèng)送。門店經(jīng)常搞“充500送100”的活動(dòng)這100塊的贈(zèng)送金額如果直接并進(jìn)余額那用戶在退卡時(shí)就會(huì)面臨“贈(zèng)送金額是否退還”的糾紛。我的做法是區(qū)分充值本金和贈(zèng)送金在會(huì)員余額表里維護(hù)available_balance和bonus_balance兩個(gè)字段消費(fèi)時(shí)默認(rèn)先花贈(zèng)送金再花本金退款時(shí)優(yōu)先退本金。這套規(guī)則雖然簡(jiǎn)單但實(shí)際門店幾乎都對(duì)這種細(xì)節(jié)特別講究是增強(qiáng)系統(tǒng)粘性的關(guān)鍵。訂單模塊我用主從表結(jié)構(gòu)主表存訂單號(hào)、會(huì)員id、總金額、支付方式、狀態(tài)明細(xì)表存商品快照。商品快照是整個(gè)訂單系統(tǒng)的要點(diǎn)下單時(shí)就把商品名稱、單價(jià)、數(shù)量原樣保存進(jìn)訂單明細(xì)表后續(xù)即使商品價(jià)格調(diào)整訂單記錄仍保持下單時(shí)的價(jià)格避免財(cái)務(wù)對(duì)賬糾紛。如果不做快照只關(guān)聯(lián)商品id三個(gè)月后商品改價(jià)了翻舊賬時(shí)會(huì)發(fā)現(xiàn)所有歷史訂單金額都是錯(cuò)的。4.4 服務(wù)預(yù)約與寄養(yǎng)模塊時(shí)間沖突校驗(yàn)是關(guān)鍵預(yù)約模塊的代碼難點(diǎn)在于時(shí)間沖突判斷。客戶預(yù)訂某個(gè)時(shí)間段給寵物洗澡系統(tǒng)必須判斷該時(shí)段美容師是否已排滿。我的預(yù)約表結(jié)構(gòu)里有一個(gè)time_slot字段存的是時(shí)間段編號(hào)比如上午第一時(shí)段、下午第二時(shí)段。為了避免沖突我在service層的處理邏輯是查詢指定美容師在指定日期、指定時(shí)間段內(nèi)是否有已確認(rèn)的預(yù)約如果有且未取消則拒絕新預(yù)約。這條查詢加上唯一索引employee_id, appointment_date, time_slot, status后能保證極端情況下也不會(huì)出現(xiàn)重復(fù)預(yù)約。這里的status必須是非取消狀態(tài)。寄養(yǎng)模塊需要注意的是自動(dòng)計(jì)算費(fèi)用的邏輯。寄養(yǎng)費(fèi)用按天計(jì)費(fèi)取寵和送寵的時(shí)間要精確到小時(shí)但實(shí)際結(jié)算時(shí)門店通行的規(guī)則是“不滿一天按一天算”。我在代碼里用一個(gè)簡(jiǎn)單的日期計(jì)算邏輯來(lái)覆蓋這個(gè)規(guī)則傳入入店時(shí)間和離店時(shí)間計(jì)算出應(yīng)該收取的天數(shù)。這個(gè)邏輯看起來(lái)簡(jiǎn)單但實(shí)際能避免大量和客戶的糾紛。5. 踩坑實(shí)錄那些讓我印象深刻的線上問(wèn)題5.1 日期格式化引發(fā)的前后端數(shù)據(jù)錯(cuò)亂這是幾乎每個(gè)Spring Boot項(xiàng)目都會(huì)遇到的問(wèn)題。后端返回的時(shí)間格式是2024-03-15T09:30:00前端直接原樣顯示出來(lái)門店店員看到這個(gè)帶T的日期一頭霧水。原因在于Spring Boot默認(rèn)的Jackson序列化對(duì)LocalDateTime采用的是ISO-8601格式并不是我們習(xí)慣的yyyy-MM-dd HH:mm:ss。解決方案是在application.yml里配置全局日期格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8但是這個(gè)方法只對(duì)java.util.Date生效對(duì)LocalDateTime無(wú)效。這也是最隱蔽的地方。要徹底解決LocalDateTime的格式問(wèn)題需要添加一個(gè)Jackson自定義配置類注冊(cè)LocalDateTimeSerializer和LocalDateTimeDeserializer。我上線第一周就接到門店反饋“時(shí)間顯示不對(duì)”排查了快兩個(gè)小時(shí)才發(fā)現(xiàn)是LocalDateTime沒(méi)有全局格式化覆蓋而 Date類型正常。這個(gè)教訓(xùn)讓我明白了前后端聯(lián)調(diào)開(kāi)始前必須在接口文檔里固定所有日期時(shí)間的傳輸格式。5.2 事務(wù)失效沒(méi)走代理的坑我有一個(gè)在service層內(nèi)部的私有方法調(diào)用事務(wù)方法的場(chǎng)景結(jié)果發(fā)現(xiàn)事務(wù)根本沒(méi)有生效。查下來(lái)才知道事務(wù)是通過(guò)Spring AOP代理實(shí)現(xiàn)的內(nèi)部this調(diào)用不經(jīng)過(guò)代理對(duì)象所以Transactional注解根本不會(huì)生效。這件事發(fā)生在會(huì)員退款業(yè)務(wù)里。我在withdrawRefund方法里調(diào)用了內(nèi)部private方法updateBalanceupdateBalance上有Transactional按預(yù)期應(yīng)該和外部方法一起組成一個(gè)事務(wù)結(jié)果updateBalance執(zhí)行失敗拋出異常后前面的操作已經(jīng)提交了沒(méi)法回滾。解決方案非常粗暴把事務(wù)注解加到外部公開(kāi)方法withdrawRefund上或者在類內(nèi)部通過(guò)代理對(duì)象調(diào)方法。這個(gè)坑特別隱蔽尤其對(duì)于前期不是特別熟悉Spring底層原理的人建議直接把事務(wù)邊界放在controller調(diào)用的第一個(gè)service方法上這樣最穩(wěn)妥。提示事務(wù)注解加在public方法上才生效加在private方法上靜默失效。調(diào)用必須走代理對(duì)象同類內(nèi)部直接this調(diào)用同樣失效。這是Spring事務(wù)最常見(jiàn)的問(wèn)題來(lái)源。5.3 邏輯刪除和唯一索引的沖突這是實(shí)踐里非常頭疼的一個(gè)問(wèn)題。我為會(huì)員表的phone字段設(shè)置了唯一索引用戶注銷后邏輯刪除deleted1數(shù)據(jù)還在表里結(jié)果新注冊(cè)用戶用了同一個(gè)手機(jī)號(hào)插入操作直接觸發(fā)了唯一索引沖突。常規(guī)解決辦法有三條路。第一條是唯一索引不能設(shè)置在phone這個(gè)字段上可以改成phone deleted的方式但MySQL唯一索引中deleted全是0和1兩個(gè)邏輯刪除的用戶仍然沖突。第二條是把deleted改成隨機(jī)的唯一字符串比如刪除時(shí)deleted當(dāng)前時(shí)間戳拼接隨機(jī)數(shù)保證每次刪除的deleted值都不同這樣聯(lián)合唯一索引不沖突。第三條是把已刪除的數(shù)據(jù)物理遷走比如獨(dú)立歸檔表。我目前選擇的是第二種方案實(shí)現(xiàn)成本最低。系統(tǒng)里刪除用戶時(shí)將deleted字段更新為業(yè)務(wù)主鍵的負(fù)值和隨機(jī)串確保聯(lián)合唯一索引的唯一性。這個(gè)方案在維護(hù)性和實(shí)現(xiàn)成本上都比較平衡。5.4 枚舉映射tinyint還是字符串我在寵物類型字段上使用了TINYINT類型存儲(chǔ)1貓、2狗、3其他。這個(gè)設(shè)計(jì)看似沒(méi)有錯(cuò)但聯(lián)調(diào)時(shí)前端傳了一個(gè)字符串2給后端MyBatis-Plus自動(dòng)類型轉(zhuǎn)換失敗導(dǎo)致接口直接報(bào)500。排查后發(fā)現(xiàn)問(wèn)題根源在于前端傳參時(shí)沒(méi)有嚴(yán)格遵守類型約束。我的建議是在項(xiàng)目里用枚舉類型而不是直接用Integer和String來(lái)回倒在實(shí)體類屬性上配合EnumValue注解使用MyBatis-Plus的枚舉映射功能。這個(gè)方案能讓代碼里只出現(xiàn)PetTypeEnum.CAT這樣的語(yǔ)義化寫法既避免魔法數(shù)字又是一處硬約束。從項(xiàng)目管理角度看很久之后再看代碼一眼就能明白這個(gè)字段的含義維護(hù)成本大幅降低。6. 打包部署與上線從一個(gè)jar包說(shuō)起6.1 Spring Boot的打包策略Spring Boot項(xiàng)目最終產(chǎn)物就是一個(gè)可執(zhí)行的jar包這是它相比傳統(tǒng)SSH項(xiàng)目最大的便捷點(diǎn)。打包時(shí)我用的是Maven的spring-boot-maven-plugin執(zhí)行mvn clean package -DskipTests即可。跳過(guò)測(cè)試這個(gè)參數(shù)建議日常就用上不是因?yàn)闇y(cè)試不重要而是大部分私活項(xiàng)目根本沒(méi)有完善的測(cè)試用例每次打包跑一遍全是紅色報(bào)錯(cuò)只會(huì)浪費(fèi)時(shí)間。前端Vue項(xiàng)目打包后生成dist目錄把dist目錄里的static和index.html復(fù)制到Spring Boot項(xiàng)目的src/main/resources/static路徑下重新打包Java工程最終一個(gè)jar包就同時(shí)包含了后端接口和前端頁(yè)面。訪問(wèn)時(shí)直接通過(guò)同一端口進(jìn)入省去了配置Nginx和跨域的工作。這種方式對(duì)中小型系統(tǒng)非常友好唯一需要注意的問(wèn)題是前端路由模式必須改成hash模式否則刷新頁(yè)面時(shí)會(huì)404。雖然把前端放進(jìn)jar包在工程上不是最優(yōu)解但對(duì)個(gè)人或小團(tuán)隊(duì)接門店項(xiàng)目來(lái)說(shuō)客戶只關(guān)心能不能雙擊啟動(dòng)部署人員只需要一個(gè)jar包這臺(tái)機(jī)器上跑起來(lái)就完了。按場(chǎng)景選擇方案而不是追求架構(gòu)的絕對(duì)先進(jìn)這是我長(zhǎng)期接小項(xiàng)目的核心心得。6.2 上線環(huán)境里常見(jiàn)的兩個(gè)坑第一個(gè)坑是MySQL 8.0的密碼加密規(guī)則。MySQL 8.0默認(rèn)的caching_sha2_password認(rèn)證插件和老版本的JDBC驅(qū)動(dòng)不兼容項(xiàng)目啟動(dòng)時(shí)就會(huì)報(bào)Public Key Retrieval is not allowed的錯(cuò)。解決方案是把JDBC驅(qū)動(dòng)版本升級(jí)到8.0.x或者在連接串中加allowPublicKeyRetrievaltrue。類似問(wèn)題在首次部署時(shí)特別常見(jiàn)提前排掉這個(gè)坑能省很多事。第二個(gè)坑是服務(wù)器時(shí)區(qū)問(wèn)題。新買的云服務(wù)器默認(rèn)時(shí)區(qū)是UTC和本地時(shí)區(qū)不一致插入數(shù)據(jù)庫(kù)的時(shí)間就會(huì)晚8小時(shí)所有報(bào)表數(shù)據(jù)對(duì)不上。啟動(dòng)jar包時(shí)建議在JVM參數(shù)里加上-Duser.timezoneAsia/Shanghai同時(shí)在application.yml里也固定了serverTimezone兩處都設(shè)置才能萬(wàn)無(wú)一失。磁盤空間問(wèn)題也值得一提。應(yīng)用日志默認(rèn)按天滾動(dòng)但門店這種體量的系統(tǒng)如果不加日志清理策略一兩年后日志就能占滿磁盤。我在配置里把日志保留期設(shè)置為30天大小超過(guò)100MB自動(dòng)切割并且做了定時(shí)清理的腳本。這些細(xì)節(jié)可能看起來(lái)不起眼但上線維護(hù)的投入會(huì)被這些細(xì)枝末節(jié)無(wú)限放大。7. 復(fù)盤與經(jīng)驗(yàn)沉淀這個(gè)寵物店管理系統(tǒng)從立項(xiàng)到上線前后大約用了六周時(shí)間。整個(gè)過(guò)程中我最大的感受是技術(shù)選型上不需要追求新潮穩(wěn)定可靠才是第一位的。Spring Boot 2.7 MyBatis-Plus Vue這套組合雖然不算前沿但放到門店管理這個(gè)場(chǎng)景里非常匹配團(tuán)隊(duì)協(xié)作效率高、問(wèn)題排查快、客戶反饋好。很多開(kāi)發(fā)者在做類似項(xiàng)目時(shí)容易陷入“為了解決一個(gè)不存在的高并發(fā)問(wèn)題而把系統(tǒng)架構(gòu)搞復(fù)雜”的陷阱。寵物店的門店規(guī)模決定了它的并發(fā)量白天高峰期同時(shí)在線操作的員工能超過(guò)10個(gè)人就算不錯(cuò)了。真正考驗(yàn)系統(tǒng)的不是并發(fā)而是業(yè)務(wù)邏輯的完整性、數(shù)據(jù)的一致性、操作的便捷性。把會(huì)員儲(chǔ)值流水做清楚、把庫(kù)存扣減做成原子操作、把預(yù)約時(shí)的時(shí)間沖突校驗(yàn)做嚴(yán)謹(jǐn)這些才是這個(gè)系統(tǒng)真正的價(jià)值所在。這也是我在復(fù)盤之后最大的收獲——好的管理系統(tǒng)不是炫技的舞臺(tái)而是把矛盾規(guī)避在過(guò)程里的工具。最后再分享一個(gè)經(jīng)驗(yàn)接這種傳統(tǒng)行業(yè)的軟件需求一定要提前去門店現(xiàn)場(chǎng)蹲半天?？纯吹陠T結(jié)賬時(shí)是右手拿掃碼槍還是兩手打字看看柜臺(tái)上客戶等待的耐心極限甚至看看墻面貼著的價(jià)格表是什么樣。這些細(xì)節(jié)很多是寫進(jìn)需求文檔里根本不會(huì)出現(xiàn)的盲區(qū)但決定了做出來(lái)的系統(tǒng)店員愿不愿意用、真正用不用的起來(lái)。我這次去蹲點(diǎn)的時(shí)候發(fā)現(xiàn)店員結(jié)賬時(shí)經(jīng)常需要一手抱寵物一手操作電腦所以整個(gè)前端的按鈕都做得足夠大、步驟壓到最少操作路徑短的方案得到了門店的一致好評(píng)。技術(shù)是死的但場(chǎng)景是活的蹲下去才能看到真問(wèn)題。