做過電商系統(tǒng)的朋友都知道藥品商城跟普通賣衣服、賣數(shù)碼產(chǎn)品的商城根本不是一回事。它的背后牽涉到藥品信息合規(guī)展示、庫存批次跟蹤、處方藥銷售管控、甚至還有遠(yuǎn)程問診開方的需求。而SSM也就是Spring SpringMVC MyBatis這套經(jīng)典組合在這種業(yè)務(wù)復(fù)雜度中等但事務(wù)性極強的系統(tǒng)里反而是非常合適的選擇。幾天前我把一個基于SSM的藥品電子商城系統(tǒng)完整跑通了一遍從數(shù)據(jù)庫設(shè)計到在線診斷模塊的聯(lián)調(diào)前前后后踩了不少坑。如果你正準(zhǔn)備做類似項目或者正在用SSM寫醫(yī)療類電商系統(tǒng)這篇文章應(yīng)該能幫你少走很多彎路。先簡單說說它到底是個什么東西它本質(zhì)上是一個B2C藥品銷售平臺疊加了在線問診與電子處方流轉(zhuǎn)能力核心用戶是普通消費者和坐診藥師代碼結(jié)構(gòu)上按SSM標(biāo)準(zhǔn)三層架構(gòu)來組織。適合用SpringMVC做控制層、MyBatis做持久層、Spring做業(yè)務(wù)事務(wù)管理的中小型團隊或個人開發(fā)者作為參考。系統(tǒng)設(shè)計與架構(gòu)選型思路1.1 為什么藥品商城仍適合用SSM而非微服務(wù)近幾年微服務(wù)架構(gòu)被炒得很熱動不動就Spring Cloud、Dubbo但對于一個藥品電子商城加在線診斷系統(tǒng)而言我反而堅持用SSM單體架構(gòu)理由其實不復(fù)雜。首先藥品商城這類系統(tǒng)的核心痛點不在于并發(fā)量而在于事務(wù)一致性和業(yè)務(wù)流程的準(zhǔn)確性。一次下單動作可能同時要扣減藥品庫存、鎖定優(yōu)惠券、生成訂單快照、記錄操作日志如果這幾步操作被拆到多個服務(wù)里就得引入分布式事務(wù)成本和復(fù)雜度陡然上升。而在SSM單體架構(gòu)下一個Spring管理的Service方法里數(shù)據(jù)庫事務(wù)天然就覆蓋了這幾個操作要么全部成功要么全部回滾邏輯極容易把控。其次SSM技術(shù)棧非常成熟招人容易、文檔多、排錯簡單。MyBatis的靈活SQL非常適合醫(yī)療電商里大量動態(tài)查詢和復(fù)雜報表統(tǒng)計的場景SpringMVC的注解開發(fā)讓接口層代碼一目了然Spring的IoC與AOP做權(quán)限攔截和事務(wù)管理也非常順手。整個項目不需要額外引入注冊中心、配置中心、消息隊列對中小型團隊來說維護成本便宜得多。1.2 藥品電商的核心業(yè)務(wù)流程拆解我最初接手這個系統(tǒng)時第一件事不是看代碼而是先把藥品銷售的合規(guī)路徑梳理清楚。一個常規(guī)的藥品電子商城其核心業(yè)務(wù)流程大致如下用戶注冊登錄后瀏覽藥品目錄查詢藥品時不僅要看價格還要區(qū)分處方藥與非處方藥非處方藥可以直接加入購物車下單購買處方藥則必須先發(fā)起在線診斷或問診由藥師或醫(yī)師確認(rèn)后開具電子處方有了處方后系統(tǒng)校驗處方有效性并允許提交訂單訂單支付后進入后臺審核倉庫按批次揀貨出庫物流完成后用戶可確認(rèn)收貨整個流程閉環(huán)在線診斷模塊之所以和商城深度綁定是因為處方藥銷售必須建立醫(yī)生/藥師與患者的互動記錄。系統(tǒng)里診斷記錄與處方單據(jù)需要存留可追溯的電子檔案包括患者主訴、藥師建議、處方藥名稱、用法用量等。這塊在設(shè)計時我特意做了獨立的業(yè)務(wù)表而沒有把它塞進訂單表里目的就是方便后續(xù)擴展隨訪功能。1.3 模塊劃分與代碼包結(jié)構(gòu)設(shè)計SSM項目最怕的就是代碼層層堆在一起時間長了連自己都找不到是哪一層出問題。我在設(shè)計這個系統(tǒng)時嚴(yán)格按MVC三層加模塊分包主要模塊包括用戶模塊普通用戶、藥師、管理員三種角色藥品模塊藥品分類、藥品信息、藥品規(guī)格與批次庫存購物車與訂單模塊購物車管理、訂單生成、支付回調(diào)在線診斷模塊問診會話、診斷病歷、處方單系統(tǒng)管理模塊角色權(quán)限、操作日志、數(shù)據(jù)統(tǒng)計對應(yīng)的Java包結(jié)構(gòu)大致是這樣com.medical.mall ├── controller # 控制層接收前端請求 │ ├── UserController │ ├── DrugController │ ├── CartController │ ├── OrderController │ └── DiagnosisController ├── service # 業(yè)務(wù)層核心事務(wù)邏輯 │ ├── impl │ └── ... ├── dao # 數(shù)據(jù)訪問層MyBatis Mapper接口 ├── pojo # 實體類、Vo、Dto ├── common # 公共工具類、常量、統(tǒng)一結(jié)果封裝 └── config # Spring、MyBatis、SpringMVC配置這樣的分包方式讓我在開發(fā)在線診斷模塊時可以直接復(fù)用用戶管理和藥品管理的基礎(chǔ)能力同時又能保證業(yè)務(wù)隔離避免一個模塊的改動牽連到其他模塊。特別是涉及處方藥這類敏感業(yè)務(wù)時獨立模塊也方便日后單獨做權(quán)限收緊。數(shù)據(jù)庫建模與核心表設(shè)計2.1 藥品信息表的設(shè)計細(xì)節(jié)藥品商品信息和普通商品不同它在建表時需要更多的字段來承載合規(guī)要求。我的t_drug表設(shè)計時除了基礎(chǔ)的藥品名稱、通用名、生產(chǎn)廠家、批準(zhǔn)文號之外還包含了劑型、規(guī)格、單位、存儲條件、有效期、處方類型等字段。其中比較關(guān)鍵的幾個字段有drug_type區(qū)分處方藥與OTC前端展示時用來控制購買流程approval_number藥品批準(zhǔn)文號如國藥準(zhǔn)字H開頭代表化學(xué)藥品、Z代表中成藥這個字段必須唯一stock_batch批次號對應(yīng)倉庫里實際入庫的批次expiry_date有效期截止日期訂單創(chuàng)建時必須校驗require_diagnosis是否需要在線診斷通由drug_type推導(dǎo)但保留冗余字段建表時還有一個容易忽略的地方——藥品圖片與說明書附件不能直接存在主表里。我是用了單獨的附件表來存儲圖片、PDF說明書等文件URL用drug_id關(guān)聯(lián)這樣查詢藥品列表時不會因為讀取大字段拖慢接口速度。藥品表的DDL核心部分大致如下CREATE TABLE t_drug ( id bigint(20) NOT NULL AUTO_INCREMENT, drug_code varchar(50) NOT NULL COMMENT 藥品唯一編碼, drug_name varchar(100) NOT NULL COMMENT 藥品名稱, generic_name varchar(100) DEFAULT NULL COMMENT 通用名, approval_number varchar(50) DEFAULT NULL COMMENT 批準(zhǔn)文號, drug_type tinyint(4) NOT NULL COMMENT 1-處方藥 2-OTC, dosage_form varchar(50) DEFAULT NULL COMMENT 劑型, specification varchar(100) DEFAULT NULL COMMENT 規(guī)格, unit varchar(20) DEFAULT NULL COMMENT 單位, price decimal(10,2) NOT NULL COMMENT 銷售單價, stock_total int(11) NOT NULL DEFAULT 0 COMMENT 庫存總量, require_diagnosis tinyint(1) NOT NULL DEFAULT 0 COMMENT 是否需診斷, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 上下架狀態(tài), create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_drug_code (drug_code), KEY idx_drug_type (drug_type), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;2.2 庫存批次模型藥品庫存為何不能只存一個總數(shù)在做一個普通商品庫存時可能一個stock字段就搞定了但藥品庫存一定要拆成批次來管理。原因很簡單不同批次的藥品生產(chǎn)日期和有效期不一樣同一個藥品不同批次到期時間不同的情況非常常見。如果只用一個總數(shù)揀貨時判斷近效期藥品完全無從下手。為此我設(shè)計了t_drug_stock_batch表以batch_no為維度記錄每個批次的入庫數(shù)量、剩余數(shù)量、生產(chǎn)日期、有效期。訂單發(fā)貨時系統(tǒng)優(yōu)先揀取有效期最近的批次也就是“先進先出”而到了更新庫存時則需要同時更新批次表的剩余數(shù)和藥品表的總庫存數(shù)。這個過程我在事務(wù)里做保證兩邊數(shù)據(jù)一致。用了批次模型以后入庫操作也變得清晰了。每次采購入庫只需向批次表插入一條記錄并累加藥品主表庫存每次用戶下單則需要在事務(wù)里預(yù)占庫存我這版用的是樂觀鎖方式更新批次剩余量時加WHERE remaining_qty #{qty}受影響行數(shù)為0則說明并發(fā)沖突重新嘗試或提示用戶庫存不足。2.3 在線診斷與處方單的數(shù)據(jù)結(jié)構(gòu)在線診斷模塊的數(shù)據(jù)模型是我整個項目里花時間最多的部分因為它直接關(guān)系到合規(guī)性。診斷主表t_diagnosis記錄一次問診會話的基本信息包括患者用戶ID、接診藥師ID、問診狀態(tài)、癥狀描述、初步診斷結(jié)果、創(chuàng)建時間。一次診斷會話可以對應(yīng)多條消息記錄也可以生成一張或多張?zhí)幏絾?。處方單表t_prescription設(shè)計時我特意包含了處方號、診斷ID、患者ID、藥師ID、處方類型、用法用量描述、有效天數(shù)、開方時間、過期時間、處方狀態(tài)。這里有一個非常關(guān)鍵的字段是處方有效期。按照常規(guī)實踐電子處方一般有效期為3天過期后系統(tǒng)應(yīng)自動作廢不允許用戶繼續(xù)用它結(jié)算購藥。我在訂單提交時做了一個校驗方法專門判斷處方是否處于有效期內(nèi)。處方明細(xì)表t_prescription_item則以藥品為粒度記錄每種藥的名稱、劑量、用藥頻次、用藥天數(shù)、總數(shù)量。處方明細(xì)與商城藥品主表并不直接強關(guān)聯(lián)外鍵因為處方歷史是歸檔數(shù)據(jù)即使藥品后來下架了也要保留當(dāng)時的開方內(nèi)容。這也是我在設(shè)計上堅持基本不動用物理外鍵的原因——歷史數(shù)據(jù)完整性比關(guān)系完整性更重要。核心功能實現(xiàn)從藥品檢索到在線開方3.1 藥品分類檢索與條件篩選實現(xiàn)藥品檢索頁的篩選條件往往比普通商品復(fù)雜。用戶可能需要按藥品種類中成藥、化學(xué)藥、保健品、按處方類型處方藥、OTC、按疾病癥狀感冒、發(fā)燒、腸胃甚至按廠家來篩選。如果用普通拼接SQL方式寫死后期擴展極為痛苦這里MyBatis的動態(tài)SQL就成了利器。我在Mapper中采用where標(biāo)簽加if標(biāo)簽動態(tài)拼條件比如select idsearchDrugs resultTypecom.medical.mall.pojo.Drug SELECT d.id, d.drug_code, d.drug_name, d.generic_name, d.specification, d.unit, d.price, d.drug_type, d.require_diagnosis, d.factory_name FROM t_drug d where d.status 1 if testkeyword ! null and keyword ! AND (d.drug_name LIKE CONCAT(%, #{keyword}, %) OR d.generic_name LIKE CONCAT(%, #{keyword}, %) OR d.factory_name LIKE CONCAT(%, #{keyword}, %)) /if if testdrugType ! null AND d.drug_type #{drugType} /if if testcategoryId ! null AND d.category_id #{categoryId} /if if testminPrice ! null AND d.price #{minPrice} /if if testmaxPrice ! null AND d.price lt; #{maxPrice} /if /where ORDER BY d.id DESC /select這里需要注意MyBatis中使用小于號時記得轉(zhuǎn)義為lt;尤其寫在XML里否則解析會直接報錯。這種情況我在改生產(chǎn)SQL時碰到不止一次調(diào)了半天最后發(fā)現(xiàn)是特殊符號轉(zhuǎn)義問題相當(dāng)浪費時間。3.2 購物車與訂單提交事務(wù)邊界如何劃購物車加購與下單流程中最容易出錯的就是庫存扣減與訂單生成的原子性。我的處理方式是把購物車選中商品生成訂單的過程做成一個Service方法加上Transactional注解內(nèi)部依次做幾件事——校驗每個藥品的上架狀態(tài)、校驗處方藥是否攜帶有效處方、預(yù)扣庫存、生成訂單主表和明細(xì)表、清空購物車對應(yīng)項。任何一步失敗整個方法回滾。具體實現(xiàn)片段如下Transactional(rollbackFor Exception.class) public Order createOrder(OrderCreateDTO dto, Long userId) { // 1. 校驗購物車項目 ListCartItem items cartMapper.selectSelectedItems(dto.getCartItemIds(), userId); if (CollectionUtils.isEmpty(items)) { throw new BusinessException(購物車選中項為空); } // 2. 校驗藥品狀態(tài)及合規(guī)信息 for (CartItem item : items) { Drug drug drugMapper.selectById(item.getDrugId()); if (drug null || drug.getStatus() ! 1) { throw new BusinessException(藥品不存在或已下架 item.getDrugName()); } if (drug.getRequireDiagnosis() 1) { // 處方藥必須攜帶有效處方 Prescription pres prescriptionMapper.selectValidByUserAndId( dto.getPrescriptionId(), userId); if (pres null || pres.getStatus() ! 1) { throw new BusinessException(處方藥必須憑有效處方購買); } } } // 3. 生成訂單號并保存訂單 String orderNo generateOrderNo(); Order order new Order(); order.setOrderNo(orderNo).setUserId(userId); order.setTotalAmount(calTotalAmount(items)); order.setStatus(0); // 待支付 orderMapper.insert(order); // 4. 保存訂單明細(xì) for (CartItem item : items) { OrderItem oi new OrderItem(); oi.setOrderId(order.getId()); oi.setDrugId(item.getDrugId()); oi.setDrugName(item.getDrugName()); oi.setPrice(item.getPrice()); oi.setQty(item.getQty()); orderItemMapper.insert(oi); } // 5. 預(yù)占庫存并清空購物車 for (CartItem item : items) { int rows drugStockBatchMapper.deductStock(item.getDrugId(), item.getQty()); if (rows 0) { throw new BusinessException(庫存不足 item.getDrugName()); } } cartMapper.removeByIds(dto.getCartItemIds(), userId); return order; }這里有一個細(xì)節(jié)值得單獨說明事務(wù)方法內(nèi)部如果catch了異常而不往外拋Spring的Transactional默認(rèn)不會回滾。我一開始踩過這個坑后來定了一個團隊規(guī)范——Service層只負(fù)責(zé)業(yè)務(wù)邏輯不吞異常所有異常在Controller層統(tǒng)一處理并轉(zhuǎn)成前端可見的提示信息。這個用AOP可以做得很干凈代碼里也清爽不少。3.3 在線診斷的會話式交互與狀態(tài)流轉(zhuǎn)在線診斷模塊我做成了一種類客服的會話模式?；颊甙l(fā)起問診請求后系統(tǒng)自動進入等待分配狀態(tài)藥師登錄后臺看到待接診隊列點擊接診后雙方進入一對一會話。這里的核心是會話狀態(tài)的流轉(zhuǎn)管理我在t_diagnosis表里用status字段來表示0等待接診、1問診中、2藥師已開方、3已完成、4已取消?；颊甙l(fā)送消息時調(diào)用的Controller大致下面這樣PostMapping(/api/diagnosis/send) public Result sendMessage(RequestBody DiagnosisMessageDTO dto, SessionAttribute(userId) Long userId) { Diagnosis diagnosis diagnosisService.getById(dto.getDiagnosisId()); if (diagnosis null || !diagnosis.getPatientId().equals(userId)) { return Result.error(會話不存在或無權(quán)限); } if (diagnosis.getStatus() ! 1) { return Result.error(當(dāng)前會話不在問診中); } diagnosisService.saveMessage(dto.getDiagnosisId(), userId, dto.getContent()); return Result.success(); }這段代碼里有幾個細(xì)節(jié)很容易被忽略。首先會話權(quán)限校驗不只是判斷用戶是否登錄還要判斷當(dāng)前用戶是不是該會話的歸屬患者否則用戶A把會話ID改成B就能看到B的病歷信息這是醫(yī)療數(shù)據(jù)的大忌。其次狀態(tài)校驗放在Service邊界之外只是控制層的快速失敗策略真正嚴(yán)謹(jǐn)?shù)呐袛啾仨氃赟ervice里再做一次。藥師開方時系統(tǒng)支持三種操作開具處方、補充建議、結(jié)束會話。開具處方時會生成t_prescription記錄并把診斷狀態(tài)從問診中改為“已開方”。開方后患者端可以立刻看到電子處方處方確認(rèn)無誤后就可以直接跳轉(zhuǎn)購藥。整個流程閉環(huán)做下來體驗上比線下藥店排隊等候要順暢得多。3.4 處方有效期校驗與訂單聯(lián)動處方有效期是整個藥品電子商城合規(guī)要求里特別容易忽略但特別重要的一環(huán)。我在t_prescription表設(shè)計時預(yù)留了effective_days和expire_time字段每次創(chuàng)建處方時自動計算過期時間。在訂單提交Service里獲取處方對象后還要再檢查一下過期時間與當(dāng)前時間的關(guān)系public Prescription checkValidPrescription(Long prescriptionId, Long userId) { Prescription prescription prescriptionMapper.selectById(prescriptionId); if (prescription null || !prescription.getPatientId().equals(userId)) { throw new BusinessException(處方不存在或與當(dāng)前用戶不匹配); } if (prescription.getStatus() ! 1) { throw new BusinessException(處方當(dāng)前不可用); } if (prescription.getExpireTime().before(new Date())) { // 自動作廢 prescriptionMapper.updateStatus(prescriptionId, 2); throw new BusinessException(處方已過期請重新問診開方); } return prescription; }過期的處方自動作廢這個邏輯我是在訂單環(huán)節(jié)觸發(fā)的而不是定時任務(wù)批量掃的。原因在于定時任務(wù)掃描有延遲如果用戶正好卡在過期后的訂單提交節(jié)點定時任務(wù)還沒跑就會導(dǎo)致一張過期處方被繼續(xù)使用。這里采用提交時實時校驗并順手作廢的方式時效性更強。SSM各層協(xié)作與關(guān)鍵配置細(xì)節(jié)4.1 MyBatis Mapper接口與XML映射的協(xié)同SSM項目里MyBatis的使用是核心中的核心。我的習(xí)慣是Mapper接口只定義方法簽名SQL寫在對應(yīng)的XML文件中原因很簡單復(fù)雜SQL寫在注解里會非常難看特別是有大量動態(tài)條件和多表關(guān)聯(lián)時XML的include標(biāo)簽還能復(fù)用公共SQL片段比注解干凈太多。這里有一個非常值得推薦的技巧——用MyBatis的sql標(biāo)簽把常用查詢字段抽出來例如sql idBase_Column_List id, drug_code, drug_name, generic_name, approval_number, drug_type, dosage_form, specification, unit, price, stock_total, require_diagnosis, factory_name, status /sql然后用include refidBase_Column_List/去引用。這樣每條SQL都不會因為字段過多導(dǎo)致可讀性下降。另一個需要注意的點是結(jié)果映射如果表字段和下劃線命名與Java駝峰命名不一致項目啟動時一定要設(shè)置mapUnderscoreToCamelCase為true否則查出來的對象全是null以前調(diào)試這個問題時浪費了不少時間。4.2 Service層行為封裝與事務(wù)控制Service層的設(shè)計原則我個人實踐下來覺得有三條最重要。第一一個Service方法只做一個完整的業(yè)務(wù)動作不要把查詢列表和下單分開又強行拼在一個事務(wù)里。第二事務(wù)邊界要清晰讀多寫少的純查詢方法不需要加事務(wù)加了反而占用連接時間影響并發(fā)性能。第三Service內(nèi)部調(diào)用同類中的其他方法時Transactional注解不生效這一點Spring代理機制決定跨類調(diào)用時切面才會介入。實際開發(fā)中我遇到過一件特別尷尬的事。當(dāng)時我把庫存扣減和訂單生成放在兩個不同Service類里在Controller里依次調(diào)用中間沒有事務(wù)串聯(lián)。結(jié)果庫存更新成功后訂單生成因為某個字段為空拋異常頁面上提示下單失敗但庫存已經(jīng)扣了。后來我把這兩個操作挪到同一個Service類的方法里用Transactional(rollbackFor Exception.class)包裹起來才算徹底解決。這是一次代價不小的教訓(xùn)。4.3 SpringMVC攔截器與權(quán)限控制的落地藥品商城有一個典型的權(quán)限控制場景普通用戶不能訪問藥師后臺藥師不能操作管理員功能所有處方藥購買流程用戶必須完成在線診斷。這種場景用SpringMVC的攔截器做成統(tǒng)一驗證是最合適的。我在spring-mvc.xml里配置了攔截器路徑規(guī)則然后單獨寫了一個AuthInterceptor實現(xiàn)HandlerInterceptor接口。攔截器里從Session中獲取當(dāng)前登錄用戶根據(jù)請求URL前綴判斷所需角色比如/api/admin/**要求管理員角色、/api/pharmacist/**要求藥師角色。校驗不通過時直接返回固定的JSON結(jié)果并中斷請求。但要注意接口鑒權(quán)時千萬不要只在攔截器里做角色判斷因為攔截器的路徑匹配規(guī)則很難覆蓋所有URL變體Service層也要保留基礎(chǔ)校驗邏輯形成縱深防御。常見問題排查與性能優(yōu)化實錄5.1 MyBatis N1查詢問題與結(jié)果集映射優(yōu)化在線診斷模塊開發(fā)到第二周時我遇到一個典型的性能問題。前端藥師工作臺需要展示每一個會話的最新一條消息預(yù)覽我最初在循環(huán)里逐個查詢會話的最后一條消息一次打開工作臺就是幾十條SQL接口響應(yīng)時間慢得讓人無法接受。排查思路很快就鎖定到了N1查詢上。解決辦法是改用一條SQL按會話分組取最新消息。查所有會話基本信息和每個會話最新消息可以用子查詢配合JOINSELECT d.*, m.content AS last_message FROM t_diagnosis d LEFT JOIN t_diagnosis_message m ON m.id ( SELECT msg.id FROM t_diagnosis_message msg WHERE msg.diagnosis_id d.id ORDER BY msg.create_time DESC LIMIT 1 ) WHERE d.status ! 4 ORDER BY d.create_time DESC這種方式在數(shù)據(jù)量不大的時候效率非常高而且避免了臨時表帶來的性能損耗。5.2 庫存超賣問題樂觀鎖方案實測藥品電商雖然不像秒殺系統(tǒng)那樣有極端并發(fā)但遇到某個爆款藥品促銷時仍然可能產(chǎn)生并發(fā)下單。如果不做任何控制超賣幾乎是必然的。我實現(xiàn)了一個非常經(jīng)典的樂觀鎖做法在扣減批次庫存的SQL上增加剩余量條件update iddeductStockByBatch UPDATE t_drug_stock_batch SET remaining_qty remaining_qty - #{qty} WHERE id #{batchId} AND remaining_qty #{qty} /update受影響行數(shù)等于0時說明該批次庫存不足或已經(jīng)有人搶先扣完直接拋出友好提示。這里我沒有選擇悲觀鎖SELECT ... FOR UPDATE因為藥品商城整體并發(fā)并不高悲觀鎖會額外持有數(shù)據(jù)庫連接鎖資源而且需要特別注意事務(wù)的提交與釋放順序用樂觀鎖在大多數(shù)場景下更輕量。[\begin{lstlisting}[languagejava] // 偽代碼片段說明樂觀鎖的調(diào)用流程 public void deductStock(Long drugId, Integer qty) { // 1. 查詢有效期最近的批次 List batches stockBatchMapper.selectNearExpiryBatches(drugId); int totalDeducted 0; for (StockBatch batch : batches) { if (totalDeducted qty) break; int need Math.min(batch.getRemainingQty(), qty - totalDeducted); int rows stockBatchMapper.deductStockByBatch(batch.getId(), need); if (rows 0) continue; totalDeducted need; } if (totalDeducted qty) { throw new BusinessException(庫存不足); } } \end{lstlisting}]5.3 在線診斷消息并發(fā)的冪等處理在線診斷的消息發(fā)送有一個容易被忽視的坑——患者連續(xù)點擊發(fā)送按鈕多次可能會因為前端沒有及時禁用按鈕而產(chǎn)生并發(fā)請求從而插入多條相同內(nèi)容的消息。這個問題我一開始是在前端用loading標(biāo)志解決但后來發(fā)現(xiàn)后端接口仍然需要做冪等控制兜底。我在消息表里加了一個client_msg_id字段由前端發(fā)送消息時生成一個唯一的UUID。后端插入消息時先檢查這個client_msg_id是否已經(jīng)存在如果存在則直接返回成功不重復(fù)插入。這樣即使網(wǎng)絡(luò)重傳或者用戶連點也不會產(chǎn)生重復(fù)消息記錄。診斷與處方是嚴(yán)肅的醫(yī)療數(shù)據(jù)數(shù)據(jù)重復(fù)造成的后果遠(yuǎn)比普通聊天室嚴(yán)重。5.4 常見問題速查表問題現(xiàn)象根本原因解決方案查詢藥品列表返回null字段MyBatis駝峰映射未開啟在mybatis-config.xml設(shè)置mapUnderscoreToCamelCasetrue事務(wù)方法中異常后數(shù)據(jù)未回滾Service方法內(nèi)部catch了異常未向外拋出統(tǒng)一由Controller處理異常Service層不吞異常庫存扣減出現(xiàn)負(fù)數(shù)扣減SQL未加剩余量條件使用樂觀鎖remaining_qty #{qty}條件處方藥訂單提交被拒處方已過期未做實時校驗訂單提交時實時檢查過期時間并自動作廢處方會話列表接口響應(yīng)慢N1查詢導(dǎo)致SQL過多使用子查詢關(guān)聯(lián)最新消息一次查出列表數(shù)據(jù)前端連點導(dǎo)致重復(fù)消息缺少冪等控制消息表增加client_msg_id唯一標(biāo)識做去重攔截器放行了不該訪問的接口路徑匹配規(guī)則不夠嚴(yán)謹(jǐn)增加更精確的URL前綴匹配Service層保留校驗5.5 在線診斷輪詢改WebSocket的實踐最初在線診斷消息的獲取方案我用的是前端每隔3秒輪詢一次接口看有沒有新消息。這種方式勝在實現(xiàn)簡單但問題也不少。首先是輪詢會產(chǎn)生大量無效請求藥師端同時打開多個會話時服務(wù)器資源被白白消耗。其次是消息到達(dá)有最長3秒的延遲體驗不夠?qū)崟r。后來我引入了WebSocket在SpringMVC配置類里注冊一個TextWebSocketHandler按用戶ID維護WebSocket會話集合。藥師接診、患者發(fā)消息、系統(tǒng)通知開方結(jié)果這些事件都通過WebSocket推送給對端接口從主動查詢變成了事件通知。改造后效果很明顯消息延遲幾乎降到零服務(wù)器的HTTP請求壓力也大幅下降。需要注意的是WebSocket連接要處理好登錄鑒權(quán)問題我在握手?jǐn)r截器中從查詢參數(shù)里提取token并校驗用戶身份防止未授權(quán)連接。部署經(jīng)驗與擴展思考6.1 傳統(tǒng)SSM項目的打包部署流程很多項目即使開發(fā)完了部署環(huán)節(jié)照樣會讓人焦頭爛額SSM項目也不例外。我的部署流程一般分四步走在pom.xml里配置maven-war-plugin用mvn clean package打出war包把war包丟進Tomcat的webapps目錄SSM傳統(tǒng)方案基本都是這個套路修改jdbc.properties中數(shù)據(jù)庫地址和賬號密碼保證連接的是生產(chǎn)庫而不是本地庫啟動Tomcat后查看catalina.out日志確認(rèn)Spring容器初始化成功這里有一個很關(guān)鍵的操作細(xì)節(jié)數(shù)據(jù)庫連接信息抽取到獨立的jdbc.properties文件中并在Spring配置里通過context:property-placeholder引入嚴(yán)禁硬編碼在Java類中。否則每次環(huán)境切換都要重新編譯代碼非常痛苦?？紤]到現(xiàn)在容器化越來越普及我也嘗試過把TomcatSSM打成Docker鏡像流程也不算復(fù)雜就是把war包拷貝到Tomcat鏡像的webapps目錄里啟動時通過環(huán)境變量注入數(shù)據(jù)庫連接參數(shù)遷移環(huán)境極其方便。6.2 從SSM向Spring Boot演進需要注意什么說實話如果讓我從零開始重新做這個藥品商城系統(tǒng)我大概率會直接用Spring Boot而非傳統(tǒng)SSM。Spring Boot的自動配置和起步依賴讓項目搭建節(jié)省大量時間內(nèi)嵌Tomcat也省去了部署的煩惱。但這并不意味著SSM這套技術(shù)棧就過時了恰恰相反我的經(jīng)驗是先理解SSM的三層架構(gòu)和核心思想再上手Spring Boot會事半功倍。MyBatis的操作方式基本不變SpringMVC的注解也完全兼容升級到Spring Boot更多是配置方式與依賴管理的轉(zhuǎn)變。如果你手頭這個SSM項目后續(xù)計劃轉(zhuǎn)型我建議從這幾個點入手web.xml中的配置逐步遷移到Spring Boot的自動配置類中spring-mvc.xml、applicationContext.xml里的Bean定義改造為Configuration加Bean分頁插件、通用Mapper等第三方集成盡量換成Spring Boot Starter版本這個演進過程并不需要重寫業(yè)務(wù)代碼重點工作量集中在配置遷移與依賴梳理上。6.3 合規(guī)審計視角下的日志與追溯設(shè)計藥品商城業(yè)務(wù)跟普通商城有一個天壤之別就是藥品銷售數(shù)據(jù)需要滿足可追溯的合規(guī)審計要求尤其是處方藥。因此我在系統(tǒng)里單獨添加了操作日志模塊重點記錄三類數(shù)據(jù)用戶的登錄日志包括登錄時間、IP地址、終端設(shè)備藥品訂單的完整狀態(tài)流轉(zhuǎn)日志從下單、支付、審核、發(fā)貨到簽收在線診斷全流程的記錄包括問診發(fā)起、消息內(nèi)容、處方開具時間這些日志不進入業(yè)務(wù)主流程而是通過Spring的AOP切面異步寫入日志表。由于藥品數(shù)據(jù)涉及用戶隱私日志內(nèi)容本身不存儲明文敏感字段必要的關(guān)聯(lián)通過用戶ID進行。如果真的遇到審計需要再通過ID到業(yè)務(wù)表里查詢詳細(xì)數(shù)據(jù)。這種設(shè)計既滿足了追溯需求又不會讓日志表成為新的數(shù)據(jù)泄露點。6.4 關(guān)于這套系統(tǒng)我最后想說的幾句話做藥品商城這類項目最考驗人的其實不是技術(shù)本身而是你能否真正理解業(yè)務(wù)背后的規(guī)則。SSM框架也好、Spring Boot也罷都只是實現(xiàn)手段真正決定項目價值的是那些看不見的細(xì)節(jié)處方藥能不能憑一張截圖就買走、庫存批次是不是先進先出、診斷記錄是否完整可追溯。我個人在實際開發(fā)中的體會是做這類系統(tǒng)時心里要始終繃著一根“合規(guī)”的弦。技術(shù)上的坑都好填比如N1查詢、事務(wù)回滾失效、庫存超賣這些東西網(wǎng)上有大把答案但業(yè)務(wù)上的疏忽比如處方校驗不到位、藥房資質(zhì)信息缺失、售后退貨不考慮藥品特殊性才是一旦上線就可能帶來真正麻煩的問題。希望這篇文章里的設(shè)計與實現(xiàn)思路能幫你把踩過的坑提前繞開。如果你也正在做類似項目歡迎在評論區(qū)聊聊你的方案互相補一補盲區(qū)。