前幾天把一套物資綜合管理系統(tǒng)重新整理了一遍從后端接口到前端頁面再到數(shù)據(jù)庫腳本全部跑通之后打包成了一份可以直接運行的源碼。這套東西不是那種只有幾個空殼頁面的演示項目而是把企業(yè)里物資管理的真實流程都做了進去物資分類、入庫登記、庫存查詢、領用審批、出庫記錄、統(tǒng)計報表該有的模塊基本都齊了。技術棧是SpringBoot做后端接口Vue做前端頁面MySQL存數(shù)據(jù)典型的前后端分離結構。今天把整個項目的設計思路、核心實現(xiàn)、運行步驟和踩坑記錄完整梳理出來希望能幫到正在做類似系統(tǒng)或者打算拿這種項目練手的朋友。這套源碼特別適合三類人一是正在準備畢業(yè)設計的學生拿來改改就能用二是剛學完SpringBoot和Vue、想看一個完整真實項目長什么樣的初學者三是公司內部確實需要一套輕量級物資管理工具、但不想買商業(yè)軟件的運維或開發(fā)人員。比起那些只貼出幾個核心代碼片段、根本跑不起來的教程源碼這一套最大的特點就是開箱即用。下面我會從架構拆解、后端設計、前端實現(xiàn)、數(shù)據(jù)庫腳本、運行步驟和問題排查這幾個維度一層層講透。1. 項目整體設計與架構拆解1.1 這套系統(tǒng)到底解決了什么問題先說說物資管理這個場景。很多中小型公司或者學校、事業(yè)單位物資管理還停留在Excel表格加微信群的階段。入庫登記靠手寫領用物資靠口頭招呼月底盤點發(fā)現(xiàn)庫存對不上新來的同事不知道倉庫里到底有什么。這些零散的痛點聚在一起就是物資管理系統(tǒng)存在的理由。一個完整的物資管理系統(tǒng)核心閉環(huán)就三條線物資進來、庫存放量、物資出去。再往里拆就是物資的入庫單管理、庫存臺賬管理、領用申請與審批、出庫登記以及圍繞這些數(shù)據(jù)產(chǎn)生的統(tǒng)計報表。這套源碼正是按照這條主線來組織的沒有堆砌多余的社交功能、審批流引擎之類的重東西業(yè)務邊界很克制這對中小規(guī)模場景反而是優(yōu)勢。1.2 為什么選SpringBoot加Vue加MySQL這個組合先說后端。SpringBoot在這個領域已經(jīng)成為事實標準它解決的核心痛點是Spring傳統(tǒng)項目中那些繁瑣的XML配置、依賴管理沖突和部署流程。使用SpringBoot之后一個內嵌的Tomcat、一套起步依賴、一個Application主類就能把后端服務跑起來這對維護和二次開發(fā)來說非常友好。前端選Vue的原因也很實在。Vue的數(shù)據(jù)雙向綁定和組件化開發(fā)特別適合管理后臺這類表單密集、列表密集、交互狀態(tài)多的頁面。填一個入庫表單時校驗規(guī)則要即時反饋查庫存時表格列要動態(tài)隱藏這些用jQuery那套手動操作DOM的方式來做代碼量會膨脹幾倍。Vue的響應式數(shù)據(jù)模型天然匹配這類需求。再加上Element UI這類成熟組件庫表格、彈窗、表單校驗、分頁組件直接拿來用開發(fā)效率高很多。MySQL就更不用說了開源、穩(wěn)定、普及率高不管是本機部署還是上云都有大量現(xiàn)成經(jīng)驗可參考。這套系統(tǒng)沒有用到Redis做緩存也沒有引入消息隊列全部依賴MySQL的關系型事務能力小團隊的運維成本可以壓到非常低。可能有人會問為什么不用更流行的前后端分離之外的單體架構或者微服務架構。這么看物資管理系統(tǒng)的用戶量級通常就是幾十到幾百人并發(fā)不高事務復雜度中等單體應用配合前后端分離已經(jīng)是性價比最高的方案了。引入微服務只會增加運維負擔沒有任何實際收益。技術選型不是越新越好是匹配場景才叫好。1.3 源碼的工程結構一覽拿到源碼之后整個項目分兩個大目錄后端back-end或者叫server前端front-end或者叫web。我這邊習慣把后端命名為server、前端命名為ui方便區(qū)分。后端的工程結構按Maven標準劃分你可能會看到這樣的布局server ├── src/main/java/com/example/wms │ ├── controller # 接收HTTP請求返回Result結果 │ ├── service # 業(yè)務邏輯層接口加實現(xiàn)類 │ ├── mapper # MyBatis的Mapper接口對應XML或注解SQL │ ├── entity # 數(shù)據(jù)庫實體類 │ ├── dto # 前端傳輸對象用于參數(shù)接收與結果封裝 │ ├── config # 配置類跨域、攔截器、WebMvc配置 │ ├── common # 統(tǒng)一返回體、異常處理、工具類 │ └── WmsApplication.java # SpringBoot啟動類 └── src/main/resources ├── application.yml # 數(shù)據(jù)源、端口、MyBatis配置 └── mapper # MyBatis XML文件前端的結構就是標準的Vue工程ui ├── src │ ├── api # 按模塊封裝的接口請求 │ ├── assets # 靜態(tài)資源 │ ├── components # 公共組件分頁、彈窗等 │ ├── router # 路由配置與守衛(wèi) │ ├── store # Vuex狀態(tài)管理token、用戶信息 │ ├── views # 頁面登錄、物資、入庫、領用、統(tǒng)計等 │ ├── App.vue │ └── main.js ├── package.json └── vue.config.js # 開發(fā)服務器與代理配置這套結構的優(yōu)點是職責清晰前端頁面找不到數(shù)據(jù)就去api目錄找接口后端接口出問題就去service層看邏輯排查問題路徑非常直接。2. 后端核心模塊設計與實現(xiàn)解析2.1 統(tǒng)一返回體與全局異常處理為什么是必需品后端接口不可能只返回數(shù)據(jù)本身還得告訴前端這次請求成功沒有、如果失敗了是哪一類問題、提示信息應該怎么展示。如果每個接口都自己拼返回值前端每個請求都要單獨做異常判斷代碼就亂套了。這套源碼里定義了一個Result類結構大概是這樣的public class ResultT { private Integer code; // 200成功500業(yè)務失敗401未登錄取 private String message; // 提示信息 private T data; // 業(yè)務數(shù)據(jù) }所有Controller統(tǒng)一返回Result對象成功就Result.success(data)業(yè)務校驗不通過就Result.error(庫存不足)。前端拿到響應之后先看code再取data邏輯非常統(tǒng)一。這里有個關鍵設計業(yè)務異常和系統(tǒng)異常要分開處理。我見過很多項目把系統(tǒng)異常直接拋到前端用戶看到一堆OOM的堆棧信息這個體驗是非常糟糕的。配合一個全局異常處理器RestControllerAdvice把系統(tǒng)異常統(tǒng)一轉換成系統(tǒng)繁忙請稍后再試把業(yè)務異常直接帶入提示信息這才是正經(jīng)做法。這套源碼里已經(jīng)把這一層做完了不需要你再自己去補。2.2 登錄認證怎么做的為什么選這種方案企業(yè)系統(tǒng)基本都需要登錄物資管理系統(tǒng)也不例外。管理員難道要管庫存和用戶權限普通員工只能申請領用物資這個身份區(qū)分在數(shù)據(jù)庫層面就要體現(xiàn)出來。登錄認證這塊源碼采用的是Token加攔截器的方式而不是傳統(tǒng)Session方案。每次用戶登錄成功后后端生成一個Token可以是UUID也可以是用JWT加密生成把用戶ID和角色信息寫進Token里然后返回給前端。前端存在localStorage中每次請求在Header里帶上后端攔截器解析Token、讀取用戶身份。為什么不直接用Session因為前后端分離之后前端和后端往往不在同一個域名和端口下Session的Cookie跨域策略處理起來很麻煩。Token的方式天然支持跨域而且無狀態(tài)后端重啟也不會把用戶的登錄狀態(tài)沖掉這對本地開發(fā)和上線部署都省心很多。密碼存儲是個老生常談但必須強調的點。源碼里不會對密碼明文存儲用的是BCrypt加密也就是SpringSecurity自帶的那套加密工具。每次校驗時把前端傳過來的明文密碼和數(shù)據(jù)庫里存的加密密碼做匹配而不是直接拼接SQL比對字符串。如果你拿到別的源碼發(fā)現(xiàn)密碼字段是明文請一定不要直接上線使用。2.3 核心業(yè)務表與接口設計思路物資管理系統(tǒng)的核心表通常是這幾張物資分類表、物資信息表或者叫物資檔案表、入庫單主表加明細表、領用單主表加明細表以及系統(tǒng)用戶表。拿入庫單來舉例一張入庫單需要記錄單號、經(jīng)手人、入庫時間、供應商如果是采購入庫、備注這是一條主表記錄。入庫單下面可能同時包含多種物資每種物資入庫數(shù)量不同所以還需要一張明細表來存這次入庫了幾種物資、每種是多少。這種主表加明細表的設計在進銷存系統(tǒng)里極其常見也是物資管理系統(tǒng)的地基。接口設計上用的是RESTful風格各業(yè)務模塊的路徑劃分很清楚模塊接口路徑說明登錄認證POST /api/auth/login登錄并返回Token物資分類GET/POST/PUT/DELETE /api/category分類的增刪改查物資檔案GET/POST/PUT/DELETE /api/material物資信息的維護入庫管理POST /api/stock/in創(chuàng)建入庫單并更新庫存領用管理POST /api/stock/out創(chuàng)建領用單并扣減庫存庫存查詢GET /api/stock/list分頁查詢各物資的當前庫存統(tǒng)計報表GET /api/report/summary匯總入庫量、出庫量、庫存余額這種按業(yè)務模塊切分接口的好處是擴展性好。比如后面要加一個報廢功能那就增加一個/api/stock/scrap接口和現(xiàn)有的入庫、領用并列不會影響已經(jīng)穩(wěn)定的邏輯。加一個小提醒入庫和領用接口在源碼中都用事務Transactional包裹因為建單和改庫存必須同時成功或同時失敗。這一步如果沒做事務極端情況下會出現(xiàn)單據(jù)創(chuàng)建成功但庫存沒加上去的情況對業(yè)務來說就是重大數(shù)據(jù)事故。2.4 Mapper層與SQL的一些細節(jié)心得持久層這塊源碼用的是MyBatis而且建議直接用MyBatis-Plus來跑省去大量寫單表CRUD的重復勞動。為什么要這么選因為物資管理系統(tǒng)里有大量的單表分頁查詢、條件過濾、增刪改查這些邏輯幾乎一模一樣的代碼用MyBatis-Plus的BaseMapper可以直接繼承現(xiàn)成的通用方法代碼量能減掉三分之一還多。報表類SQL是繞不開的坎。比如統(tǒng)計每種物資的累計入庫量、累計出庫量和當前庫存SQL思路是用分組聚合加條件匯總SELECT material_id, SUM(CASE WHEN type IN THEN quantity ELSE 0 END) AS total_in, SUM(CASE WHEN type OUT THEN quantity ELSE 0 END) AS total_out, SUM(CASE WHEN type IN THEN quantity ELSE -quantity END) AS current_stock FROM stock_record GROUP BY material_id這里有一個容易踩的坑庫存字段到底用int還是decimal。如果物資按個、箱、瓶這類整數(shù)單位計算數(shù)量字段用int就夠了不要用decimal因為decimal會引入精度問題后臺對賬會非常痛苦。但如果是金額、單價這類字段必須用decimal不能圖省事用doubledouble的浮點誤差在累加、匯總后會被無限放大。這個設計決策在前面的表結構里就要定好不然后期改字段類型代價很大。3. 前端Vue工程核心實現(xiàn)解析3.1 前端工程初始化與頁面布局前端工程初始化用的Vue CLI或者Vite都行源碼里基于Vue的組件化機制搭建了一整套管理后臺布局左側是菜單欄物資管理、入庫管理、領用管理、系統(tǒng)管理之類的入口頂部是用戶信息和退出按鈕中間的內容區(qū)用來承載各個頁面。這種布局是所有管理系統(tǒng)的標配用戶進入系統(tǒng)不用額外學習成本。組件庫這塊建議使用Element UI對應Vue2或者Element Plus對應Vue3。像物資信息表格、入庫單的彈窗表單、領用明細的級聯(lián)選擇器這些組件都有現(xiàn)成的封裝直接按文檔配置就好。這套源碼里應該已經(jīng)做了一部分組件的二次封裝比如分頁組件、搜索表單組件目的是為了減少頁面之間的重復代碼。拿到源碼后你可以看一下components目錄下的封裝情況理解別人封裝組件的思路比自己從零開始寫要省力得多。3.2 路由權限控制到底怎么回事權限控制是前端設計里比較微妙的部分。常見的誤區(qū)是我只要把側邊欄菜單隱藏起來用戶就看不到?jīng)]權限的頁面了。這其實只是個花架子真正地控制在前端要配合路由守衛(wèi)在后端要配合接口權限校驗。前端路由守衛(wèi)的典型邏輯是router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (!token to.path ! /login) { next(/login); // 沒登錄只能去登錄頁 } else { next(); // 已登錄放行 } });這套源碼里在路由層面做了基本的Token守衛(wèi)同時在菜單渲染層面根據(jù)用戶角色動態(tài)顯示或隱藏入口。注意前端的權限控制只是用戶體驗的一部分真正的數(shù)據(jù)安全還得靠后端接口校驗比如刪除物資檔案的接口必須判斷當前用戶是否是管理員。把安全寄托在前端頁面隱藏上這是非常危險的想法。3.3 Axios封裝與前后端聯(lián)調的細節(jié)前端的異步請求庫基本都是Axios但直接在每個頁面里調用this.$http.post容易導致代碼重復。更規(guī)范的做法是統(tǒng)一封裝一個Request實例把公共邏輯都做在攔截器里。源碼里的大致做法如下// api/request.js import axios from axios; const request axios.create({ baseURL: process.env.VUE_APP_BASE_URL || /api, timeout: 10000 }); // 請求攔截器統(tǒng)一帶上token request.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] Bearer token; } return config; }); // 響應攔截器統(tǒng)一處理業(yè)務code碼 request.interceptors.response.use( response { const res response.data; if (res.code ! 200) { // 彈錯誤提示并拋出異常中斷后續(xù)操作 return Promise.reject(new Error(res.message)); } return res.data; }, error { // 處理HTTP層錯誤比如401跳登錄、500提示系統(tǒng)錯誤 return Promise.reject(error); } ); export default request;這套封裝方案幾乎適用于所有管理后臺項目。把錯誤提示統(tǒng)一放在攔截器里處理頁面里直接await調用接口拿數(shù)據(jù)就行大幅減少頁面級的重復try-catch。跨域問題在本地開發(fā)時幾乎必現(xiàn)。前端跑在8080端口后端跑在8080端口通過Axios直接訪問時瀏覽器的同源策略會攔下跨域請求。最省事的本地跨域方案不用后端加CORS注解而是在vue.config.js里配置代理轉發(fā)所有/api開頭請求都被Vue的devServer轉發(fā)到localhost:8088瀏覽器視角下就沒有跨域概念了。部署到生產(chǎn)環(huán)境時則用Nginx把前端的靜態(tài)資源和后端的/api路徑配置到同一個域名下從根源上消除跨域。3.4 核心頁面的交互邏輯拆解前端頁面的核心交互可以分成三類表單操作、列表查詢、信息反饋。拿入庫管理頁面來說用戶點擊新增入庫彈出表單選擇物資、填數(shù)量、填供應商、填備注提交后調用后端入庫接口成功后刷新庫存列表。這里最值得關注的是物資選擇器的設計。如果是一次入庫多種物資那頁面就需要一個動態(tài)表格點一次添加一行就增加一條物資明細行每一行都能選擇物資和填數(shù)量。這個交互模式在Vue里用數(shù)組循環(huán)渲染就好。el-table :dataorderItems el-table-column label物資 template #default{ row } el-select v-modelrow.materialId filterable placeholder請選擇物資 el-option v-form in materialList :keym.id :labelm.name :valuem.id / /el-select /template /el-table-column el-table-column label數(shù)量 template #default{ row } el-input-number v-modelrow.quantity :min1 / /template /el-table-column /el-table這種動態(tài)明細行的交互看似簡單但涉及一個要點新增行時需要給每行一個唯一標識可以用時間戳拼隨機數(shù)方便Vue對行的增刪進行追蹤避免刪錯行。這類細節(jié)就是經(jīng)驗積累出來的文檔上很少會寫。4. MySQL數(shù)據(jù)庫設計與初始化腳本要點4.1 核心表結構設計與字段類型心得數(shù)據(jù)庫是這套系統(tǒng)最持久的部分。前端頁面可以換后端接口可以重構但表結構一旦跑偏改起來的成本極高。所以建表的時候一定要想清楚。用戶表的核心字段就是id、用戶名、密碼BCrypt加密后的字符串、真實姓名、角色admin/user、創(chuàng)建時間。物資檔案表的字段相對多一些物資編碼、物資名稱、分類ID、規(guī)格型號、單位、單價、備注、創(chuàng)建時間。庫存表可以是單獨的一張表也可以直接依賴庫存匯總視圖但更清晰的做法是維護一張庫存表每次出入庫后更新對應物資的庫存值。這里分享一個字段命名和類型的經(jīng)驗。主鍵統(tǒng)一用bigint自增或者雪花ID邏輯刪除字段用deleted0未刪1已刪不要物理刪除記錄創(chuàng)建時間和更新時間用datetime不要用timestamp因為timestamp的取值范圍到2038年就過期了雖然日常開發(fā)用不到那么遠但一旦數(shù)據(jù)量大起來會非常麻煩。數(shù)量字段用int金額字段用decimal(10,2)文本字段用varchar并設置合理長度不要圖省事全部用texttext字段的索引和查詢性能都很差。4.2 初始化SQL腳本為什么是直接運行的關鍵這套源碼能直接運行很大程度上要歸功于初始化腳本設計得當。你的源碼包里應該有一個database目錄里面放著init.sql內容包含建庫語句、建表語句、默認管理員賬號的插入語句以及一小批演示數(shù)據(jù)。為了避免首次運行報數(shù)據(jù)庫不存在腳本開頭一般會有CREATE DATABASE IF NOT EXISTS wms DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE wms;然后是一個一個的CREATE TABLE IF NOT EXISTS。這里要特別提醒的是字符集和排序規(guī)則必須統(tǒng)一。utf8mb4相比utf8多出來的部分是能夠正確存儲emoji和生僻字的而且它的索引兼容性更好。很多人在本地跑通后放到服務器上出現(xiàn)亂碼絕大多數(shù)原因是建庫時用了utf8不是utf8mb4連接字符串也沒指定字符集前端頁面本身是UTF-8編碼三方一交叉中文就變成問號了。這套腳本里已經(jīng)把字符集預設好你執(zhí)行的時候不要手賤去改成默認值。4.3 SpringBoot數(shù)據(jù)源配置的幾個關鍵點后端application.yml里的數(shù)據(jù)源配置是整個項目能跑起來的生命線。核心配置包括server: port: 8088 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/wms?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的數(shù)據(jù)庫密碼 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml type-aliases-package: com.example.wms.entity這里最少有三個坑。第一url中必須帶serverTimezone參數(shù)否則高版本MySQL驅動會報時區(qū)相關的異常各種奇奇怪怪的時間錯亂問題也會隨之而來。第二MySQL的驅動類名在新老版本中不一樣舊版是com.mysql.jdbc.Driver新版是com.mysql.cj.jdbc.Driver用老配置去連新版驅動會直接報ClassNotFound。第三application.yml里寫的數(shù)據(jù)庫密碼是模板占位符還是實際密碼要分清楚。源碼如果提交到公開倉庫一般會把真實密碼改成你本地要設置的密碼或者用${WMS_DB_PASSWORD}環(huán)境變量占位的方式。你本地運行時需要把這個值改成你自己的MySQL密碼否則啟動會一直報連接拒絕這是新手最容易卡住的地方。5. 本地直接運行的完整操作步驟5.1 環(huán)境準備到底需要哪些工具和版本根據(jù)我的實踐經(jīng)驗一套穩(wěn)妥的組合是這樣的軟件推薦版本說明JDK1.8或11大多數(shù)SpringBoot項目基于Java 8版本太新也可能編譯報錯Maven3.6及以上用IDEA內置Maven也行Node.js14或16或18要看你這邊Vue是哪個版本Vue2一般建議16Vue3建議18MySQL5.7或8.05.7很穩(wěn)8.0要注意默認加密規(guī)則差異IDEA2021以上社區(qū)版就夠用這里有個最常見的版本坑JDK版本太高而項目是老語法寫的編譯會遇到一堆問題。如果你的源碼寫的是Java 8的語法用JDK 17打開可能直接報編譯錯誤。優(yōu)先按照源碼README里注明的版本組合來準備環(huán)境。沒有任何環(huán)境適配能力的直接運行是不存在的所以看到源碼包里帶README先讀它比看代碼事半功倍。5.2 數(shù)據(jù)庫初始化實操從新建庫到執(zhí)行腳本第一步連上你的本地MySQL?？梢杂妹钚幸部梢杂肗avicat如果已有就順手不建議為了跑項目特意去破解工具命令行那幾條命令足夠用。命令行方式創(chuàng)建一個數(shù)據(jù)庫并執(zhí)行腳本mysql -u root -p # 輸入密碼后 source /你的路徑/init.sql;執(zhí)行成功后查看數(shù)據(jù)庫是否建出來了SHOW DATABASES; USE wms; SHOW TABLES;正常情況下你會看到用戶表、物資表、入庫表、領用表等至少五六張表并且可以驗證默認管理員賬號是否存在SELECT * FROM sys_user;這里建議不要修改init.sql里的初始化數(shù)據(jù)。默認管理員賬號一般就是admin密碼可能是admin123或者123456你先拿這個賬號登錄成功之后再進系統(tǒng)到用戶管理里改密碼。直接改腳本容易造成后面的數(shù)據(jù)關聯(lián)問題。5.3 后端項目啟動步驟與日志識別打開IDEAFile - Open選擇server目錄等待Maven把依賴都下載完。下載過程中如果網(wǎng)絡比較慢記得在Maven的settings.xml里配置國內鏡像源比如阿里云鏡像這個細節(jié)能幫你省下大量等待時間。直接找到啟動類就是在com.example.wms包下的xxxApplication類類上標注SpringBootApplication。右鍵運行這個主類控制臺開始刷日志。等到出現(xiàn)類似下面的日志時就說明后端啟動成功了Tomcat started on port(s): 8088 (http) with context path Started WmsApplication in 5.231 seconds看到Started關鍵字的日志后可以先測試一下接口是否通了。瀏覽器訪問一個健康的接口地址比如http://localhost:8088/api/auth/login能返回JSON數(shù)據(jù)或者401之類的響應就說明后端沒問題。如果啟動過程報錯先定位到最頂層的異常原因不要被下面幾百行堆棧嚇到九成以上是你在4.3小結里列出的那幾個原因。5.4 前端項目啟動步驟與瀏覽器訪問打開前端項目同樣用IDEA或者直接在終端里進入ui目錄。首次運行需要安裝依賴npm install如果npm install的速度無法忍受可以采用國內源npm config set registry https://registry.npmmirror.com然后啟動開發(fā)服務器npm run serve看到這樣的日志就說明前端跑通了App running at: - Local: http://localhost:8080/ 編譯成功瀏覽器打開http://localhost:8080正常會跳轉到登錄頁面輸入默認管理員賬號密碼登錄成功后就能看到一個帶側邊欄的物資管理后臺。到這里整套系統(tǒng)就算完全跑起來了。可以在系統(tǒng)里試著創(chuàng)建一條物資分類、錄入一份入庫單、然后發(fā)起一個領用申請把整個流程走一遍你會對這個系統(tǒng)以及它背后的技術架構有一個完整的感知。5.5 前后端聯(lián)調配置核對清單如果頁面打開了但登錄一直轉圈或者提示請求失敗先不要懷疑代碼先檢查聯(lián)調配置。我整理了一份排查清單后端是否已經(jīng)啟動端口是否是8088日志里有沒有Started標記。前端請求的baseURL是否指向正確。開發(fā)環(huán)境一般是通過代理轉發(fā)所以看vue.config.js里devServer.proxy配置是否正確。數(shù)據(jù)庫里的用戶賬號密碼是否真的存在檢查sys_user表內容。瀏覽器F12打開Network面板看登錄請求是否返回了Respones。如果是404檢查后端Controller的路徑和前端api文件里的路徑是否一致。做完這四項檢查90%以上的聯(lián)調問題都能解決。剩下的基本就是代碼本身需要調試的問題了。6. 常見問題與排查技巧實錄6.1 問題速查表上線運行和本地開發(fā)中常見的問題我整理了一張表每個問題基本都遇到過對應的解決方式也是經(jīng)過驗證的現(xiàn)象根本原因排查與解決辦法后端啟動報數(shù)據(jù)庫連接失敗MySQL沒開、密碼錯誤、數(shù)據(jù)庫不存在確認mysql服務已啟動檢查application.yml密碼確認init.sql已執(zhí)行npm install報錯Node版本過高或過低、網(wǎng)絡不通查看報錯提示切換到推薦Node版本換國內npm鏡像源登錄后頁面一直在轉圈前端請求沒到后端確認后端端口啟動成功檢查代理配置用F12看請求是否404頁面能打開但驗證碼不顯示驗證碼接口被攔截器攔截后端加白名單把驗證碼接口排除在登錄攔截之外后端啟動報時區(qū)錯誤MySQL連接串沒加serverTimezone按4.3節(jié)的url加上serverTimezoneAsia/Shanghai前端打包后部署到服務器刷新頁面404前端路由用history模式Nginx配置try_files $uri $uri/ /index.html6.2 幾個值得反復強調的避坑指南第一不要在源碼上直接改數(shù)據(jù)庫密碼并提交到公開倉庫。即使是在學習階段也應該養(yǎng)成把敏感配置從代碼里剝離的習慣。數(shù)據(jù)庫密碼、密鑰這類東西要么放在環(huán)境變量里要么放在獨立的配置文件中并加入gitignore。第二錄入領用單時一定要先驗證庫存夠不夠。后端在扣減庫存前必須做一次判斷當前庫存是否大于等于本次領用數(shù)量。如果不夠直接返回業(yè)務異常庫存不足。這個判斷不能只依賴前端表單校驗因為用戶完全可以繞過前端直接調接口。第三不要輕易刪除歷史出入庫記錄。如果你需要調整某筆錯誤的入庫或領用比較穩(wěn)妥的做法是新增一條與之相反的沖抵記錄比如多入庫了10個就再登記一條出庫10而不是直接delete原始記錄。保留完整的流水是進銷存系統(tǒng)的審計底線一旦刪除后期對賬基本無法挽回。第四做報表查詢的時候盡量不要在頁面加載時把所有數(shù)據(jù)全查出來。數(shù)據(jù)量小的時候感覺不出來等到幾十萬條記錄的時候瀏覽器會直接卡死。無論是庫存列表還是出入庫明細都要分頁查詢后端用MyBatis-Plus自帶的分頁插件就行。表格分頁在前端是標配但很多人初學時會漏掉這一步。6.3 接手陌生源碼時的快速上手方法論如果這套源碼不是你自己從零寫的拿到手的第一時間不要急著跑代碼。我自己的習慣是先看三樣東西README文件、init.sql腳本和application.yml配置。README會告訴你作者聲明的環(huán)境要求和運行步驟init.sql讓你知道數(shù)據(jù)庫里有哪些表和初始數(shù)據(jù)application.yml讓你了解端口、數(shù)據(jù)源和可能的外部依賴。這三樣東西看完你心里對項目的全貌就有了七成把握。接下來再去看代碼優(yōu)先看Controller層把所有接口在腦子里過一遍知道這個系統(tǒng)提供了哪些能力。然后再看Service層把核心業(yè)務邏輯入庫、庫存扣減整理一遍。最后再看前端頁面長什么樣和接口一一對應。這個順序是從外到內的比直接一頭扎進細節(jié)要高效得多。7. 這套源碼后續(xù)還能怎么擴展這套系統(tǒng)當前的功能已經(jīng)能解決日常物資管理需求但距離大型企業(yè)級系統(tǒng)還有一段路。如果后面有時間我會在這個基礎上逐步做一些擴展。給幾個我看好且實踐過的方向供拿到源碼的朋友參考。第一個方向是引入對象存儲來做附件管理。現(xiàn)在的物資系統(tǒng)里入庫單常常需要關聯(lián)采購合同、質檢報告、物資照片這些附件。這些二進制文件放在數(shù)據(jù)庫里不合適最有性價比的方式是接入MinIO或者云對象存儲。把附件的訪問路徑存到數(shù)據(jù)庫文件本身放到對象存儲這是企業(yè)系統(tǒng)的常規(guī)操作。庫表設計上也只需要增加附件表、在入庫單主表加一個附件關聯(lián)字段。第二個方向是增加消息通知能力。當員工提交了領用申請管理員需要及時審批目前如果管理員不在系統(tǒng)里這個申請就晾在那里。接入消息通知之后申請?zhí)峤粫r自動給管理員推送一個站內信或者企業(yè)微信消息管理效率會提升很多。極簡的情況下可以用WebSocket做站內通知不需要引入完整的工作流引擎。第三個方向是報表增強。當前系統(tǒng)有基本的出入庫匯總但業(yè)務負責人往往需要看到更多維度的數(shù)據(jù)一個月內各分類物資的領取趨勢、不同部門或員工領用物資的排行、庫存周轉率等。這些場景非常適合接ECharts圖表庫前端畫折線圖、柱狀圖、餅圖后端寫對應的分組聚合SQL。視覺效果一旦做出來系統(tǒng)的完成度會有質的提升。第四個方向是接口文檔自動化。如果你準備把這個項目作為多人協(xié)作的起點手動維護接口文檔很容易過時。建議接入Knife4j或者SpringDoc讓后端啟動后自動生成接口文檔頁面前端照著文檔聯(lián)調減少溝通成本。最后說點實操中的個人體會這套系統(tǒng)我前后帶過不少同學跑通過最大的坑從來都不是代碼本身的邏輯而是環(huán)境不一致帶來的各種幺蛾子。比如有人MySQL用了8.0有人用了5.7兩個版本在驅動連接時表現(xiàn)就是不一樣再比如有人Node裝的是20跑Vue2老項目直接報OpenSSL錯誤換成Node16就好了。所以真的建議拿到源碼后第一步先看README把環(huán)境對齊了再動手很多源碼有問題跑不起來的結論其實都是環(huán)境問題。另外很多初學者拿到這種源碼之后喜歡到處復制代碼把每個文件都打開一遍看不懂就慌。實際上你不用急著全部看懂先把系統(tǒng)跑起來從用戶視角在界面上點一遍對系統(tǒng)有了真實感受之后再帶著這個功能是怎么實現(xiàn)的這樣的問題去看代碼理解效率會高很多。這套物資綜合管理系統(tǒng)拿來練手還是做基礎二次開發(fā)都很合適。后面我會繼續(xù)整理一些針對性更強的拆解文章比如把某一條入庫流程從前端到后端到數(shù)據(jù)庫的完整數(shù)據(jù)流串講一遍或者講講報表模塊里的SQL優(yōu)化有興趣的朋友可以繼續(xù)關注。