1. 项目背景与整体思路1.1 为什么做前后端分离的应急物资管理系统应急物资管理系统说白了就是把物资的“进、出、存、查”管明白。这类系统在很多学校毕业设计、企业培训项目里非常常见但大多数资料还停留在JSPServlet或者单体框架阶段。我最早也接手过一套老系统里面所有页面都是服务端渲染改一个查询逻辑要重启服务给管理员配个权限要翻大半天代码。后来决定用前后端分离重写才算把开发节奏和部署方式理顺。前后端分离的核心思路是后端只负责接口和数据前端通过HTTP请求拿数据并负责渲染页面。对于应急物资管理这种场景好处非常明显一是前端可以集中精力做表单、表格、数据展示后端专注业务逻辑和SQL优化二是后续如果需要换手机端或者大屏展示直接复用后端接口就行三是部署时可以分别扩展比如把静态资源交给Nginx后端服务独立运行互不拖累。这篇文章适合正在学习SpringBoot和Vue的开发者也适合准备做毕业设计或实训项目的同学。我会从数据库设计一直聊到部署上线把踩过的坑一并写出来按着做就能跑起来。1.2 技术选型为什么是SpringBootVueMyBatisMySQL这个组合现在几乎是后台管理系统的“默认套餐”但选型背后是有理由的。SpringBoot负责快速搭建工程它自动装配的特性让配置量大幅减少配合内嵌Tomcat本地启动一个类就行不用单独部署容器。Vue作为前端框架渐进式、组件化适合从简单页面扩展到权限管理、数据统计这类复杂交互。MyBatis的优势在于SQL可控应急物资的库存查询往往有多表关联、条件动态拼接用MyBatis XML写起来直观也方便后续DBA接手优化。MySQL就不用多说了免费、稳定、社区案例多招人也好招。为什么不推荐在这个项目里一上来就用太重的东西比如微服务、Redis、MQ。应急物资管理系统的核心业务量级并不大单机部署完全足够。技术栈越简单越容易把业务逻辑讲清楚也越容易让新手掌握。如果你搜过“SpringBootVue前后端分离”相关关键词会发现大量实战教程都是这个组合说明它的通用性和学习路径已经非常成熟。2. 系统核心模块与数据库设计2.1 功能模块拆解拿到需求后我先把功能拆成六个模块系统登录与用户管理、物资分类管理、物资基础信息管理、库存管理、出入库记录、统计预警。用户权限不一定要做得很重但至少要有管理员和普通操作员的区别避免任何人登录就能改库存。具体来说物资分类用来维护一级分类、二级分类比如“医疗物资”“救援装备”“生活保障”。物资基础信息维护物资名称、规格型号、单位、保质期、存放仓库等。库存管理是最核心的部分要能看到每个仓库、每个物资的当前库存量并支持入库和出库操作。出入库记录则保存每一笔流水方便追溯。统计预警用于设置库存上下限低于下限时在首页弹出提醒。这些功能组合起来就构成一个完整的业务闭环。这里有个设计细节不要在每次操作时直接改总库存却不留凭证。正确做法是先写一条出入库流水然后根据流水更新库存这样出现问题可以反查。很多初版系统都栽在“直接改数”这个坑上。2.2 数据库表设计要点我设计的核心表包括这几张sys_user用户表、category分类表、material_info物资信息表、warehouse仓库表、stock库存表、stock_record出入库流水表、alarm_config预警配置表。字段不要贪多够用就行。以库存表stock为例最需要关注的字段是material_id和warehouse_id这两个字段要建联合唯一索引防止同一个物资在同一个仓库出现多条库存记录。如果出现两条库存统计就会莫名翻倍。另一个容易忽略的是decimal类型的精度库存数量一般用decimal(12,2)别用float或double否则累加多次后会出现0.001这种误差。物资信息表material_info里我建议加上bar_code、specification、unit等字段这些在实际盘点时非常有用。预警配置表alarm_config不需要单独一张表去关联每个物资直接在material_info里加low_stock和high_stock字段就够了减少关联查询。具体建表SQL示例大致是这样CREATE TABLE material_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 物资名称, spec VARCHAR(100) COMMENT 规格型号, unit VARCHAR(20) COMMENT 计量单位, category_id BIGINT COMMENT 分类ID, low_stock DECIMAL(12,2) DEFAULT 0 COMMENT 库存下限, high_stock DECIMAL(12,2) DEFAULT 99999 COMMENT 库存上限, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT物资信息表;注意这里统一使用utf8mb4而不是utf8。utf8mb4兼容emoji和生僻字避免后续导入数据报“Incorrect string value”错误。2.3 MyBatis与MySQL的实操配合数据库表设计好之后就要面对MyBatis的编码细节。第一个要点是开启驼峰映射在application.yml里配置map-underscore-to-camel-case: true这样数据库字段material_id能自动映射到Java实体类的materialId不用写一堆resultMap。不过如果你SQL中起了别名比如select u.user_name as userName记得保持一致。第二个要点是动态SQL。库存查询通常不是单条件用户可能只输入物资名称也可能同时选择分类和仓库。这时候就用MyBatis的 标签拼条件注意不能用 包裹foreach循环导致缺少前缀的坑。一个常见的模糊查询写法是SELECT m.id, m.name, w.warehouse_name, s.quantity FROM stock s LEFT JOIN material_info m ON s.material_id m.id LEFT JOIN warehouse w ON s.warehouse_id w.id where if testname ! null and name ! AND m.name LIKE CONCAT(%, #{name}, %) /if if testwarehouseId ! null AND s.warehouse_id #{warehouseId} /if /where注意LIKE不要直接传“%”#{name}“%”因为在某些数据库驱动下会报参数数量不对推荐用CONCAT。另外所有查询条件都使用#{}预编译避免SQL注入。这是老生常谈但我在代码评审里还是经常看到有人直接把参数拼进SQL风险非常大。3. 后端SpringBoot核心实现要点3.1 项目结构与接口规划SpringBoot项目结构我习惯按功能分包controller、service、mapper、entity、common。common里放统一返回值、异常处理器、工具类。不要按三层架构把类堆在一层否则后期维护很痛苦。接口规划上我统一返回Result对象结构是code、message、data。代码大概类似public class ResultT { private Integer code; private String message; private T data; // 静态方法 success/error }前端只看code判断逻辑200是成功400参数错误500服务器错误。业务状态码另外定义比如库存量不足返回510。这样前后端联调的时候接口说明表一目了然。以库存模块为例我规划了这样几组接口方法路径说明GET/api/stock/list分页查询库存列表POST/api/stock/in入库操作POST/api/stock/out出库操作GET/api/stock/record出入库流水GET/api/stock/warn库存预警列表接口路径统一以/api开头方便Nginx代理配置。后面部署时你会发现如果前端和后端接口路径交叉混乱代理规则会写得很痛苦。3.2 MyBatis分页插件与动态SQL分页查询是后台系统的刚需。用MyBatis时最省事的方案是引入PageHelper插件。在pom.xml里加依赖后在service层查询前调用PageHelper.startPage(pageNum, pageSize)紧接着的第一条查询会默认带上LIMIT。注意一个坑startPage之后如果有多条SQL插件只对第一条Select生效所以不要把无关的赋值查询放在分页查询前面。PageHelper还需要在yml里配置reasonable: true意思是当页码超过总页数时自动回退到合理页码避免前端翻到空页。分页返回结果建议封装成PageInfo里面有total、pageNum、pageSize、list等字段前端直接拿list渲染表格拿total渲染分页组件。如果你不想引入插件纯手写LIMIT也可以但要注意COUNT查询和LIST查询条件必须一致否则分页总数不对。很多人在这个点上翻车搜索条件变了总条数没变列表页码就乱了。3.3 统一异常处理与全局过滤器SpringBoot项目的健壮性很大程度取决于异常处理是否统一。我统一用RestControllerAdvice加ExceptionHandler处理业务异常和兜底异常。业务异常类可以自行定义在Service层判断到库存不足、参数缺失时直接抛出Controller层就不需要写一堆try-catch。兜底Exception处理则把未知错误日志打到日志文件里返回code500给前端不要把堆栈信息直接暴露给调用方。除了异常处理我还加了一个全局过滤器来处理请求体里的特殊字符。比如用户把物资名称输入成“ ”如果不做处理存进数据库再回显就是XSS风险。过滤器的主要逻辑是读取请求流做统一转义和非法字符过滤。注意处理POST请求体时需要重写HttpServletRequestWrapper否则流只能读一次。这个包装类的代码网上有很多成熟方案但一定要在过滤器中排除文件上传接口否则会把二进制内容也过滤了导致上传文件损坏。4. 前端Vue核心实现要点4.1 项目初始化与路由配置前端部分我用的Vue CLI创建项目版本选择2.x还是3.x取决于团队熟悉度。但核心经验是先规划好目录结构再开始写页面。我的目录大致是views页面、components通用组件、router路由、api请求接口、store状态管理、utils工具类。路由配置一定要用懒加载import的时候写成const StockList () import(/views/stock/StockList.vue)这样首屏体积小很多。如果搜过“vue路由参数”很多人会遇到传参后在刷新页面时参数丢失的问题解决办法是用params传参后刷新会丢失建议敏感数据用query传参或者用本地存储兜底但要注意登录令牌不要放在localStorage的明文里。路由守卫也必须写上用来做登录校验。在router.beforeEach里判断是否存在token没有token就跳转到登录页。这一步看着简单但对整个系统的安全性非常重要别只在前端按钮上做权限判断。4.2 前后端联调axios与跨域处理axios封装是整个前后端联调的关键。我一般创建service.js统一设置baseURL和请求拦截器。请求拦截器里携带token响应拦截器里统一处理code和token过期。代码大概这样import axios from axios const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) service.interceptors.request.use(config { config.headers[Authorization] localStorage.getItem(token) return config }) service.interceptors.response.use(res { const code res.data.code if (code 401) { router.push(/login) } return res.data })关于跨域开发环境我推荐用Vue的proxy配置在vue.config.js里把/api代理到后端地址。生产环境则用Nginx反向代理不用在后端接口上频繁加CrossOrigin。这样遇到跨域问题就只在部署层解决后端代码干净很多。4.3 组件化与状态管理页面写多了你会发现很多表格、弹窗、查询表单是重复的。我会把查询表单和分页表格抽成通用组件比如SearchForm、BaseTable。但要注意组件抽得太细会让联调变复杂一开始可以先按页面粒度写第二次重复时再抽不要过早设计。状态管理方面如果只是保存用户名、登录状态用Vuex或Pinia都够。应急物资管理系统里真正需要共享的状态一般是登录用户信息和菜单权限。我建议只把这两类信息放store列表数据不要放store否则刷新页面后需要重新同步反而多出bug。组件之间的通信优先用props和事件跨多层的场景才考虑全局状态避免状态流难以追踪。5. 完整部署流程与实操记录5.1 环境准备JDK、Node、MySQL部署前先把环境准备好。后端需要JDK 1.8或17推荐用JDK1.8配SpringBoot 2.x网上资料最多遇到问题也好查前端需要Node.js 14以上数据库用MySQL 5.7或8.0。如果服务器是Linux系统安装MySQL的方式会稍微不同Ubuntu用aptCentOS用yum或dnf但核心步骤都是启动服务、设置root密码、开放对应端口。安装MySQL时有两个容易踩的坑第一是root密码设置后要记得把密码写在小本子上默认的密码校验策略选简单模式或后期改第二是MySQL 8.0的时区问题连接串里要加serverTimezoneAsia/Shanghai否则报错。数据库准备好后把之前设计的建表SQL和执行初始数据的SQL一起跑一遍。我建议用命令行source或Native连接工具执行别在可视化工具里直接复制粘贴建多个表因为字符集配置可能不一致。建完表后用一条简单的select count(*) from material_info验证权限和编码。5.2 后端打包部署到TomcatSpringBoot有两种部署姿势打成可执行Jar直接跑或者打成War包放进Tomcat。如果只是单机部署我强烈推荐Jar包方式Tomcat都可以不单独装因为SpringBoot内嵌了Tomcat。打包命令很简单mvn clean package -Dmaven.test.skiptrue在target目录下会生成一个jar文件然后执行java -jar emergency-material-system.jar启动日志出现“Started Application in x seconds”就说明成功。如果需要后台运行用nohup命令并指定日志文件。要注意生产环境不要直接使用root用户跑服务创建一个普通用户更安全。端口默认8080如果服务器上已经占用8080可以在启动命令里加上--server.port18080或者改application.yml。如果你所在的项目组要求必须打War包那需要把SpringBoot启动类继承SpringBootServletInitializer并且修改pom.xml里的packaging为war同时把tomcat依赖设为provided。这种做法适合交付给运维统一部署但本地调试不如Jar包方便。5.3 前端打包与Nginx部署前端在本地开发完成后执行npm run build生成dist目录。这里要强调dist目录是一堆静态文件不能直接双击打开看效果必须放在Web服务器里。最常用的是Nginx。Nginx配置核心是“静态文件由Nginx处理API请求代理到后端”。一个精简配置如下server { listen 80; server_name your-server-ip; root /usr/share/nginx/html/emergency; index index.html; location /api/ { proxy_pass http://127.0.0.1:18080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }注意location /api/的proxy_pass路径结尾是否带斜杠决定转发时是否保留/api前缀。如果后端接口上下文恰好是/api那proxy_pass http://127.0.0.1:18080;即可如果写成http://127.0.0.1:18080/会把/api去掉导致404。这是部署中最常见的坑我每次都要检查一遍。前端路由使用history模式时Nginx必须配置try_files $uri $uri/ /index.html否则刷新某个子页面会报404。如果不想改Nginx也可以把Vue路由改成hash模式但URL上会多一个#看你怎么取舍。5.4 联调验证部署完成后接下来是一套完整的冒烟测试流程。先访问登录页输入管理员账号密码确认能拿到token并跳转到首页。然后依次测试分类管理的新增和修改物资信息的录入再测试入库操作到库存列表中确认数量增加最后出库操作观察数量减少并生成流水记录。我一般还会测试一遍异常流程比如把库存出库数量大于当前库存看是否返回友好提示“库存不足”关闭后端服务后访问前端页面看是否提示“请求失败”而不是白屏或无限loading。这些看似不起眼的小点是系统是否“可用”的重要标准。联调时如果发现数据没有更新第一反应去看Nginx的error.log和后端日志不要第一时间怀疑代码逻辑。6. 常见问题与排查技巧6.1 启动报错速查表我把这个项目部署运维中高频出现的问题整理成一张表碰到类似情况可以直接照方抓药现象可能原因解决办法后端启动报“Port 8080 was already in use”端口被占用使用netstat -ano查进程改端口或kill进程MySQL连接报“Access denied for user”密码错误或权限不足检查用户名密码grant授权远程访问前端请求接口报“Network Error”跨域或后端未启动先curl接口地址确认后端可访问页面刷新后404Nginx未配置history回退加try_files $uri $uri/ /index.html中文乱码数据库字符集不是utf8mb4建库建表统一utf8mb4连接串加characterEncodingutf8PageHelper分页不生效startPage后执行了多余查询确保startPage后面紧接需要分页的查询这里要补充一个排查顺序先看日志再看网络最后才怀疑代码。很多人习惯一上来就开IDE调试其实线上环境根本没法调试只能靠日志。建议后端启动时保留应用日志文件前端用浏览器开发者工具的Network面板看请求响应90%的问题都能在这两步里定位。6.2 部署踩坑实录第一个坑是数据库密码里有特殊字符。比如密码写成123456abc在application.yml里如果直接用url: jdbc:mysql://localhost:3306/emergency?password123456abcYAML会解析混乱。解决办法是对密码加引号或者把密码放到环境变量里引用。第二个坑是跨域问题表现很迷惑。前端请求登录接口返回200但拿不到data打开了浏览器开发者工具才发现响应体为空这是因为CORS拦截在浏览器端。当时我在后端加了一堆CrossOrigin还是有几个接口报错最后改为Nginx代理才彻底解决。第三个坑是MyBatis返回的实体类字段全部为null。原因是数据库中字段是下划线命名而实体里是驼峰命名并且配置没有开启map-underscore-to-camel-case。这个问题经常在别人部署你的项目时出现因为他们很可能用了不同的application.yml配置。第四个坑是前端打包后接口地址写死了。在开发环境baseURL是localhost:8080打包到生产后仍然请求localhost导致服务器上无法访问API。正确做法是用环境变量区分开发和生产环境在.env.production里把baseURL设为/api然后交给Nginx代理。6.3 性能与安全优化心得系统能跑起来只是第一步上线前我还会做几件小事。索引方面stock_record表的material_id和warehouse_id都要建索引因为明细查询和报表统计会高频用到。material_info表的name字段如果经常作为查询条件也建议建一个普通索引但不要滥用索引否则插入性能会下降。连接池方面如果用的是HikariCP建议在配置里设一下maximum-pool-size默认10对这个小系统够用没必要拉满。SQL日志在本地可以开启上线前关掉防止把参数全部打印到日志文件里造成信息泄露。密码存储一定用BCrypt加密不要明文存。登录接口需要加简单的验证码或登录失败次数限制防止暴力破解。MyBatis自带一级缓存和二级缓存很多人喜欢把二级缓存打开提升查询性能。但在应急物资系统里物资库存会频繁更新二级缓存很容易出现“查不到最新数据”的问题反而不如不开。我只在物资分类这类很少变更的查询上用了CacheNamespace其他高频查询都靠MySQL和索引本身这样逻辑更可控。还有一个细节上线前检查所有接口是否返回了多余的业务数据。比如用户列表如果包含用户的密码字段即使加密过也不建议返回给前端。这个可以在实体类上使用JsonIgnore或者写专门的VO虽然多写几步但对安全非常重要。最后数据库务必定期备份。应急物资系统的数据量虽然不大但它承担的是库存台账的完整性。我习惯每天凌晨用mysqldump做全量备份保留最近7天备份文件。等到真出了问题你会发现这条备份命令是整篇文章里最值钱的部分。