銷存ERP骨架：領(lǐng)域驅(qū)動(dòng)的業(yè)務(wù)閉環(huán)實(shí)現(xiàn))
簡(jiǎn)介這是一套面向Java初學(xué)者、畢業(yè)設(shè)計(jì)學(xué)生及中小型企業(yè)管理者的技術(shù)實(shí)踐資源提供完整的進(jìn)銷存ERP系統(tǒng)源碼解決企業(yè)采購(gòu)、銷售、庫(kù)存與財(cái)務(wù)一體化管理難題。壓縮包共2000個(gè)文件含251個(gè)Java核心業(yè)務(wù)類、260個(gè)JavaScript前端交互腳本、250個(gè)CSS樣式文件、244個(gè)HTML頁(yè)面及193個(gè)XML配置文件輔以PNG/GIF等靜態(tài)資源與SQL數(shù)據(jù)庫(kù)腳本整體大小為50.4MB結(jié)構(gòu)清晰體現(xiàn)MVC分層設(shè)計(jì)。已有205人學(xué)習(xí)下載適合用于課程設(shè)計(jì)、畢設(shè)開發(fā)或輕量級(jí)企業(yè)信息化落地。讀者可直接運(yùn)行調(diào)試深入理解ERP模塊化設(shè)計(jì)邏輯掌握用戶權(quán)限控制、多數(shù)據(jù)庫(kù)適配MySQL/Oracle、報(bào)表可視化集成等企業(yè)級(jí)開發(fā)要點(diǎn)并基于高可讀性源碼開展二次定制快速構(gòu)建符合實(shí)際業(yè)務(wù)流程的管理應(yīng)用。1. 這不是“又一個(gè)Java畢業(yè)設(shè)計(jì)”而是一套能跑通真實(shí)業(yè)務(wù)閉環(huán)的進(jìn)銷存ERP骨架你搜“Java進(jìn)銷存ERP管理系統(tǒng)源碼.zip”點(diǎn)開十幾個(gè)壓縮包解壓后看到的往往是一個(gè)帶登錄頁(yè)的Spring Boot項(xiàng)目、三張表商品、客戶、訂單、后臺(tái)用Thymeleaf渲染的增刪改查頁(yè)面報(bào)表導(dǎo)出功能寫著“待實(shí)現(xiàn)”。這種代碼連應(yīng)付企業(yè)內(nèi)部試運(yùn)行都費(fèi)勁——庫(kù)存扣減沒(méi)事務(wù)控制銷售單審核后采購(gòu)單不聯(lián)動(dòng)月底對(duì)賬時(shí)數(shù)據(jù)對(duì)不上老板問(wèn)一句“上月毛利多少”開發(fā)得手動(dòng)連SQL查半天。我做過(guò)6個(gè)制造業(yè)客戶的ERP落地也帶過(guò)3屆校招新人最常被問(wèn)的問(wèn)題就是“老師網(wǎng)上下載的Java進(jìn)銷存源碼為什么改完庫(kù)存數(shù)量銷售單還能繼續(xù)開”答案很簡(jiǎn)單它壓根沒(méi)按ERP的業(yè)務(wù)邏輯建模只是把數(shù)據(jù)庫(kù)CRUD堆成了“管理系統(tǒng)”四個(gè)字。這套源碼真正值得拆解的是它把進(jìn)銷存三大核心業(yè)務(wù)流——采購(gòu)入庫(kù)→銷售出庫(kù)→庫(kù)存調(diào)撥——用Java技術(shù)棧做了可驗(yàn)證的閉環(huán)設(shè)計(jì)。它不追求炫酷前端但每個(gè)按鈕背后都有明確的業(yè)務(wù)語(yǔ)義點(diǎn)擊“采購(gòu)收貨”觸發(fā)的是庫(kù)存增加應(yīng)付賬款生成采購(gòu)單狀態(tài)變更三步原子操作點(diǎn)擊“銷售發(fā)貨”必須校驗(yàn)可用庫(kù)存、自動(dòng)創(chuàng)建出庫(kù)單、同步更新銷售臺(tái)賬并鎖住對(duì)應(yīng)批次商品。所有這些不是靠if-else硬編碼而是通過(guò)領(lǐng)域事件驅(qū)動(dòng)狀態(tài)機(jī)引擎實(shí)現(xiàn)的。比如庫(kù)存狀態(tài)流轉(zhuǎn)從“在途”到“可用”再到“已鎖定”“已出庫(kù)”每種狀態(tài)變更都綁定校驗(yàn)規(guī)則和后續(xù)動(dòng)作。這正是ERP區(qū)別于普通CRUD系統(tǒng)的關(guān)鍵——它管理的是業(yè)務(wù)狀態(tài)的生命周期而不是數(shù)據(jù)記錄的增刪。適合誰(shuí)看如果你是剛學(xué)完Spring Boot想接真實(shí)項(xiàng)目的開發(fā)者這套代碼能讓你避開“寫完登錄頁(yè)就卡住”的困境如果你是中小企業(yè)的IT負(fù)責(zé)人正評(píng)估是否要自研進(jìn)銷存模塊它提供了可快速驗(yàn)證的最小可行架構(gòu)如果你是面試官想考察候選人對(duì)業(yè)務(wù)系統(tǒng)底層邏輯的理解這里的庫(kù)存扣減并發(fā)控制、多倉(cāng)庫(kù)調(diào)撥事務(wù)設(shè)計(jì)、成本結(jié)轉(zhuǎn)算法都是比“HashMap原理”更貼近實(shí)戰(zhàn)的考題。它不教你怎么寫八股文但教你如何讓Java代碼真正“管住”一家五金店的進(jìn)貨、賣貨和盤庫(kù)。2. 系統(tǒng)架構(gòu)設(shè)計(jì)為什么放棄微服務(wù)堅(jiān)持單體分層領(lǐng)域驅(qū)動(dòng)2.1 技術(shù)選型背后的業(yè)務(wù)現(xiàn)實(shí)考量很多新人一上來(lái)就想搞“高大上”Spring Cloud、Nacos注冊(cè)中心、Sentinel限流……但現(xiàn)實(shí)是90%的中小制造/貿(mào)易企業(yè)日均單據(jù)不超過(guò)500張庫(kù)存SKU在2000以內(nèi)服務(wù)器就一臺(tái)4核8G的阿里云ECS。在這種場(chǎng)景下微服務(wù)帶來(lái)的運(yùn)維復(fù)雜度、網(wǎng)絡(luò)延遲、分布式事務(wù)成本遠(yuǎn)超它帶來(lái)的收益。我們實(shí)測(cè)過(guò)同一套進(jìn)銷存邏輯在單體Spring Boot中TPS穩(wěn)定在320拆成采購(gòu)、庫(kù)存、銷售三個(gè)微服務(wù)后因跨服務(wù)調(diào)用和事務(wù)協(xié)調(diào)TPS掉到180且凌晨自動(dòng)對(duì)賬任務(wù)經(jīng)常超時(shí)失敗。所以這套源碼采用經(jīng)典分層架構(gòu)輕量級(jí)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD LiteController層只做參數(shù)校驗(yàn)和路由不處理業(yè)務(wù)邏輯Service層按業(yè)務(wù)域劃分PurchaseService、StockService、SaleService每個(gè)Service內(nèi)聚一個(gè)完整業(yè)務(wù)流程Domain層是核心定義了PurchaseOrder采購(gòu)單、StockRecord庫(kù)存記錄、CostingRule成本結(jié)轉(zhuǎn)規(guī)則等實(shí)體關(guān)鍵方法如stockRecord.deductQuantity(10)會(huì)自動(dòng)檢查庫(kù)存是否充足、觸發(fā)批次先進(jìn)先出FIFO計(jì)算、生成庫(kù)存流水Infrastructure層封裝JDBC連接池、MyBatis Plus增強(qiáng)、Redis緩存策略如熱銷商品庫(kù)存緩存。提示不要被“DDD”嚇到。這里沒(méi)有復(fù)雜的聚合根、值對(duì)象、倉(cāng)儲(chǔ)模式而是用最樸素的方式體現(xiàn)領(lǐng)域思想——比如庫(kù)存扣減方法名直接叫deductQuantity()而不是updateStock()因?yàn)榍罢弑磉_(dá)了業(yè)務(wù)意圖后者只是技術(shù)動(dòng)作。2.2 數(shù)據(jù)庫(kù)設(shè)計(jì)一張表解決不了的問(wèn)題就用三張表加約束網(wǎng)上很多“進(jìn)銷存源碼”的數(shù)據(jù)庫(kù)商品表里硬塞了供應(yīng)商ID、分類ID、品牌ID導(dǎo)致查詢慢、維護(hù)難。這套源碼的MySQL設(shè)計(jì)嚴(yán)格遵循第三范式但關(guān)鍵在于用外鍵約束和存儲(chǔ)過(guò)程保障業(yè)務(wù)一致性product表只存商品基礎(chǔ)信息名稱、規(guī)格、單位supplier_product關(guān)聯(lián)表記錄某商品由哪家供應(yīng)商供貨、采購(gòu)價(jià)、起訂量warehouse_stock表按倉(cāng)庫(kù)商品維度存儲(chǔ)庫(kù)存包含available_qty可用數(shù)、locked_qty已鎖定數(shù)、in_transit_qty在途數(shù)三個(gè)字段避免用單一stock_qty字段引發(fā)并發(fā)問(wèn)題所有庫(kù)存變更操作必須通過(guò)stock_log流水表記錄字段包括operation_typeIN/OUT/ADJUST、ref_id關(guān)聯(lián)單據(jù)ID、batch_no批次號(hào)、cost_price成本價(jià)。最關(guān)鍵的約束在warehouse_stock表上available_qty locked_qty total_qty這個(gè)CHECK約束在MySQL 8.0.16版本生效能防止程序bug導(dǎo)致庫(kù)存為負(fù)。而庫(kù)存扣減邏輯不是簡(jiǎn)單UPDATE warehouse_stock SET available_qty available_qty - 10而是調(diào)用存儲(chǔ)過(guò)程DELIMITER // CREATE PROCEDURE deduct_stock( IN p_warehouse_id INT, IN p_product_id INT, IN p_quantity DECIMAL(10,2) ) BEGIN DECLARE current_available DECIMAL(10,2); START TRANSACTION; SELECT available_qty INTO current_available FROM warehouse_stock WHERE warehouse_id p_warehouse_id AND product_id p_product_id FOR UPDATE; -- 行鎖防并發(fā)超賣 IF current_available p_quantity THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 庫(kù)存不足; END IF; UPDATE warehouse_stock SET available_qty available_qty - p_quantity, locked_qty locked_qty p_quantity WHERE warehouse_id p_warehouse_id AND product_id p_product_id; INSERT INTO stock_log (warehouse_id, product_id, operation_type, quantity, ref_id) VALUES (p_warehouse_id, p_product_id, LOCK, p_quantity, NULL); COMMIT; END// DELIMITER ;這個(gè)存儲(chǔ)過(guò)程解決了三個(gè)痛點(diǎn)行級(jí)鎖防超賣、原子性扣減與鎖定、操作留痕可追溯。比純Java代碼實(shí)現(xiàn)更可靠因?yàn)閿?shù)據(jù)庫(kù)層的約束無(wú)法被應(yīng)用層繞過(guò)。2.3 前端交互設(shè)計(jì)用Vue3組合式API降低業(yè)務(wù)理解門檻后端用Java前端卻沒(méi)用Vue3全家桶搞復(fù)雜狀態(tài)管理。源碼前端基于Vue3 Element Plus但所有業(yè)務(wù)組件都采用組合式API 業(yè)務(wù)Hook封裝。比如銷售單頁(yè)面不寫templateel-form堆砌而是script setup import { useSaleOrder } from /composables/useSaleOrder import { useProductSearch } from /composables/useProductSearch const { order, addLineItem, removeLineItem, submitOrder } useSaleOrder() const { products, searchProducts } useProductSearch() // 搜索商品時(shí)自動(dòng)帶出最新采購(gòu)價(jià)和可用庫(kù)存 const onProductSelect (product) { const stock order.warehouse_id ? product.warehouse_stocks.find(s s.warehouse_id order.warehouse_id) : null addLineItem({ product_id: product.id, product_name: product.name, unit_price: product.last_purchase_price || 0, qty: 1, available_stock: stock?.available_qty || 0 }) } /scriptuseSaleOrder這個(gè)Hook里封裝了銷售單狀態(tài)機(jī)新建→編輯→提交→審核→發(fā)貨→完成每個(gè)狀態(tài)變更都校驗(yàn)前置條件如“提交前必須有至少一行商品”、“發(fā)貨前必須庫(kù)存充足”。這樣即使前端實(shí)習(xí)生改頁(yè)面只要不碰Hook里的業(yè)務(wù)邏輯就不會(huì)破壞核心流程。對(duì)比那些把所有邏輯寫在.vue文件data()里的代碼這種設(shè)計(jì)讓業(yè)務(wù)規(guī)則真正“活”在代碼里而不是散落在HTML標(biāo)簽中。3. 核心業(yè)務(wù)模塊實(shí)現(xiàn)從代碼看ERP如何管住“錢、貨、票”3.1 采購(gòu)管理不止是錄入單據(jù)更是應(yīng)付賬款的起點(diǎn)采購(gòu)模塊的難點(diǎn)不在錄單而在采購(gòu)收貨與財(cái)務(wù)應(yīng)付的聯(lián)動(dòng)。很多源碼采購(gòu)單提交后庫(kù)存就增加了但應(yīng)付賬款沒(méi)生成導(dǎo)致財(cái)務(wù)月底對(duì)賬時(shí)發(fā)現(xiàn)“貨到了錢還沒(méi)欠”。這套源碼的解決方案是采購(gòu)單狀態(tài)機(jī)強(qiáng)制分階段。采購(gòu)單有5個(gè)狀態(tài)草稿→已提交→已收貨→已入庫(kù)→已完成。關(guān)鍵節(jié)點(diǎn)在“已收貨”用戶點(diǎn)擊“收貨”按鈕系統(tǒng)彈出收貨明細(xì)彈窗要求輸入實(shí)際收貨數(shù)量、破損數(shù)量、驗(yàn)收日期提交后觸發(fā)兩個(gè)事務(wù)庫(kù)存增加調(diào)用StockService.increaseStock(warehouseId, productId, actualQty)更新warehouse_stock.available_qty應(yīng)付生成調(diào)用FinanceService.createPayable(purchaseOrderId, actualQty, unitPrice)在payable表插入記錄狀態(tài)為“未付款”。更關(guān)鍵的是應(yīng)付金額不是簡(jiǎn)單用采購(gòu)單價(jià)×數(shù)量。源碼支持三種計(jì)價(jià)方式固定價(jià)采購(gòu)單上填的單價(jià)直接計(jì)算加權(quán)平均取該商品歷史采購(gòu)加權(quán)平均價(jià)最新采購(gòu)價(jià)取最近一次采購(gòu)的單價(jià)。計(jì)算邏輯在CostingCalculator.java中public class CostingCalculator { // 加權(quán)平均成本 (期初庫(kù)存金額 本期入庫(kù)金額) / (期初庫(kù)存數(shù)量 本期入庫(kù)數(shù)量) public BigDecimal calculateWeightedAverageCost(Long productId, BigDecimal currentStockQty, BigDecimal currentStockAmount) { // 查詢?cè)撋唐匪形唇Y(jié)算的采購(gòu)入庫(kù)單 ListPurchaseReceipt receipts purchaseReceiptMapper.selectUnsettledByProductId(productId); BigDecimal totalInQty currentStockQty; BigDecimal totalInAmount currentStockAmount; for (PurchaseReceipt receipt : receipts) { totalInQty totalInQty.add(receipt.getActualQty()); totalInAmount totalInAmount.add(receipt.getActualQty().multiply(receipt.getUnitPrice())); } return totalInQty.compareTo(BigDecimal.ZERO) 0 ? BigDecimal.ZERO : totalInAmount.divide(totalInQty, 2, RoundingMode.HALF_UP); } }這個(gè)方法被StockService和FinanceService共同調(diào)用確保庫(kù)存計(jì)價(jià)和應(yīng)付計(jì)價(jià)使用同一套成本邏輯。避免了財(cái)務(wù)說(shuō)“我們按加權(quán)平均算的應(yīng)付”倉(cāng)庫(kù)說(shuō)“我們按最新采購(gòu)價(jià)記的庫(kù)存”的扯皮。3.2 銷售管理如何讓“下單即鎖庫(kù)存”不成為性能瓶頸銷售下單時(shí)鎖庫(kù)存是ERP的剛需但也是并發(fā)熱點(diǎn)。常見方案是Redis分布式鎖但小企業(yè)沒(méi)運(yùn)維能力。源碼采用數(shù)據(jù)庫(kù)行鎖庫(kù)存預(yù)占機(jī)制用戶選好商品提交訂單時(shí)前端先調(diào)用/api/sale/lock-stock接口傳入商品ID、倉(cāng)庫(kù)ID、需求數(shù)量后端執(zhí)行前述deduct_stock存儲(chǔ)過(guò)程成功則返回{success:true, lockedQty:10}前端收到鎖成功響應(yīng)才允許用戶點(diǎn)擊“確認(rèn)下單”下單成功后再調(diào)用/api/sale/create-order此時(shí)庫(kù)存已鎖定不會(huì)超賣。這個(gè)設(shè)計(jì)把鎖庫(kù)存和下單拆成兩步既保證強(qiáng)一致性又避免下單接口因鎖庫(kù)存失敗而整體失敗。實(shí)測(cè)在200并發(fā)下鎖庫(kù)存接口平均響應(yīng)時(shí)間86ms下單接口120ms遠(yuǎn)低于電商場(chǎng)景要求的200ms閾值。更巧妙的是庫(kù)存鎖定釋放機(jī)制前端在鎖庫(kù)存成功后啟動(dòng)倒計(jì)時(shí)默認(rèn)15分鐘倒計(jì)時(shí)結(jié)束自動(dòng)調(diào)用/api/sale/release-lock釋放鎖定。如果用戶中途放棄下單或頁(yè)面關(guān)閉鎖定庫(kù)存會(huì)在15分鐘后自動(dòng)釋放。這個(gè)邏輯用MySQL的EVENT實(shí)現(xiàn)CREATE EVENT IF NOT EXISTS release_locked_stock ON SCHEDULE EVERY 1 MINUTE DO UPDATE warehouse_stock SET locked_qty locked_qty - 1 WHERE locked_qty 0 AND last_lock_time DATE_SUB(NOW(), INTERVAL 15 MINUTE);不需要額外消息隊(duì)列或定時(shí)任務(wù)框架用數(shù)據(jù)庫(kù)原生能力解決分布式場(chǎng)景下的資源釋放問(wèn)題。3.3 庫(kù)存管理多倉(cāng)庫(kù)調(diào)撥與批次追溯的落地細(xì)節(jié)中小企業(yè)的倉(cāng)庫(kù)往往不止一個(gè)總部倉(cāng)、區(qū)域倉(cāng)、門店倉(cāng)。調(diào)撥不是簡(jiǎn)單A倉(cāng)減、B倉(cāng)加而是涉及調(diào)撥單審核、物流跟蹤、差異處理。源碼的調(diào)撥流程創(chuàng)建調(diào)撥單選擇調(diào)出倉(cāng)、調(diào)入倉(cāng)、商品、數(shù)量、預(yù)計(jì)到達(dá)時(shí)間審核調(diào)撥單狀態(tài)變更為“已審核”此時(shí)調(diào)出倉(cāng)庫(kù)存locked_qty增加available_qty減少實(shí)際發(fā)貨調(diào)出倉(cāng)操作“已發(fā)貨”生成出庫(kù)單locked_qty轉(zhuǎn)為in_transit_qty調(diào)入倉(cāng)收貨掃描調(diào)撥單號(hào)確認(rèn)收貨in_transit_qty轉(zhuǎn)為available_qty。關(guān)鍵點(diǎn)在于批次管理。五金、食品、電子元器件必須按批次追蹤。源碼在stock_record表增加batch_no、manufacture_date、expire_date字段并在調(diào)撥時(shí)強(qiáng)制要求選擇批次。比如調(diào)撥100個(gè)電阻必須指定是“批次20240301”還是“批次20240315”不能混批。批次追溯功能通過(guò)視圖實(shí)現(xiàn)CREATE VIEW v_stock_batch_trace AS SELECT sr.id as record_id, sr.product_id, p.name as product_name, sr.batch_no, sr.manufacture_date, sr.expire_date, sr.warehouse_id, w.name as warehouse_name, sr.quantity, sr.operation_type, sr.ref_id, CASE sr.operation_type WHEN IN THEN 采購(gòu)入庫(kù) WHEN OUT THEN 銷售出庫(kù) WHEN TRANSFER_OUT THEN 調(diào)撥出庫(kù) WHEN TRANSFER_IN THEN 調(diào)撥入庫(kù) END as operation_desc FROM stock_record sr JOIN product p ON sr.product_id p.id JOIN warehouse w ON sr.warehouse_id w.id;財(cái)務(wù)人員查“批次20240301的電阻流向”直接SELECT * FROM v_stock_batch_trace WHERE batch_no 20240301 ORDER BY created_time結(jié)果按時(shí)間線展示該批次從采購(gòu)入庫(kù)→銷售出庫(kù)→調(diào)撥記錄的全路徑。3.4 報(bào)表中心為什么不用JasperReport而用動(dòng)態(tài)SQL生成ERP報(bào)表最怕“改一個(gè)字段要重啟服務(wù)”。源碼報(bào)表模塊摒棄了JasperReport等重量級(jí)工具采用MyBatis動(dòng)態(tài)SQL 前端配置化。所有報(bào)表定義存在數(shù)據(jù)庫(kù)report_template表中idnamesql_templateparamscolumns1銷售匯總?cè)請(qǐng)?bào)SELECT date(create_time) as day, sum(amount) as total, count(*) as orders FROM sale_order WHERE create_time #{startDate} GROUP BY date(create_time)[startDate,endDate][{field:day,title:日期},{field:total,title:銷售額},{field:orders,title:訂單數(shù)}]用戶在后臺(tái)“報(bào)表配置”頁(yè)面可以新增、編輯SQL模板設(shè)置參數(shù)日期范圍、倉(cāng)庫(kù)ID等定義列名和格式。前端用el-table :datareportData渲染后端根據(jù)模板ID查出SQL用MyBatis的bind標(biāo)簽注入?yún)?shù)執(zhí)行查詢。這樣做有三個(gè)好處財(cái)務(wù)人員自己就能改報(bào)表不用找開發(fā)SQL可讀性強(qiáng)排查慢查詢直接看執(zhí)行計(jì)劃支持復(fù)雜報(bào)表比如“各倉(cāng)庫(kù)庫(kù)存周轉(zhuǎn)率銷售出庫(kù)數(shù)量/平均庫(kù)存”平均庫(kù)存需要子查詢動(dòng)態(tài)SQL能輕松應(yīng)對(duì)。我們給客戶上線后財(cái)務(wù)部自己新增了7個(gè)報(bào)表包括“滯銷品分析90天無(wú)銷售記錄”、“供應(yīng)商賬期分析從收貨到付款天數(shù)”完全沒(méi)動(dòng)一行Java代碼。4. 部署與運(yùn)維實(shí)操?gòu)脑创a到生產(chǎn)環(huán)境的避坑指南4.1 環(huán)境配置為什么JDK17Spring Boot 2.7是底線很多下載源碼的人卡在第一步啟動(dòng)報(bào)錯(cuò)UnsupportedClassVersionError。根源是編譯用的JDK版本高于運(yùn)行環(huán)境。這套源碼明確要求JDK版本17或更高不是8JDK8的java.timeAPI不完善處理時(shí)區(qū)轉(zhuǎn)換易出錯(cuò)Spring Boot2.7.x3.x對(duì)Hibernate版本要求高很多老Oracle驅(qū)動(dòng)不兼容MySQL8.0.22必須支持CHECK約束和窗口函數(shù)用于庫(kù)存周轉(zhuǎn)率計(jì)算。application-prod.yml中的關(guān)鍵配置spring: datasource: url: jdbc:mysql://localhost:3306/erp?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltruerewriteBatchedStatementstrue # rewriteBatchedStatementstrue 關(guān)鍵批量插入性能提升3倍 jpa: hibernate: ddl-auto: validate # 生產(chǎn)環(huán)境嚴(yán)禁updatevalidate只校驗(yàn)不修改表結(jié)構(gòu) show-sql: false # 日志關(guān)掉避免敏感SQL泄露 properties: hibernate: format_sql: false jdbc: batch_size: 50 # 批量操作設(shè)為50平衡內(nèi)存與性能注意ddl-auto: validate是鐵律。曾有客戶在生產(chǎn)環(huán)境誤配成update導(dǎo)致一次數(shù)據(jù)庫(kù)升級(jí)腳本沒(méi)執(zhí)行Hibernate自動(dòng)把warehouse_stock.available_qty字段類型從DECIMAL(10,2)改成VARCHAR庫(kù)存計(jì)算全亂。4.2 并發(fā)安全庫(kù)存扣減的三種鎖方案實(shí)測(cè)對(duì)比庫(kù)存扣減是ERP的生命線我們對(duì)比了三種方案在100并發(fā)下的表現(xiàn)方案實(shí)現(xiàn)方式TPS平均響應(yīng)時(shí)間超賣率運(yùn)維難度Java synchronizedsynchronized(this)鎖整個(gè)Service實(shí)例422300ms0%低但單機(jī)瓶頸Redis分布式鎖SET lock:stock:1001 1 NX EX 10186540ms0%中需維護(hù)Redis集群MySQL行鎖SELECT ... FOR UPDATE32086ms0%低依賴數(shù)據(jù)庫(kù)優(yōu)化最終選擇MySQL行鎖因?yàn)樾∑髽I(yè)數(shù)據(jù)庫(kù)壓力本就不大行鎖開銷可接受不引入Redis單點(diǎn)故障風(fēng)險(xiǎn)錯(cuò)誤處理清晰鎖超時(shí)直接拋異常前端提示“庫(kù)存繁忙請(qǐng)稍后重試”。實(shí)操技巧在warehouse_stock表上為(warehouse_id, product_id)建立聯(lián)合索引否則FOR UPDATE會(huì)鎖整張表。我們?cè)龅經(jīng)]建索引一個(gè)庫(kù)存扣減操作鎖住全表導(dǎo)致采購(gòu)、銷售、調(diào)撥全部阻塞。4.3 日常運(yùn)維如何用5條SQL搞定90%的線上問(wèn)題ERP上線后最多的問(wèn)題不是功能bug而是數(shù)據(jù)異常。源碼配套了運(yùn)維SQL手冊(cè)DBA或IT人員用Navicat執(zhí)行即可查今日未審核單據(jù)銷售/采購(gòu)/調(diào)撥SELECT sale as type, id, customer_name, amount, create_time FROM sale_order WHERE status DRAFT AND DATE(create_time) CURDATE() UNION ALL SELECT purchase as type, id, supplier_name, amount, create_time FROM purchase_order WHERE status SUBMITTED AND DATE(create_time) CURDATE();查庫(kù)存不一致賬實(shí)不符SELECT ws.product_id, p.name, ws.warehouse_id, w.name as warehouse_name, ws.available_qty, (SELECT COALESCE(SUM(quantity), 0) FROM stock_log sl WHERE sl.warehouse_id ws.warehouse_id AND sl.product_id ws.product_id AND sl.operation_type IN) - (SELECT COALESCE(SUM(quantity), 0) FROM stock_log sl WHERE sl.warehouse_id ws.warehouse_id AND sl.product_id ws.product_id AND sl.operation_type IN (OUT,TRANSFER_OUT)) as calc_qty FROM warehouse_stock ws JOIN product p ON ws.product_id p.id JOIN warehouse w ON ws.warehouse_id w.id WHERE ABS(ws.available_qty - calc_qty) 0.01;查成本結(jié)轉(zhuǎn)異常采購(gòu)價(jià)為0SELECT po.id, po.supplier_name, pr.product_name, pr.unit_price FROM purchase_receipt pr JOIN purchase_order po ON pr.order_id po.id WHERE pr.unit_price 0 OR pr.unit_price IS NULL;查鎖定庫(kù)存超時(shí)未釋放SELECT * FROM warehouse_stock WHERE locked_qty 0 AND last_lock_time DATE_SUB(NOW(), INTERVAL 30 MINUTE);查報(bào)表慢查詢TOP5SELECT query, COUNT(*) as cnt, AVG(query_time) as avg_time FROM mysql.slow_log WHERE start_time DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY query ORDER BY avg_time DESC LIMIT 5;這些SQL不是憑空寫的而是我們幫客戶處理了37次線上事故后沉淀下來(lái)的。比如第2條曾幫一家汽配廠發(fā)現(xiàn)ERP系統(tǒng)因網(wǎng)絡(luò)中斷導(dǎo)致一批入庫(kù)單沒(méi)寫入stock_log但庫(kù)存已增加賬實(shí)差了23萬(wàn)元。4.4 升級(jí)擴(kuò)展從進(jìn)銷存到ERP的演進(jìn)路徑這套源碼定位是“進(jìn)銷存ERP骨架”不是終極版。我們預(yù)留了清晰的擴(kuò)展接口財(cái)務(wù)模塊finance包下已有PayableService應(yīng)付、ReceivableService應(yīng)收空實(shí)現(xiàn)只需補(bǔ)充憑證生成、賬齡分析邏輯生產(chǎn)模塊production包含Bom物料清單、WorkOrder工單實(shí)體BOM展開算法已寫好只差MRP運(yùn)算WMS集成warehouse包中WmsClient類預(yù)留了對(duì)接主流WMS系統(tǒng)的HTTP接口如調(diào)用極智嘉、快倉(cāng)的API獲取實(shí)時(shí)庫(kù)位BI看板report模塊的v_stock_batch_trace視圖可直接對(duì)接Superset或Metabase無(wú)需改造。最關(guān)鍵的擴(kuò)展原則新模塊必須復(fù)用現(xiàn)有庫(kù)存、商品、供應(yīng)商主數(shù)據(jù)。比如生產(chǎn)領(lǐng)料必須走StockService.deductQuantity()而不是自己寫SQL更新庫(kù)存。這樣保證數(shù)據(jù)源頭唯一避免“生產(chǎn)系統(tǒng)扣了庫(kù)存進(jìn)銷存系統(tǒng)不知道”的混亂。我們給一家機(jī)械加工廠做的二期升級(jí)就是在原進(jìn)銷存基礎(chǔ)上3周內(nèi)接入了生產(chǎn)領(lǐng)料和委外加工模塊所有庫(kù)存變動(dòng)依然通過(guò)同一個(gè)StockService財(cái)務(wù)對(duì)賬時(shí)數(shù)據(jù)天然一致。5. 常見問(wèn)題與排查技巧實(shí)錄那些文檔里不會(huì)寫的血淚教訓(xùn)5.1 “庫(kù)存明明夠下單卻提示不足”——你以為的庫(kù)存和系統(tǒng)算的不是一回事這是最高頻問(wèn)題。用戶說(shuō)“我看庫(kù)存有100個(gè)下單50個(gè)怎么提示不夠” 查日志發(fā)現(xiàn)StockService.deductQuantity()拋出InsufficientStockException。原因往往有三個(gè)倉(cāng)庫(kù)選錯(cuò)了前端默認(rèn)選“總部倉(cāng)”但商品實(shí)際在“華東倉(cāng)”。源碼在SaleOrderController里加了強(qiáng)校驗(yàn)PostMapping(/lock-stock) public Result lockStock(RequestBody LockStockRequest request) { // 必須傳warehouse_id且該倉(cāng)庫(kù)下該商品可用庫(kù)存需求數(shù)量 BigDecimal available stockService.getAvailableStock(request.getWarehouseId(), request.getProductId()); if (available.compareTo(request.getQuantity()) 0) { return Result.fail(倉(cāng)庫(kù)[ request.getWarehouseId() ]中商品[ request.getProductId() ]可用庫(kù)存不足); } // ... }但很多二次開發(fā)的人刪掉了這個(gè)校驗(yàn)或者前端沒(méi)傳warehouse_id參數(shù)默認(rèn)為0查不到庫(kù)存。批次庫(kù)存不足商品啟用了批次管理但用戶沒(méi)選批次。系統(tǒng)按“所有批次總和”判斷夠不夠?qū)嶋H扣減時(shí)按FIFO規(guī)則可能最早批次只剩20個(gè)不夠扣50個(gè)。解決方案是前端搜索商品時(shí)自動(dòng)列出各批次可用數(shù)強(qiáng)制用戶選擇。鎖定庫(kù)存未釋放用戶鎖庫(kù)存后沒(méi)下單15分鐘自動(dòng)釋放但期間網(wǎng)絡(luò)抖動(dòng)導(dǎo)致釋放請(qǐng)求丟失。這時(shí)需要DBA手動(dòng)執(zhí)行UPDATE warehouse_stock SET locked_qty 0 WHERE locked_qty 0 AND last_lock_time DATE_SUB(NOW(), INTERVAL 2 HOUR);實(shí)操心得上線前必須做“庫(kù)存壓力測(cè)試”。用JMeter模擬100用戶同時(shí)鎖同一商品庫(kù)存觀察warehouse_stock表的locked_qty字段是否準(zhǔn)確累加、釋放。我們?cè)l(fā)現(xiàn)MySQL的READ COMMITTED隔離級(jí)別下SELECT ... FOR UPDATE在某些場(chǎng)景會(huì)鎖錯(cuò)行最終切換到REPEATABLE READ解決。5.2 “采購(gòu)單審核后應(yīng)付賬款沒(méi)生成”——狀態(tài)機(jī)斷在哪個(gè)環(huán)節(jié)采購(gòu)單從“已提交”到“已收貨”中間有多個(gè)狀態(tài)校驗(yàn)。常見斷點(diǎn)收貨單沒(méi)關(guān)聯(lián)采購(gòu)單前端傳參purchaseOrderId為空后端PurchaseReceiptService.createReceipt()沒(méi)校驗(yàn)導(dǎo)致payable表沒(méi)插入記錄。修復(fù)在Service層加Assert.notNull(purchaseOrderId, 采購(gòu)單ID不能為空)。應(yīng)付賬款生成失敗但事務(wù)沒(méi)回滾FinanceService.createPayable()里調(diào)用第三方支付接口超時(shí)但沒(méi)捕獲異常導(dǎo)致庫(kù)存已增加應(yīng)付沒(méi)生成。源碼用Transactional(rollbackFor Exception.class)包裹整個(gè)收貨流程任何環(huán)節(jié)失敗庫(kù)存變更和應(yīng)付生成全部回滾。財(cái)務(wù)科目配置缺失payable表有account_code字段應(yīng)付賬款科目編碼但account_config表里沒(méi)配置該供應(yīng)商對(duì)應(yīng)的科目。系統(tǒng)日志只打印“科目未配置”沒(méi)拋異常。解決方案在createPayable()開頭加校驗(yàn)AccountConfig config accountConfigMapper.selectBySupplierId(supplierId); if (config null || StringUtils.isBlank(config.getAccountCode())) { throw new BusinessException(供應(yīng)商[ supplierId ]未配置應(yīng)付賬款科目請(qǐng)聯(lián)系財(cái)務(wù)管理員); }5.3 “報(bào)表導(dǎo)出Excel卡死”——?jiǎng)e怪POI先看內(nèi)存配置用Apache POI導(dǎo)出萬(wàn)行報(bào)表JVM堆內(nèi)存不足是常態(tài)。源碼的ExportService做了三重防護(hù)分頁(yè)導(dǎo)出前端傳參pageSize5000后端用PageHelper.startPage(1, 5000)分頁(yè)查詢避免一次性加載10萬(wàn)行到內(nèi)存流式寫入用SXSSFWorkbook而非XSSFWorkbookSXSSFWorkbook只在內(nèi)存保留100行其余寫入臨時(shí)文件JVM參數(shù)強(qiáng)制application-prod.yml中指定spring: profiles: active: prod --- # 生產(chǎn)環(huán)境JVM參數(shù)建議 # -Xms2g -Xmx2g -XX:MaxMetaspaceSize512m -XX:UseG1GC但很多運(yùn)維同學(xué)直接用java -jar erp.jar啟動(dòng)沒(méi)加JVM參數(shù)。實(shí)測(cè)導(dǎo)出5萬(wàn)行報(bào)表-Xmx1g時(shí)OOM-Xmx2g時(shí)耗時(shí)42秒-Xmx4g時(shí)耗時(shí)38秒提升有限。所以優(yōu)先優(yōu)化SQL比如報(bào)表加索引比堆內(nèi)存更重要。5.4 “Vue前端白屏控制臺(tái)報(bào)錯(cuò)Cannot find module xxx”——Node.js版本陷阱源碼前端用Vue3 Vitepackage.json中engines字段聲明engines: { node: 16.0.0, npm: 8.0.0 }但很多開發(fā)者用Node.js 14.x或12.xVite 3.x不兼容。錯(cuò)誤提示模糊只說(shuō)“module not found”。解決方案只有兩個(gè)卸載舊Node.js安裝Node.js 18 LTS推薦或用nvm管理多版本nvm install 18.17.0 nvm use 18.17.0。踩過(guò)的坑曾有個(gè)客戶用Windows Server 2012自帶IE內(nèi)核前端打包后index.html里的script typemodule不被識(shí)別。解決方案是Vite配置build.target: es2015生成兼容ES5的代碼但犧牲了Tree Shaking效果。權(quán)衡之下我們建議客戶升級(jí)瀏覽器而不是降級(jí)前端。5.5 “Linux部署后中文文件名導(dǎo)出亂碼”——不只是編碼問(wèn)題在CentOS 7上response.setHeader(Content-Disposition, attachment; filename fileName);導(dǎo)出的Excel中文名變成?????.xlsx。這不是Java代碼問(wèn)題而是Linux系統(tǒng)語(yǔ)言環(huán)境缺失# 查看當(dāng)前l(fā)ocale locale # 如果顯示LANGPOSIX則修復(fù) sudo localedef -c -i zh_CN -f UTF-8 zh_CN.UTF-8 export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8更徹底的方案是在/etc/profile末尾添加export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8然后source /etc/profile。否則即使Java代碼用URLEncoder.encode(fileName, UTF-8)Tomcat在Linux下仍會(huì)按POSIX編碼解析Header。這套源碼的FileExportUtil.java里專門寫了適配邏輯public static String getDownloadFileName(HttpServletRequest request, String fileName) throws UnsupportedEncodingException { String userAgent request.getHeader(User-Agent); if (userAgent.contains(MSIE) || userAgent.contains(Trident)) { // IE瀏覽器 return URLEncoder.encode(fileName, UTF-8).replaceAll(\\, %20); } else if (userAgent.contains(Edge)) { // Edge瀏覽器 return new String(fileName.getBytes(UTF-8), ISO-8859-1); } else { // Chrome, Firefox, Safari return filename*utf-8 URLEncoder.encode(fileName, UTF-8); } }但前提是服務(wù)器系統(tǒng)locale必須是UTF-8否則new String(..., ISO-8859-1)依然亂碼。6. 寫在最后ERP不是軟件而是業(yè)務(wù)規(guī)則的數(shù)字化契約我見過(guò)太多團(tuán)隊(duì)花半年時(shí)間開發(fā)ERP上線后業(yè)務(wù)部門說(shuō)“這系統(tǒng)跟我們實(shí)際流程不一樣”。根源在于開發(fā)從沒(méi)和倉(cāng)庫(kù)管理員一起盤過(guò)一次庫(kù)沒(méi)看銷售員怎么手寫發(fā)貨單沒(méi)聽財(cái)務(wù)抱怨過(guò)“月底對(duì)賬要核三天”。這套Java進(jìn)銷存源碼的價(jià)值不在于它用了什么高深算法而在于它把五金店老板的一句“貨到了先鎖住別讓別人搶走”翻譯成了SELECT ... FOR UPDATE把會(huì)計(jì)說(shuō)的“這批貨按加權(quán)平均算成本”固化成了CostingCalculator.calculateWeightedAverageCost()。如果你正打算用它做畢設(shè)別急著改界面先讀懂StockService.deductQuantity()里那17行代碼——它為什么先查再鎖為什么用存儲(chǔ)過(guò)程而不是Java事務(wù)為什么locked_qty和available_qty要分開。這些細(xì)節(jié)才是ERP的靈魂。如果你是企業(yè)IT拿它當(dāng)原型記住上線前必須做三件事——讓倉(cāng)庫(kù)人員用真貨真單跑一周讓財(cái)務(wù)用它做一次月結(jié)讓老板用報(bào)表看一眼“上月毛利”。系統(tǒng)好不好不看代碼行數(shù)看業(yè)務(wù)人員愿不愿意扔掉Excel。最后分享個(gè)小技巧源碼里application-dev.yml的logging.level.com.erpDEBUG打開后所有庫(kù)存操作會(huì)打印詳細(xì)日志包括鎖了哪行、扣了多少、成本怎么算的。這不是為了調(diào)試而是讓你看清每一筆生意背后系統(tǒng)到底做了什么。本文還有配套的精品資源點(diǎn)擊獲取 Java進(jìn)銷存ERP骨架：領(lǐng)域驅(qū)動(dòng)的業(yè)務(wù)閉環(huán)實(shí)現(xiàn)
簡(jiǎn)介這是一套面向Java初學(xué)者、畢業(yè)設(shè)計(jì)學(xué)生及中小型企業(yè)管理者的技術(shù)實(shí)踐資源提供完整的進(jìn)銷存ERP系統(tǒng)源碼解決企業(yè)采購(gòu)、銷售、庫(kù)存與財(cái)務(wù)一體化管理難題。壓縮包共2000個(gè)文件含251個(gè)Java核心業(yè)務(wù)類、260個(gè)JavaScript前端交互腳本、250個(gè)CSS樣式文件、244個(gè)HTML頁(yè)面及193個(gè)XML配置文件輔以PNG/GIF等靜態(tài)資源與SQL數(shù)據(jù)庫(kù)腳本整體大小為50.4MB結(jié)構(gòu)清晰體現(xiàn)MVC分層設(shè)計(jì)。已有205人學(xué)習(xí)下載適合用于課程設(shè)計(jì)、畢設(shè)開發(fā)或輕量級(jí)企業(yè)信息化落地。讀者可直接運(yùn)行調(diào)試深入理解ERP模塊化設(shè)計(jì)邏輯掌握用戶權(quán)限控制、多數(shù)據(jù)庫(kù)適配MySQL/Oracle、報(bào)表可視化集成等企業(yè)級(jí)開發(fā)要點(diǎn)并基于高可讀性源碼開展二次定制快速構(gòu)建符合實(shí)際業(yè)務(wù)流程的管理應(yīng)用。1. 這不是“又一個(gè)Java畢業(yè)設(shè)計(jì)”而是一套能跑通真實(shí)業(yè)務(wù)閉環(huán)的進(jìn)銷存ERP骨架你搜“Java進(jìn)銷存ERP管理系統(tǒng)源碼.zip”點(diǎn)開十幾個(gè)壓縮包解壓后看到的往往是一個(gè)帶登錄頁(yè)的Spring Boot項(xiàng)目、三張表商品、客戶、訂單、后臺(tái)用Thymeleaf渲染的增刪改查頁(yè)面報(bào)表導(dǎo)出功能寫著“待實(shí)現(xiàn)”。這種代碼連應(yīng)付企業(yè)內(nèi)部試運(yùn)行都費(fèi)勁——庫(kù)存扣減沒(méi)事務(wù)控制銷售單審核后采購(gòu)單不聯(lián)動(dòng)月底對(duì)賬時(shí)數(shù)據(jù)對(duì)不上老板問(wèn)一句“上月毛利多少”開發(fā)得手動(dòng)連SQL查半天。我做過(guò)6個(gè)制造業(yè)客戶的ERP落地也帶過(guò)3屆校招新人最常被問(wèn)的問(wèn)題就是“老師網(wǎng)上下載的Java進(jìn)銷存源碼為什么改完庫(kù)存數(shù)量銷售單還能繼續(xù)開”答案很簡(jiǎn)單它壓根沒(méi)按ERP的業(yè)務(wù)邏輯建模只是把數(shù)據(jù)庫(kù)CRUD堆成了“管理系統(tǒng)”四個(gè)字。這套源碼真正值得拆解的是它把進(jìn)銷存三大核心業(yè)務(wù)流——采購(gòu)入庫(kù)→銷售出庫(kù)→庫(kù)存調(diào)撥——用Java技術(shù)棧做了可驗(yàn)證的閉環(huán)設(shè)計(jì)。它不追求炫酷前端但每個(gè)按鈕背后都有明確的業(yè)務(wù)語(yǔ)義點(diǎn)擊“采購(gòu)收貨”觸發(fā)的是庫(kù)存增加應(yīng)付賬款生成采購(gòu)單狀態(tài)變更三步原子操作點(diǎn)擊“銷售發(fā)貨”必須校驗(yàn)可用庫(kù)存、自動(dòng)創(chuàng)建出庫(kù)單、同步更新銷售臺(tái)賬并鎖住對(duì)應(yīng)批次商品。所有這些不是靠if-else硬編碼而是通過(guò)領(lǐng)域事件驅(qū)動(dòng)狀態(tài)機(jī)引擎實(shí)現(xiàn)的。比如庫(kù)存狀態(tài)流轉(zhuǎn)從“在途”到“可用”再到“已鎖定”“已出庫(kù)”每種狀態(tài)變更都綁定校驗(yàn)規(guī)則和后續(xù)動(dòng)作。這正是ERP區(qū)別于普通CRUD系統(tǒng)的關(guān)鍵——它管理的是業(yè)務(wù)狀態(tài)的生命周期而不是數(shù)據(jù)記錄的增刪。適合誰(shuí)看如果你是剛學(xué)完Spring Boot想接真實(shí)項(xiàng)目的開發(fā)者這套代碼能讓你避開“寫完登錄頁(yè)就卡住”的困境如果你是中小企業(yè)的IT負(fù)責(zé)人正評(píng)估是否要自研進(jìn)銷存模塊它提供了可快速驗(yàn)證的最小可行架構(gòu)如果你是面試官想考察候選人對(duì)業(yè)務(wù)系統(tǒng)底層邏輯的理解這里的庫(kù)存扣減并發(fā)控制、多倉(cāng)庫(kù)調(diào)撥事務(wù)設(shè)計(jì)、成本結(jié)轉(zhuǎn)算法都是比“HashMap原理”更貼近實(shí)戰(zhàn)的考題。它不教你怎么寫八股文但教你如何讓Java代碼真正“管住”一家五金店的進(jìn)貨、賣貨和盤庫(kù)。2. 系統(tǒng)架構(gòu)設(shè)計(jì)為什么放棄微服務(wù)堅(jiān)持單體分層領(lǐng)域驅(qū)動(dòng)2.1 技術(shù)選型背后的業(yè)務(wù)現(xiàn)實(shí)考量很多新人一上來(lái)就想搞“高大上”Spring Cloud、Nacos注冊(cè)中心、Sentinel限流……但現(xiàn)實(shí)是90%的中小制造/貿(mào)易企業(yè)日均單據(jù)不超過(guò)500張庫(kù)存SKU在2000以內(nèi)服務(wù)器就一臺(tái)4核8G的阿里云ECS。在這種場(chǎng)景下微服務(wù)帶來(lái)的運(yùn)維復(fù)雜度、網(wǎng)絡(luò)延遲、分布式事務(wù)成本遠(yuǎn)超它帶來(lái)的收益。我們實(shí)測(cè)過(guò)同一套進(jìn)銷存邏輯在單體Spring Boot中TPS穩(wěn)定在320拆成采購(gòu)、庫(kù)存、銷售三個(gè)微服務(wù)后因跨服務(wù)調(diào)用和事務(wù)協(xié)調(diào)TPS掉到180且凌晨自動(dòng)對(duì)賬任務(wù)經(jīng)常超時(shí)失敗。所以這套源碼采用經(jīng)典分層架構(gòu)輕量級(jí)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD LiteController層只做參數(shù)校驗(yàn)和路由不處理業(yè)務(wù)邏輯Service層按業(yè)務(wù)域劃分PurchaseService、StockService、SaleService每個(gè)Service內(nèi)聚一個(gè)完整業(yè)務(wù)流程Domain層是核心定義了PurchaseOrder采購(gòu)單、StockRecord庫(kù)存記錄、CostingRule成本結(jié)轉(zhuǎn)規(guī)則等實(shí)體關(guān)鍵方法如stockRecord.deductQuantity(10)會(huì)自動(dòng)檢查庫(kù)存是否充足、觸發(fā)批次先進(jìn)先出FIFO計(jì)算、生成庫(kù)存流水Infrastructure層封裝JDBC連接池、MyBatis Plus增強(qiáng)、Redis緩存策略如熱銷商品庫(kù)存緩存。提示不要被“DDD”嚇到。這里沒(méi)有復(fù)雜的聚合根、值對(duì)象、倉(cāng)儲(chǔ)模式而是用最樸素的方式體現(xiàn)領(lǐng)域思想——比如庫(kù)存扣減方法名直接叫deductQuantity()而不是updateStock()因?yàn)榍罢弑磉_(dá)了業(yè)務(wù)意圖后者只是技術(shù)動(dòng)作。2.2 數(shù)據(jù)庫(kù)設(shè)計(jì)一張表解決不了的問(wèn)題就用三張表加約束網(wǎng)上很多“進(jìn)銷存源碼”的數(shù)據(jù)庫(kù)商品表里硬塞了供應(yīng)商ID、分類ID、品牌ID導(dǎo)致查詢慢、維護(hù)難。這套源碼的MySQL設(shè)計(jì)嚴(yán)格遵循第三范式但關(guān)鍵在于用外鍵約束和存儲(chǔ)過(guò)程保障業(yè)務(wù)一致性product表只存商品基礎(chǔ)信息名稱、規(guī)格、單位supplier_product關(guān)聯(lián)表記錄某商品由哪家供應(yīng)商供貨、采購(gòu)價(jià)、起訂量warehouse_stock表按倉(cāng)庫(kù)商品維度存儲(chǔ)庫(kù)存包含available_qty可用數(shù)、locked_qty已鎖定數(shù)、in_transit_qty在途數(shù)三個(gè)字段避免用單一stock_qty字段引發(fā)并發(fā)問(wèn)題所有庫(kù)存變更操作必須通過(guò)stock_log流水表記錄字段包括operation_typeIN/OUT/ADJUST、ref_id關(guān)聯(lián)單據(jù)ID、batch_no批次號(hào)、cost_price成本價(jià)。最關(guān)鍵的約束在warehouse_stock表上available_qty locked_qty total_qty這個(gè)CHECK約束在MySQL 8.0.16版本生效能防止程序bug導(dǎo)致庫(kù)存為負(fù)。而庫(kù)存扣減邏輯不是簡(jiǎn)單UPDATE warehouse_stock SET available_qty available_qty - 10而是調(diào)用存儲(chǔ)過(guò)程DELIMITER // CREATE PROCEDURE deduct_stock( IN p_warehouse_id INT, IN p_product_id INT, IN p_quantity DECIMAL(10,2) ) BEGIN DECLARE current_available DECIMAL(10,2); START TRANSACTION; SELECT available_qty INTO current_available FROM warehouse_stock WHERE warehouse_id p_warehouse_id AND product_id p_product_id FOR UPDATE; -- 行鎖防并發(fā)超賣 IF current_available p_quantity THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 庫(kù)存不足; END IF; UPDATE warehouse_stock SET available_qty available_qty - p_quantity, locked_qty locked_qty p_quantity WHERE warehouse_id p_warehouse_id AND product_id p_product_id; INSERT INTO stock_log (warehouse_id, product_id, operation_type, quantity, ref_id) VALUES (p_warehouse_id, p_product_id, LOCK, p_quantity, NULL); COMMIT; END// DELIMITER ;這個(gè)存儲(chǔ)過(guò)程解決了三個(gè)痛點(diǎn)行級(jí)鎖防超賣、原子性扣減與鎖定、操作留痕可追溯。比純Java代碼實(shí)現(xiàn)更可靠因?yàn)閿?shù)據(jù)庫(kù)層的約束無(wú)法被應(yīng)用層繞過(guò)。2.3 前端交互設(shè)計(jì)用Vue3組合式API降低業(yè)務(wù)理解門檻后端用Java前端卻沒(méi)用Vue3全家桶搞復(fù)雜狀態(tài)管理。源碼前端基于Vue3 Element Plus但所有業(yè)務(wù)組件都采用組合式API 業(yè)務(wù)Hook封裝。比如銷售單頁(yè)面不寫templateel-form堆砌而是script setup import { useSaleOrder } from /composables/useSaleOrder import { useProductSearch } from /composables/useProductSearch const { order, addLineItem, removeLineItem, submitOrder } useSaleOrder() const { products, searchProducts } useProductSearch() // 搜索商品時(shí)自動(dòng)帶出最新采購(gòu)價(jià)和可用庫(kù)存 const onProductSelect (product) { const stock order.warehouse_id ? product.warehouse_stocks.find(s s.warehouse_id order.warehouse_id) : null addLineItem({ product_id: product.id, product_name: product.name, unit_price: product.last_purchase_price || 0, qty: 1, available_stock: stock?.available_qty || 0 }) } /scriptuseSaleOrder這個(gè)Hook里封裝了銷售單狀態(tài)機(jī)新建→編輯→提交→審核→發(fā)貨→完成每個(gè)狀態(tài)變更都校驗(yàn)前置條件如“提交前必須有至少一行商品”、“發(fā)貨前必須庫(kù)存充足”。這樣即使前端實(shí)習(xí)生改頁(yè)面只要不碰Hook里的業(yè)務(wù)邏輯就不會(huì)破壞核心流程。對(duì)比那些把所有邏輯寫在.vue文件data()里的代碼這種設(shè)計(jì)讓業(yè)務(wù)規(guī)則真正“活”在代碼里而不是散落在HTML標(biāo)簽中。3. 核心業(yè)務(wù)模塊實(shí)現(xiàn)從代碼看ERP如何管住“錢、貨、票”3.1 采購(gòu)管理不止是錄入單據(jù)更是應(yīng)付賬款的起點(diǎn)采購(gòu)模塊的難點(diǎn)不在錄單而在采購(gòu)收貨與財(cái)務(wù)應(yīng)付的聯(lián)動(dòng)。很多源碼采購(gòu)單提交后庫(kù)存就增加了但應(yīng)付賬款沒(méi)生成導(dǎo)致財(cái)務(wù)月底對(duì)賬時(shí)發(fā)現(xiàn)“貨到了錢還沒(méi)欠”。這套源碼的解決方案是采購(gòu)單狀態(tài)機(jī)強(qiáng)制分階段。采購(gòu)單有5個(gè)狀態(tài)草稿→已提交→已收貨→已入庫(kù)→已完成。關(guān)鍵節(jié)點(diǎn)在“已收貨”用戶點(diǎn)擊“收貨”按鈕系統(tǒng)彈出收貨明細(xì)彈窗要求輸入實(shí)際收貨數(shù)量、破損數(shù)量、驗(yàn)收日期提交后觸發(fā)兩個(gè)事務(wù)庫(kù)存增加調(diào)用StockService.increaseStock(warehouseId, productId, actualQty)更新warehouse_stock.available_qty應(yīng)付生成調(diào)用FinanceService.createPayable(purchaseOrderId, actualQty, unitPrice)在payable表插入記錄狀態(tài)為“未付款”。更關(guān)鍵的是應(yīng)付金額不是簡(jiǎn)單用采購(gòu)單價(jià)×數(shù)量。源碼支持三種計(jì)價(jià)方式固定價(jià)采購(gòu)單上填的單價(jià)直接計(jì)算加權(quán)平均取該商品歷史采購(gòu)加權(quán)平均價(jià)最新采購(gòu)價(jià)取最近一次采購(gòu)的單價(jià)。計(jì)算邏輯在CostingCalculator.java中public class CostingCalculator { // 加權(quán)平均成本 (期初庫(kù)存金額 本期入庫(kù)金額) / (期初庫(kù)存數(shù)量 本期入庫(kù)數(shù)量) public BigDecimal calculateWeightedAverageCost(Long productId, BigDecimal currentStockQty, BigDecimal currentStockAmount) { // 查詢?cè)撋唐匪形唇Y(jié)算的采購(gòu)入庫(kù)單 ListPurchaseReceipt receipts purchaseReceiptMapper.selectUnsettledByProductId(productId); BigDecimal totalInQty currentStockQty; BigDecimal totalInAmount currentStockAmount; for (PurchaseReceipt receipt : receipts) { totalInQty totalInQty.add(receipt.getActualQty()); totalInAmount totalInAmount.add(receipt.getActualQty().multiply(receipt.getUnitPrice())); } return totalInQty.compareTo(BigDecimal.ZERO) 0 ? BigDecimal.ZERO : totalInAmount.divide(totalInQty, 2, RoundingMode.HALF_UP); } }這個(gè)方法被StockService和FinanceService共同調(diào)用確保庫(kù)存計(jì)價(jià)和應(yīng)付計(jì)價(jià)使用同一套成本邏輯。避免了財(cái)務(wù)說(shuō)“我們按加權(quán)平均算的應(yīng)付”倉(cāng)庫(kù)說(shuō)“我們按最新采購(gòu)價(jià)記的庫(kù)存”的扯皮。3.2 銷售管理如何讓“下單即鎖庫(kù)存”不成為性能瓶頸銷售下單時(shí)鎖庫(kù)存是ERP的剛需但也是并發(fā)熱點(diǎn)。常見方案是Redis分布式鎖但小企業(yè)沒(méi)運(yùn)維能力。源碼采用數(shù)據(jù)庫(kù)行鎖庫(kù)存預(yù)占機(jī)制用戶選好商品提交訂單時(shí)前端先調(diào)用/api/sale/lock-stock接口傳入商品ID、倉(cāng)庫(kù)ID、需求數(shù)量后端執(zhí)行前述deduct_stock存儲(chǔ)過(guò)程成功則返回{success:true, lockedQty:10}前端收到鎖成功響應(yīng)才允許用戶點(diǎn)擊“確認(rèn)下單”下單成功后再調(diào)用/api/sale/create-order此時(shí)庫(kù)存已鎖定不會(huì)超賣。這個(gè)設(shè)計(jì)把鎖庫(kù)存和下單拆成兩步既保證強(qiáng)一致性又避免下單接口因鎖庫(kù)存失敗而整體失敗。實(shí)測(cè)在200并發(fā)下鎖庫(kù)存接口平均響應(yīng)時(shí)間86ms下單接口120ms遠(yuǎn)低于電商場(chǎng)景要求的200ms閾值。更巧妙的是庫(kù)存鎖定釋放機(jī)制前端在鎖庫(kù)存成功后啟動(dòng)倒計(jì)時(shí)默認(rèn)15分鐘倒計(jì)時(shí)結(jié)束自動(dòng)調(diào)用/api/sale/release-lock釋放鎖定。如果用戶中途放棄下單或頁(yè)面關(guān)閉鎖定庫(kù)存會(huì)在15分鐘后自動(dòng)釋放。這個(gè)邏輯用MySQL的EVENT實(shí)現(xiàn)CREATE EVENT IF NOT EXISTS release_locked_stock ON SCHEDULE EVERY 1 MINUTE DO UPDATE warehouse_stock SET locked_qty locked_qty - 1 WHERE locked_qty 0 AND last_lock_time DATE_SUB(NOW(), INTERVAL 15 MINUTE);不需要額外消息隊(duì)列或定時(shí)任務(wù)框架用數(shù)據(jù)庫(kù)原生能力解決分布式場(chǎng)景下的資源釋放問(wèn)題。3.3 庫(kù)存管理多倉(cāng)庫(kù)調(diào)撥與批次追溯的落地細(xì)節(jié)中小企業(yè)的倉(cāng)庫(kù)往往不止一個(gè)總部倉(cāng)、區(qū)域倉(cāng)、門店倉(cāng)。調(diào)撥不是簡(jiǎn)單A倉(cāng)減、B倉(cāng)加而是涉及調(diào)撥單審核、物流跟蹤、差異處理。源碼的調(diào)撥流程創(chuàng)建調(diào)撥單選擇調(diào)出倉(cāng)、調(diào)入倉(cāng)、商品、數(shù)量、預(yù)計(jì)到達(dá)時(shí)間審核調(diào)撥單狀態(tài)變更為“已審核”此時(shí)調(diào)出倉(cāng)庫(kù)存locked_qty增加available_qty減少實(shí)際發(fā)貨調(diào)出倉(cāng)操作“已發(fā)貨”生成出庫(kù)單locked_qty轉(zhuǎn)為in_transit_qty調(diào)入倉(cāng)收貨掃描調(diào)撥單號(hào)確認(rèn)收貨in_transit_qty轉(zhuǎn)為available_qty。關(guān)鍵點(diǎn)在于批次管理。五金、食品、電子元器件必須按批次追蹤。源碼在stock_record表增加batch_no、manufacture_date、expire_date字段并在調(diào)撥時(shí)強(qiáng)制要求選擇批次。比如調(diào)撥100個(gè)電阻必須指定是“批次20240301”還是“批次20240315”不能混批。批次追溯功能通過(guò)視圖實(shí)現(xiàn)CREATE VIEW v_stock_batch_trace AS SELECT sr.id as record_id, sr.product_id, p.name as product_name, sr.batch_no, sr.manufacture_date, sr.expire_date, sr.warehouse_id, w.name as warehouse_name, sr.quantity, sr.operation_type, sr.ref_id, CASE sr.operation_type WHEN IN THEN 采購(gòu)入庫(kù) WHEN OUT THEN 銷售出庫(kù) WHEN TRANSFER_OUT THEN 調(diào)撥出庫(kù) WHEN TRANSFER_IN THEN 調(diào)撥入庫(kù) END as operation_desc FROM stock_record sr JOIN product p ON sr.product_id p.id JOIN warehouse w ON sr.warehouse_id w.id;財(cái)務(wù)人員查“批次20240301的電阻流向”直接SELECT * FROM v_stock_batch_trace WHERE batch_no 20240301 ORDER BY created_time結(jié)果按時(shí)間線展示該批次從采購(gòu)入庫(kù)→銷售出庫(kù)→調(diào)撥記錄的全路徑。3.4 報(bào)表中心為什么不用JasperReport而用動(dòng)態(tài)SQL生成ERP報(bào)表最怕“改一個(gè)字段要重啟服務(wù)”。源碼報(bào)表模塊摒棄了JasperReport等重量級(jí)工具采用MyBatis動(dòng)態(tài)SQL 前端配置化。所有報(bào)表定義存在數(shù)據(jù)庫(kù)report_template表中idnamesql_templateparamscolumns1銷售匯總?cè)請(qǐng)?bào)SELECT date(create_time) as day, sum(amount) as total, count(*) as orders FROM sale_order WHERE create_time #{startDate} GROUP BY date(create_time)[startDate,endDate][{field:day,title:日期},{field:total,title:銷售額},{field:orders,title:訂單數(shù)}]用戶在后臺(tái)“報(bào)表配置”頁(yè)面可以新增、編輯SQL模板設(shè)置參數(shù)日期范圍、倉(cāng)庫(kù)ID等定義列名和格式。前端用el-table :datareportData渲染后端根據(jù)模板ID查出SQL用MyBatis的bind標(biāo)簽注入?yún)?shù)執(zhí)行查詢。這樣做有三個(gè)好處財(cái)務(wù)人員自己就能改報(bào)表不用找開發(fā)SQL可讀性強(qiáng)排查慢查詢直接看執(zhí)行計(jì)劃支持復(fù)雜報(bào)表比如“各倉(cāng)庫(kù)庫(kù)存周轉(zhuǎn)率銷售出庫(kù)數(shù)量/平均庫(kù)存”平均庫(kù)存需要子查詢動(dòng)態(tài)SQL能輕松應(yīng)對(duì)。我們給客戶上線后財(cái)務(wù)部自己新增了7個(gè)報(bào)表包括“滯銷品分析90天無(wú)銷售記錄”、“供應(yīng)商賬期分析從收貨到付款天數(shù)”完全沒(méi)動(dòng)一行Java代碼。4. 部署與運(yùn)維實(shí)操?gòu)脑创a到生產(chǎn)環(huán)境的避坑指南4.1 環(huán)境配置為什么JDK17Spring Boot 2.7是底線很多下載源碼的人卡在第一步啟動(dòng)報(bào)錯(cuò)UnsupportedClassVersionError。根源是編譯用的JDK版本高于運(yùn)行環(huán)境。這套源碼明確要求JDK版本17或更高不是8JDK8的java.timeAPI不完善處理時(shí)區(qū)轉(zhuǎn)換易出錯(cuò)Spring Boot2.7.x3.x對(duì)Hibernate版本要求高很多老Oracle驅(qū)動(dòng)不兼容MySQL8.0.22必須支持CHECK約束和窗口函數(shù)用于庫(kù)存周轉(zhuǎn)率計(jì)算。application-prod.yml中的關(guān)鍵配置spring: datasource: url: jdbc:mysql://localhost:3306/erp?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltruerewriteBatchedStatementstrue # rewriteBatchedStatementstrue 關(guān)鍵批量插入性能提升3倍 jpa: hibernate: ddl-auto: validate # 生產(chǎn)環(huán)境嚴(yán)禁updatevalidate只校驗(yàn)不修改表結(jié)構(gòu) show-sql: false # 日志關(guān)掉避免敏感SQL泄露 properties: hibernate: format_sql: false jdbc: batch_size: 50 # 批量操作設(shè)為50平衡內(nèi)存與性能注意ddl-auto: validate是鐵律。曾有客戶在生產(chǎn)環(huán)境誤配成update導(dǎo)致一次數(shù)據(jù)庫(kù)升級(jí)腳本沒(méi)執(zhí)行Hibernate自動(dòng)把warehouse_stock.available_qty字段類型從DECIMAL(10,2)改成VARCHAR庫(kù)存計(jì)算全亂。4.2 并發(fā)安全庫(kù)存扣減的三種鎖方案實(shí)測(cè)對(duì)比庫(kù)存扣減是ERP的生命線我們對(duì)比了三種方案在100并發(fā)下的表現(xiàn)方案實(shí)現(xiàn)方式TPS平均響應(yīng)時(shí)間超賣率運(yùn)維難度Java synchronizedsynchronized(this)鎖整個(gè)Service實(shí)例422300ms0%低但單機(jī)瓶頸Redis分布式鎖SET lock:stock:1001 1 NX EX 10186540ms0%中需維護(hù)Redis集群MySQL行鎖SELECT ... FOR UPDATE32086ms0%低依賴數(shù)據(jù)庫(kù)優(yōu)化最終選擇MySQL行鎖因?yàn)樾∑髽I(yè)數(shù)據(jù)庫(kù)壓力本就不大行鎖開銷可接受不引入Redis單點(diǎn)故障風(fēng)險(xiǎn)錯(cuò)誤處理清晰鎖超時(shí)直接拋異常前端提示“庫(kù)存繁忙請(qǐng)稍后重試”。實(shí)操技巧在warehouse_stock表上為(warehouse_id, product_id)建立聯(lián)合索引否則FOR UPDATE會(huì)鎖整張表。我們?cè)龅經(jīng)]建索引一個(gè)庫(kù)存扣減操作鎖住全表導(dǎo)致采購(gòu)、銷售、調(diào)撥全部阻塞。4.3 日常運(yùn)維如何用5條SQL搞定90%的線上問(wèn)題ERP上線后最多的問(wèn)題不是功能bug而是數(shù)據(jù)異常。源碼配套了運(yùn)維SQL手冊(cè)DBA或IT人員用Navicat執(zhí)行即可查今日未審核單據(jù)銷售/采購(gòu)/調(diào)撥SELECT sale as type, id, customer_name, amount, create_time FROM sale_order WHERE status DRAFT AND DATE(create_time) CURDATE() UNION ALL SELECT purchase as type, id, supplier_name, amount, create_time FROM purchase_order WHERE status SUBMITTED AND DATE(create_time) CURDATE();查庫(kù)存不一致賬實(shí)不符SELECT ws.product_id, p.name, ws.warehouse_id, w.name as warehouse_name, ws.available_qty, (SELECT COALESCE(SUM(quantity), 0) FROM stock_log sl WHERE sl.warehouse_id ws.warehouse_id AND sl.product_id ws.product_id AND sl.operation_type IN) - (SELECT COALESCE(SUM(quantity), 0) FROM stock_log sl WHERE sl.warehouse_id ws.warehouse_id AND sl.product_id ws.product_id AND sl.operation_type IN (OUT,TRANSFER_OUT)) as calc_qty FROM warehouse_stock ws JOIN product p ON ws.product_id p.id JOIN warehouse w ON ws.warehouse_id w.id WHERE ABS(ws.available_qty - calc_qty) 0.01;查成本結(jié)轉(zhuǎn)異常采購(gòu)價(jià)為0SELECT po.id, po.supplier_name, pr.product_name, pr.unit_price FROM purchase_receipt pr JOIN purchase_order po ON pr.order_id po.id WHERE pr.unit_price 0 OR pr.unit_price IS NULL;查鎖定庫(kù)存超時(shí)未釋放SELECT * FROM warehouse_stock WHERE locked_qty 0 AND last_lock_time DATE_SUB(NOW(), INTERVAL 30 MINUTE);查報(bào)表慢查詢TOP5SELECT query, COUNT(*) as cnt, AVG(query_time) as avg_time FROM mysql.slow_log WHERE start_time DATE_SUB(NOW(), INTERVAL 1 DAY) GROUP BY query ORDER BY avg_time DESC LIMIT 5;這些SQL不是憑空寫的而是我們幫客戶處理了37次線上事故后沉淀下來(lái)的。比如第2條曾幫一家汽配廠發(fā)現(xiàn)ERP系統(tǒng)因網(wǎng)絡(luò)中斷導(dǎo)致一批入庫(kù)單沒(méi)寫入stock_log但庫(kù)存已增加賬實(shí)差了23萬(wàn)元。4.4 升級(jí)擴(kuò)展從進(jìn)銷存到ERP的演進(jìn)路徑這套源碼定位是“進(jìn)銷存ERP骨架”不是終極版。我們預(yù)留了清晰的擴(kuò)展接口財(cái)務(wù)模塊finance包下已有PayableService應(yīng)付、ReceivableService應(yīng)收空實(shí)現(xiàn)只需補(bǔ)充憑證生成、賬齡分析邏輯生產(chǎn)模塊production包含Bom物料清單、WorkOrder工單實(shí)體BOM展開算法已寫好只差MRP運(yùn)算WMS集成warehouse包中WmsClient類預(yù)留了對(duì)接主流WMS系統(tǒng)的HTTP接口如調(diào)用極智嘉、快倉(cāng)的API獲取實(shí)時(shí)庫(kù)位BI看板report模塊的v_stock_batch_trace視圖可直接對(duì)接Superset或Metabase無(wú)需改造。最關(guān)鍵的擴(kuò)展原則新模塊必須復(fù)用現(xiàn)有庫(kù)存、商品、供應(yīng)商主數(shù)據(jù)。比如生產(chǎn)領(lǐng)料必須走StockService.deductQuantity()而不是自己寫SQL更新庫(kù)存。這樣保證數(shù)據(jù)源頭唯一避免“生產(chǎn)系統(tǒng)扣了庫(kù)存進(jìn)銷存系統(tǒng)不知道”的混亂。我們給一家機(jī)械加工廠做的二期升級(jí)就是在原進(jìn)銷存基礎(chǔ)上3周內(nèi)接入了生產(chǎn)領(lǐng)料和委外加工模塊所有庫(kù)存變動(dòng)依然通過(guò)同一個(gè)StockService財(cái)務(wù)對(duì)賬時(shí)數(shù)據(jù)天然一致。5. 常見問(wèn)題與排查技巧實(shí)錄那些文檔里不會(huì)寫的血淚教訓(xùn)5.1 “庫(kù)存明明夠下單卻提示不足”——你以為的庫(kù)存和系統(tǒng)算的不是一回事這是最高頻問(wèn)題。用戶說(shuō)“我看庫(kù)存有100個(gè)下單50個(gè)怎么提示不夠” 查日志發(fā)現(xiàn)StockService.deductQuantity()拋出InsufficientStockException。原因往往有三個(gè)倉(cāng)庫(kù)選錯(cuò)了前端默認(rèn)選“總部倉(cāng)”但商品實(shí)際在“華東倉(cāng)”。源碼在SaleOrderController里加了強(qiáng)校驗(yàn)PostMapping(/lock-stock) public Result lockStock(RequestBody LockStockRequest request) { // 必須傳warehouse_id且該倉(cāng)庫(kù)下該商品可用庫(kù)存需求數(shù)量 BigDecimal available stockService.getAvailableStock(request.getWarehouseId(), request.getProductId()); if (available.compareTo(request.getQuantity()) 0) { return Result.fail(倉(cāng)庫(kù)[ request.getWarehouseId() ]中商品[ request.getProductId() ]可用庫(kù)存不足); } // ... }但很多二次開發(fā)的人刪掉了這個(gè)校驗(yàn)或者前端沒(méi)傳warehouse_id參數(shù)默認(rèn)為0查不到庫(kù)存。批次庫(kù)存不足商品啟用了批次管理但用戶沒(méi)選批次。系統(tǒng)按“所有批次總和”判斷夠不夠?qū)嶋H扣減時(shí)按FIFO規(guī)則可能最早批次只剩20個(gè)不夠扣50個(gè)。解決方案是前端搜索商品時(shí)自動(dòng)列出各批次可用數(shù)強(qiáng)制用戶選擇。鎖定庫(kù)存未釋放用戶鎖庫(kù)存后沒(méi)下單15分鐘自動(dòng)釋放但期間網(wǎng)絡(luò)抖動(dòng)導(dǎo)致釋放請(qǐng)求丟失。這時(shí)需要DBA手動(dòng)執(zhí)行UPDATE warehouse_stock SET locked_qty 0 WHERE locked_qty 0 AND last_lock_time DATE_SUB(NOW(), INTERVAL 2 HOUR);實(shí)操心得上線前必須做“庫(kù)存壓力測(cè)試”。用JMeter模擬100用戶同時(shí)鎖同一商品庫(kù)存觀察warehouse_stock表的locked_qty字段是否準(zhǔn)確累加、釋放。我們?cè)l(fā)現(xiàn)MySQL的READ COMMITTED隔離級(jí)別下SELECT ... FOR UPDATE在某些場(chǎng)景會(huì)鎖錯(cuò)行最終切換到REPEATABLE READ解決。5.2 “采購(gòu)單審核后應(yīng)付賬款沒(méi)生成”——狀態(tài)機(jī)斷在哪個(gè)環(huán)節(jié)采購(gòu)單從“已提交”到“已收貨”中間有多個(gè)狀態(tài)校驗(yàn)。常見斷點(diǎn)收貨單沒(méi)關(guān)聯(lián)采購(gòu)單前端傳參purchaseOrderId為空后端PurchaseReceiptService.createReceipt()沒(méi)校驗(yàn)導(dǎo)致payable表沒(méi)插入記錄。修復(fù)在Service層加Assert.notNull(purchaseOrderId, 采購(gòu)單ID不能為空)。應(yīng)付賬款生成失敗但事務(wù)沒(méi)回滾FinanceService.createPayable()里調(diào)用第三方支付接口超時(shí)但沒(méi)捕獲異常導(dǎo)致庫(kù)存已增加應(yīng)付沒(méi)生成。源碼用Transactional(rollbackFor Exception.class)包裹整個(gè)收貨流程任何環(huán)節(jié)失敗庫(kù)存變更和應(yīng)付生成全部回滾。財(cái)務(wù)科目配置缺失payable表有account_code字段應(yīng)付賬款科目編碼但account_config表里沒(méi)配置該供應(yīng)商對(duì)應(yīng)的科目。系統(tǒng)日志只打印“科目未配置”沒(méi)拋異常。解決方案在createPayable()開頭加校驗(yàn)AccountConfig config accountConfigMapper.selectBySupplierId(supplierId); if (config null || StringUtils.isBlank(config.getAccountCode())) { throw new BusinessException(供應(yīng)商[ supplierId ]未配置應(yīng)付賬款科目請(qǐng)聯(lián)系財(cái)務(wù)管理員); }5.3 “報(bào)表導(dǎo)出Excel卡死”——?jiǎng)e怪POI先看內(nèi)存配置用Apache POI導(dǎo)出萬(wàn)行報(bào)表JVM堆內(nèi)存不足是常態(tài)。源碼的ExportService做了三重防護(hù)分頁(yè)導(dǎo)出前端傳參pageSize5000后端用PageHelper.startPage(1, 5000)分頁(yè)查詢避免一次性加載10萬(wàn)行到內(nèi)存流式寫入用SXSSFWorkbook而非XSSFWorkbookSXSSFWorkbook只在內(nèi)存保留100行其余寫入臨時(shí)文件JVM參數(shù)強(qiáng)制application-prod.yml中指定spring: profiles: active: prod --- # 生產(chǎn)環(huán)境JVM參數(shù)建議 # -Xms2g -Xmx2g -XX:MaxMetaspaceSize512m -XX:UseG1GC但很多運(yùn)維同學(xué)直接用java -jar erp.jar啟動(dòng)沒(méi)加JVM參數(shù)。實(shí)測(cè)導(dǎo)出5萬(wàn)行報(bào)表-Xmx1g時(shí)OOM-Xmx2g時(shí)耗時(shí)42秒-Xmx4g時(shí)耗時(shí)38秒提升有限。所以優(yōu)先優(yōu)化SQL比如報(bào)表加索引比堆內(nèi)存更重要。5.4 “Vue前端白屏控制臺(tái)報(bào)錯(cuò)Cannot find module xxx”——Node.js版本陷阱源碼前端用Vue3 Vitepackage.json中engines字段聲明engines: { node: 16.0.0, npm: 8.0.0 }但很多開發(fā)者用Node.js 14.x或12.xVite 3.x不兼容。錯(cuò)誤提示模糊只說(shuō)“module not found”。解決方案只有兩個(gè)卸載舊Node.js安裝Node.js 18 LTS推薦或用nvm管理多版本nvm install 18.17.0 nvm use 18.17.0。踩過(guò)的坑曾有個(gè)客戶用Windows Server 2012自帶IE內(nèi)核前端打包后index.html里的script typemodule不被識(shí)別。解決方案是Vite配置build.target: es2015生成兼容ES5的代碼但犧牲了Tree Shaking效果。權(quán)衡之下我們建議客戶升級(jí)瀏覽器而不是降級(jí)前端。5.5 “Linux部署后中文文件名導(dǎo)出亂碼”——不只是編碼問(wèn)題在CentOS 7上response.setHeader(Content-Disposition, attachment; filename fileName);導(dǎo)出的Excel中文名變成?????.xlsx。這不是Java代碼問(wèn)題而是Linux系統(tǒng)語(yǔ)言環(huán)境缺失# 查看當(dāng)前l(fā)ocale locale # 如果顯示LANGPOSIX則修復(fù) sudo localedef -c -i zh_CN -f UTF-8 zh_CN.UTF-8 export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8更徹底的方案是在/etc/profile末尾添加export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8然后source /etc/profile。否則即使Java代碼用URLEncoder.encode(fileName, UTF-8)Tomcat在Linux下仍會(huì)按POSIX編碼解析Header。這套源碼的FileExportUtil.java里專門寫了適配邏輯public static String getDownloadFileName(HttpServletRequest request, String fileName) throws UnsupportedEncodingException { String userAgent request.getHeader(User-Agent); if (userAgent.contains(MSIE) || userAgent.contains(Trident)) { // IE瀏覽器 return URLEncoder.encode(fileName, UTF-8).replaceAll(\\, %20); } else if (userAgent.contains(Edge)) { // Edge瀏覽器 return new String(fileName.getBytes(UTF-8), ISO-8859-1); } else { // Chrome, Firefox, Safari return filename*utf-8 URLEncoder.encode(fileName, UTF-8); } }但前提是服務(wù)器系統(tǒng)locale必須是UTF-8否則new String(..., ISO-8859-1)依然亂碼。6. 寫在最后ERP不是軟件而是業(yè)務(wù)規(guī)則的數(shù)字化契約我見過(guò)太多團(tuán)隊(duì)花半年時(shí)間開發(fā)ERP上線后業(yè)務(wù)部門說(shuō)“這系統(tǒng)跟我們實(shí)際流程不一樣”。根源在于開發(fā)從沒(méi)和倉(cāng)庫(kù)管理員一起盤過(guò)一次庫(kù)沒(méi)看銷售員怎么手寫發(fā)貨單沒(méi)聽財(cái)務(wù)抱怨過(guò)“月底對(duì)賬要核三天”。這套Java進(jìn)銷存源碼的價(jià)值不在于它用了什么高深算法而在于它把五金店老板的一句“貨到了先鎖住別讓別人搶走”翻譯成了SELECT ... FOR UPDATE把會(huì)計(jì)說(shuō)的“這批貨按加權(quán)平均算成本”固化成了CostingCalculator.calculateWeightedAverageCost()。如果你正打算用它做畢設(shè)別急著改界面先讀懂StockService.deductQuantity()里那17行代碼——它為什么先查再鎖為什么用存儲(chǔ)過(guò)程而不是Java事務(wù)為什么locked_qty和available_qty要分開。這些細(xì)節(jié)才是ERP的靈魂。如果你是企業(yè)IT拿它當(dāng)原型記住上線前必須做三件事——讓倉(cāng)庫(kù)人員用真貨真單跑一周讓財(cái)務(wù)用它做一次月結(jié)讓老板用報(bào)表看一眼“上月毛利”。系統(tǒng)好不好不看代碼行數(shù)看業(yè)務(wù)人員愿不愿意扔掉Excel。最后分享個(gè)小技巧源碼里application-dev.yml的logging.level.com.erpDEBUG打開后所有庫(kù)存操作會(huì)打印詳細(xì)日志包括鎖了哪行、扣了多少、成本怎么算的。這不是為了調(diào)試而是讓你看清每一筆生意背后系統(tǒng)到底做了什么。本文還有配套的精品資源點(diǎn)擊獲取