企业官网建设流程全解析

简介：这是一套基于SpringBoot后端与Vue前端的B/S架构库存管理系统完整源码，面向计算机相关专业在校学生、教师及初级开发人员，用于课程设计、毕业设计参考或全栈开发技能实践。系统功能完整、运行稳定，涵盖商品管理、入库出库、库存预警等核心业务模块，代码含详细中文注释，便于理解MVC分层逻辑与前后端交互机制。资源包共431个文件，包含117个Java后端类、60个Vue组件、17个JS脚本、161个SVG图标及配套配置文件（yml/xml）、样式文件（css/scss）和启动脚本（bat），整体压缩包21.16MB，结构清晰、模块解耦度高。已有94人学习下载，配套必读文档说明部署流程与调试要点，可直接导入IDE运行，支持二次开发与功能扩展，是掌握SpringBoot+Vue工程化开发的实用参考样本。 做库存管理系统这件事，我前前后后接触过不下十套开源项目，但能让我愿意反复打开源码去读的并不多。这套基于Springboot和Vue的库存管理系统源码，算是其中比较难得的一套——代码完整、中文注释到位、前后端分离结构清晰，拿来学习、改造成毕业设计、或者直接作为企业内部工具的原型，都挺合适。这篇文章我不打算只给你讲"这个项目有哪些功能"，而是想把整套源码从设计思路、核心实现、环境搭建到二次开发、踩坑记录，全方位拆开讲透，让你拿到源码之后不是傻乎乎地跑起来就完事，而是能真正看懂每一层代码在干什么、改了哪里会出什么问题、想加功能该往哪个方向下手。

这套项目适合谁？如果你是Java后端刚学完Springboot、想找一个真实项目练手的前端开发，或者正在准备毕业设计的计算机专业学生，又或者公司里需要一个轻量库存管理系统但预算有限的小团队，我都建议你把这篇文章读完。即使你现在拿到的是别人打包好的源码，读完这篇，你也能比网上大多数"下载即跑"的教程多理解几个层面。

1. 项目整体设计与技术选型思路

1.1 为什么是Springboot+Vue这套组合

先说选型。你看到的这个标题是"基于Springboot和Vue的库存管理系统"，很多人会觉得这就是个标配组合、没啥好讲的。但真要认真拆解，这个选型背后是有道理的。

Springboot在Java后端领域几乎已经成了事实标准。它解决了传统Spring项目里繁琐的XML配置问题，内嵌Tomcat，打一个jar包就能跑，配合Spring MVC做接口开发效率非常高。更重要的是，Springboot的生态太成熟了，无论是数据库访问用MyBatis-Plus还是Spring Data JPA，权限认证用Spring Security还是Shiro，缓存用Redis，都有非常成熟的整合方案。这意味着你拿这套源码去改造成本很低，网上能找到大量资料。

前端选Vue而不是React或者Angular，核心原因在于Vue的上手曲线更平缓，模板语法对后端出身、对前端不太熟悉的开发者特别友好。Vue的双向数据绑定机制，对于表单密集型的管理系统来说，写起来简直不要太舒服——你在输入框里改个值，页面上其他关联的逻辑自动就更新了，完全不用像传统jQuery那样手动操作DOM。

再说回库存管理系统这个业务本身。它本质上是一个典型的CRUD密集型应用，核心逻辑就是商品的增删改查、入库出库单的录入与审核、库存数量的增减与查询。这类系统没有特别复杂的高并发场景（当然如果你要抗住双十一那种量级另说），但对数据一致性要求高，逻辑清晰度要求也高。Springboot + Vue这套前后端分离架构，后端专注业务逻辑和数据处理，前端专注交互和展示，各司其职，正好匹配。

1.2 库存管理系统核心业务模块拆解

一套合格的库存管理系统源码，不管界面长得怎么样，核心业务模块一定是齐全的，不然跑起来你会发现业务流程根本走不通。我在拿到这套源码之后，第一件事就是画了一遍它的功能脑图，这里给你梳理出来：

• 商品管理：商品的增删改查、分类管理、商品编码、规格型号、单位、库存上下限设置
• 入库管理：入库单创建、入库单审核、入库明细记录、供应商信息管理
• 出库管理：出库单创建、出库单审核、出库明细记录、领用人或客户信息管理
• 库存查询：实时库存查询、库存流水查询、库存预警列表
• 报表统计：入库统计、出库统计、库存周转情况、按时间维度的进销存报表
• 系统管理：用户管理、角色管理、菜单权限、操作日志

这套源码比较难得的地方在于，不只是把这些菜单堆上去，而是模块之间有完整的数据流转逻辑。比如商品入库，不是简简单单往商品表里加个数量就完了，而是先创建入库单，再填写入库明细，审核通过后才真正影响库存。这种"单据+明细"的设计，才是实际业务里需要的，而不是课程设计那种点击按钮直接改库存的教学Demo。

1.3 数据库设计要点与表关系

看源码先看数据库，这是我一直以来的习惯。因为代码可以写得绕，数据库表结构直接暴露了系统的核心业务模型。这套库存管理系统的数据库设计，我拆开看过后觉得是比较规范的一套。

核心表大概是这些：

• 商品分类表：维护商品分类层级，parent_id做自关联支持无限级分类
• 商品信息表：存商品名称、编码、规格、单位、分类id、库存上下限、状态等
• 供应商表：入库的来源方
• 客户表：出库的去向方
• 入库单主表：入库单号、供应商、入库日期、操作人、审核状态、备注
• 入库单明细表：关联入库单主表，存商品id、入库数量、单价、金额
• 出库单主表：结构类似入库单主表，关联客户或领用人
• 出库单明细表：关联出库单主表，存商品id、出库数量
• 库存表：商品id、当前库存数量，作为冗余设计的实时库存快照
• 库存流水表：每一次库存变动的历史记录，入库、出库、盘点调整都记一笔
• 用户表和角色表：后台登录用户与权限角色

表之间的关键关系是：入库单主表一对多入库单明细表，明细表再关联商品表；库存表是一张冗余表，它的数值由入库和出库单据审核时累计计算得出；库存流水表则负责追溯每次库存变动的前后值，方便排查问题。

这里有个设计细节值得留意：为什么已经有了入库明细和出库明细，还要单独存一张库存表？这是典型的以空间换时间的思路。如果没有库存表，每次查询实时库存都要聚合所有入库单明细和出库单明细，数据量大了以后查询效率会非常差。单独维护一张库存表，虽然增加了更新逻辑（每次出入库审核时要同步更新），但查询时直接查库存表就行，速度极快。这也是很多实际生产系统的通用做法。

2. 核心功能模块解析与实现细节

2.1 商品管理与分类设计：从一张表看代码功底

商品管理是所有库存系统的基石，这个模块做得好不好，直接决定后面所有功能好不好写。这套源码里，商品分类用了自关联的无限级分类方案，就是在分类表里设计一个parent_id字段，顶级分类的parent_id为0，子分类的parent_id指向父分类的id。这样不需要固定层级，想分三级、四级都行。

在实际代码中，商品信息的增删改查是标准的Springboot三层结构：Controller接收前端请求，Service处理业务逻辑，Mapper操作数据库。商品编码这个字段建议你重点关注，好的系统里商品编码往往是唯一索引，而且编码规则有讲究，比如"类别前缀+流水号"的格式。这套源码里的商品编码是手输的，如果你要二次开发，可以考虑改成自动生成或者支持条码扫描录入，会实用很多。

商品模块里还有一个经常被忽略但很重要的字段：库存上下限。这是后面库存预警功能的数据基础。你在页面上给某个商品设置一个库存下限为10，当库存低于10时，系统就能在预警列表里提醒你补货。代码实现上，预警查询就是一条SQL：SELECT * FROM goods WHERE stock_quantity <= stock_lower_limit。

从实操角度看，我建议你拿到源码后，先在商品模块上做一次完整的"增删改查"走读：从前端的商品列表页面开始，找到新增商品的弹窗，看表单字段，然后看前端调用的API地址，再到后端Controller中对应的接口，再到Service层的实现，最后到Mapper中的SQL语句。完整走完一遍，你就理解了这个项目的基础运转方式。

2.2 入库、出库、退货流程的状态机设计

入库和出库是这个源码的精华所在，也是最值得仔细读的部分。这套系统采用的是标准的两步走流程：先创建单据，再审核单据。

创建入库单时，系统的状态是"待审核"，此时库存不受任何影响，填错了可以直接修改或删除。审核通过后，状态变为"已审核"，此时才会真正增加库存，同时写入库存流水。这个设计的好处在于，实际业务中入库单经常需要录入员和审核员分开，录入员可以随时修改，但审核通过后数据就不能再动了，保证了操作的严肃性和可追责性。

在代码层面，审核操作的Service方法上可以看到@Transactional事务注解。这个注解非常重要，因为它保证了"检查单据状态+修改库存表+写入库存流水+更新单据状态"这几个操作要么全部成功，要么全部回滚。如果去掉这个注解，一旦中途出错，就会出现库存改了但流水没记、或者单据状态改了但库存没变这类数据不一致的严重问题。

我自己在实际开发里就踩过这个坑，当时是自己的一个系统，忘了加事务注解，结果测试时模拟数据库异常，库存直接错了。排查了大半天才发现是事务问题。所以看这套源码时，重点留意Service层所有写操作的方法上是否都有@Transactional，这不只是规范问题，更是数据安全的基本保障。

2.3 库存预警与报表统计的实现思路

库存预警功能在源码里实现得比较直白，但也足够实用。核心就是一张预警查询的列表页，后端提供一个接口，查询所有当前库存低于下限或高于上限的商品，前端用Vue的el-table展示，再给"库存不足"的行加个红色标注。如果想让预警更主动，可以扩展一个定时任务，比如用Springboot的@Scheduled注解，每天早上9点扫描一次库存表，把库存不足的商品发到管理员邮箱或者企业微信机器人，这就是很实用的二次开发方向。

报表统计这块，源码里提供了按时间范围的入库统计和出库统计。实现方式主要是聚合查询，比如统计某个月每天的入库数量，SQL大致是这样的：

SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS day, SUM(quantity) AS total_quantity FROM inbound_order_detail WHERE create_time BETWEEN #{startTime} AND #{endTime} GROUP BY day ORDER BY day

这类SQL看着简单，但要注意一个容易被坑的地方：日期范围查询的边界问题。如果你传的结束时间是2025-06-30，那这个日期默认是2025-06-30 00:00:00，但数据库里可能存在2025-06-30 10:30:00的数据，结果就是6月30号大部分数据查不到。解决方式很多，最简单的是传结束时间时把日期加一天，然后用<而不是<=；或者直接传2025-06-30 23:59:59。源码里用的哪种，你走读代码时注意看一眼，这也是面试时经常会被问到的细节。

另一个值得扩展的报表方向是"进销存汇总表"，也就是一个商品在某个时间段内，期初库存+入库总量-出库总量=期末库存。这个表在真实业务里是财务对账的刚需。如果源码里没有，建议你自己尝试实现一下，逻辑不复杂，就是几条聚合SQL的组合，但做完你对这套系统的理解会深很多。

2.4 权限设计与登录认证的实现方式

后台管理系统没有权限控制是不行的。这套源码的权限功能采用了基于角色的访问控制模型，也就是RBAC，核心是三张表：用户表、角色表、用户角色关联表。用户属于某个角色，角色拥有某些菜单的访问权限。前端根据登录用户返回的权限列表，决定哪些菜单显示、哪些按钮可用；后端在访问接口时校验当前用户是否有权限，没有就直接返回401或403。

登录认证这块，源码里如果用的方案是JWT，你会发现前端登录成功后会把token存在localStorage或sessionStorage里，之后每次请求在axios拦截器里统一把token加到请求头中。后端的拦截器或过滤器会解析token，取出用户信息放入当前线程上下文中，方便后续业务逻辑获取当前操作人。

如果源码里使用的是Session方案，则是保存在服务端，前端靠Cookie保持会话。两种方案各有优劣：JWT天然适合前后端分离和分布式部署，但token一旦签发，在过期之前无法主动失效，不适合做"强制下线"这类操作；Session则好控制，但多实例部署时要做Session共享，比较麻烦。

这里建议你好好看一下源码里的登录逻辑，然后把密码加密方式也一起看了。正常的项目密码必须加密存储，绝不能明文入库。BCrypt是当前比较推荐的方式，因为每次加密的盐是随机的，即使是同一个密码，每次加密结果也不同，安全性远高于MD5或SHA这类摘要算法。如果这套源码里用的是MD5，那你在二次开发时最好升级成BCrypt。

3. 项目跑起来：环境配置与部署实操

3.1 后端环境搭建与Springboot配置细节

很多人拿到源码卡在第一步：环境跑不起来。这里我把整套环境搭建的过程写清楚，你照着做基本不会出问题。

先准备基础工具链。JDK用1.8或11都是安全的，Maven用3.6以上版本，IDE用IDEA。数据库用MySQL 5.7或8.0都可以，注意MySQL 8.0的驱动配置和5.7略有不同，8.0的驱动类名是com.mysql.cj.jdbc.Driver，而且URL里要加上serverTimezone=Asia/Shanghai，否则会报时区相关的错误。

打开源码中的application.yml，重点看这几项配置：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/inventory_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456

数据库连接串里的characterEncoding=utf8很重要，不加的话，数据库里如果有中文数据，查询出来极有可能乱码。这一点在源码里基本都会处理，但你如果是自己新建数据库，千万记得要把数据库本身的字符集设置成utf8mb4，因为utf8mb4比utf8更完整，能存emoji，也能兼容绝大多数中文字符。

MyBatis-Plus相关的配置也建议留意。源码里如果使用了MyBatis-Plus，application.yml里通常会配置mapper-location和逻辑删除配置：

mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

逻辑删除是个好习惯，就是不真正从数据库删除记录，而是打一个标记位。这样做的最大好处是数据可追溯，比如一个商品被误删了，还能找回来；坏处是所有查询都要自动带上deleted = 0的条件，MyBatis-Plus的@TableLogic注解可以帮你在底层自动处理，但如果你写了自定义SQL，别忘记手动加条件。

配置改完之后，先跑一下项目里提供的SQL脚本，把数据库表结构和初始数据导入。建议用Navicat或者命令行source方式导入，导入完成后刷新一下数据库，确认所有表都建出来了，再启动后端。启动成功的标志是控制台出现"Started Application in xx seconds"这样的日志，或者Tomcat started on port 8080，访问http://localhost:8080能看到接口响应。

3.2 前端Vue项目初始化与接口对接容易出现的问题

前端部分需要先确认Node.js环境。我这里强烈建议使用Node 14到16的版本，不要一上来就装最新的Node 20甚至更高。因为Vue2项目在老版本Node下兼容性最好，新版本Node可能会导致node-sass编译失败、或者openssl相关的报错，这些都是非常经典的坑。

在Vue项目目录下，依次执行：

npm install npm run dev

如果npm install过程中报错，先看是不是node-sass的问题。解决办法是把package.json里的node-sass换成sass，或者装node-sass之前先把npm的源切到国内镜像，这样下载二进制文件会顺利很多：

npm config set registry https://registry.npmmirror.com

前端和后端的接口对接，核心是一个叫vue.config.js的配置。里面通常会有一段devServer配置：

module.exports = { devServer: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

这段配置的意思是，前端跑在3000端口，当浏览器里请求/api/xxx接口时，devServer会把请求转发到后端的8080端口。这样做的好处是避免了跨域问题——因为浏览器的同源策略会拦截从3000端口直接请求8080端口的接口，但通过devServer代理之后，浏览器看到的只是同一个源下的请求，就不会跨域了。

如果你在源码里看到前端代码请求的URL是/api/inbound/list这种，而后端Controller的路径是/inbound/list，那你就该知道有个地方做了路径重写。通常在vue.config.js里会有pathRewrite把/api前缀去掉，或者在axios封装里加的baseURL。这个细节看懂了，前端接口连不通的问题就解决了一大半。

3.3 关键代码走读：以入库单审核为例打通全链路

我选择入库单审核这个场景，是因为它是贯穿前后端最完整的业务链路。从用户点击"审核"按钮，到库存真正增加，每一步都有明确的意义。走读这个流程，你基本就能摸清这套源码的全部套路。

前端部分，找到入库管理页面里的审核按钮，Vue代码一般是这样的：

<el-button type="success" size="mini" @click="handleAudit(row)" >审核</el-button>

点击按钮后触发handleAudit方法，方法里调用封装的API函数，比如auditInboundOrder(row.id)，然后通过axios向后端发送PUT或POST请求。请求成功后，前端刷新列表数据，让用户看到这张单据的状态从"待审核"变成了"已审核"。

后端部分，Controller层接收请求后，调用Service层的审核方法。Service层是这个流程的核心，大致逻辑是：

@Transactional public void auditInbound(Long orderId) { // 1. 查询入库单，检查是否存在以及状态是否为待审核 InboundOrder order = inboundOrderMapper.selectById(orderId); if (order == null) { throw new BusinessException("入库单不存在"); } if (!"PENDING".equals(order.getStatus())) { throw new BusinessException("当前状态不能审核"); } // 2. 查询入库单明细列表 List<InboundOrderDetail> details = inboundOrderDetailMapper .selectList(new LambdaQueryWrapper<InboundOrderDetail>() .eq(InboundOrderDetail::getOrderId, orderId)); // 3. 遍历明细，逐条更新库存表 for (InboundOrderDetail detail : details) { Goods goods = goodsMapper.selectById(detail.getGoodsId()); goods.setStockQuantity(goods.getStockQuantity() + detail.getQuantity()); goodsMapper.updateById(goods); // 4. 写入库存流水 StockRecord record = new StockRecord(); record.setGoodsId(detail.getGoodsId()); record.setChangeType("INBOUND"); record.setChangeQuantity(detail.getQuantity()); record.setBeforeQuantity(goods.getStockQuantity() - detail.getQuantity()); record.setAfterQuantity(goods.getStockQuantity()); stockRecordMapper.insert(record); } // 5. 更新入库单状态 order.setStatus("APPROVED"); inboundOrderMapper.updateById(order); }

这段代码里有几个细节我要特别强调。第一，方法上的@Transactional必不可少，它保证了整个审核过程要么全部成功，要么全部回滚。第二，第2步和第3步之间，其实存在一个并发问题：如果两个请求同时审核同一个入库单，即使有事务，也可能会重复加库存。解决方式是在查询入库单时加上行锁，也就是SELECT ... FOR UPDATE，或者用乐观锁版本号控制。很多源码在处理这个场景时都只做了事务，没做并发控制，你二次开发时如果能补上这一点，会是一个很亮眼的加分项。第三，流水表记录了变动前后的库存值，这在实际排查问题的时候价值极高——任何库存对不上账的情况，都可以通过流水表回溯是哪个时间点、哪张单据导致的。

3.4 从源码到可演示项目的完整落地流程

如果你是想把这个项目跑起来，作为一种演示或答辩用途，我给你一个经过验证的完整流程，按这个顺序操作，基本能一次性跑通。

1. 导入数据库：用Navicat或命令行，执行源码中的SQL脚本，建库建表插入初始数据。
2. 修改后端配置：在application.yml里改数据库名、用户名、密码，确认端口未被占用。
3. 启动后端：用IDEA打开后端项目，等待Maven下载依赖完成后，直接运行主启动类。看到端口启动日志后，可以在浏览器访问一个简单的接口来验证，比如http://localhost:8080/api/user/list，有JSON返回就说明OK。
4. 修改前端配置：在vue.config.js里确认代理配置正确，target指向后端地址。
5. 启动前端：在终端进入前端目录，执行npm install，然后npm run dev，等编译完成。
6. 登录系统：浏览器访问http://localhost:3000，使用源码提供的初始账号密码登录，通常会是admin/admin123之类，具体以SQL脚本里的初始数据为准。

整个流程走下来，顺利的话大概需要半小时左右。如果你卡在依赖下载这一步，绝大部分原因是网络问题，切换npm镜像和Maven镜像基本都能解决。Maven的镜像配置在~/.m2/settings.xml里，加上阿里云镜像，下载速度能快好几倍。

4. 源码阅读与二次开发的实用建议

4.1 读这套源码的正确打开方式

很多初学者拿到源码第一反应是"先跑起来"，跑起来之后就开始迷茫：接下来看什么呢？这里我分享一个我多年来读开源项目的顺序，特别适合这种中小型管理系统。

第一步，先读数据库表结构。把每张表的字段过一遍，搞清楚表之间的关系。你可以直接用Navicat的"模型"功能生成ER图，实体关系一目了然。理解了数据模型，你就理解了系统的核心骨架。

第二步，读接口文档。如果源码里有Swagger配置，启动项目后访问http://localhost:8080/swagger-ui.html，可以看到所有接口的清单。逐个看一遍接口的URL、入参、出参，你就能知道系统对外提供了哪些能力。如果没有Swagger，就去Controller层把所有@RequestMapping注解扫一遍。

第三步，读Service层的业务逻辑。这是最花时间但也是最有收获的一步。重点看事务注解、异常处理、状态流转判断，这些是业务逻辑的精华。

第四步，回到前端，找一个完整的页面，从el-table的列表渲染，到查询表单的提交，到新增弹窗的字段校验，最后到调用API的封装，整条链路串一遍。这个过程中你会学到很多Vue实际项目中的规范写法，比如组件封装的粒度、api模块的拆分方式、状态管理的使用场景。

4.2 高频二次开发点：加批次、多仓库、条码和导入导出

不管是做毕业设计还是真实业务，大多数人拿到这套源码后都会想加一些功能。根据我做过的类似项目经验，以下几个改动方向是最常见、也最容易出效果的。

批次管理。现在的商品表如果只有一个库存数量字段，是无法区分同一商品不同批次的。如果要支持批次，需要新增批次表，入库单明细中关联批次号，出库时指定从哪个批次扣减。这个改动涉及库存表结构、入库逻辑、出库逻辑三处调整，工作量中等，但对系统实用性的提升非常明显。

多仓库支持。在商品库存表上增加warehouse_id字段，所有入库出库单上也要选择仓库，库存查询变成按仓库维度查询。这个改动相对简单，数据库增加一张仓库表，然后给关联字段加上即可，比较适合作为二次开发的练手项目。

条码扫描。可以在前端引入一个扫码枪输入的输入框，直接聚焦后监听键盘事件，条码扫完自动触发查询商品。后端只需提供一个根据条码查询商品的接口。这个功能在真实仓库场景中是刚需，而且实现起来成本很低，但演示效果非常好。

Excel导入导出。使用EasyExcel或POI，把商品列表、入库明细、库存查询结果导出成Excel，再支持从Excel批量导入商品信息。这个功能几乎每个管理类系统都想要，而且代码模板成熟，网上资料一大堆，属于性价比极高的二次开发。

4.3 项目上线前必须做的检查项

如果你不只是把这个项目当作业，而是想真正部署到服务器上给别人用，有几个检查项建议一定过一遍。

第一，修改默认密码和关闭默认账号。很多开源项目的初始账号密码全网公开，不修改等于裸奔。更稳妥的做法是把用户表里的初始密码统一重置，并且强制用户首次登录后修改密码。

第二，在数据库连接配置里不要出现真实密码。更稳妥的做法是使用环境变量或配置中心来管理敏感配置，Springboot原生就支持${DB_PASSWORD}这种占位符，配合生产环境的系统环境变量即可。

第三，配置日志。生产环境一定要有日志体系，至少配置logback或log4j2，把日志输出到文件，并设置按天滚动。同时设置好日志级别，生产环境不建议开DEBUG，否则日志量会非常大。

第四，数据库备份。哪怕只是一个几十人的小团队在用，也建议每天凌晨自动备份一次数据库。MySQL的mysqldump写个cron脚本就能搞定，这个成本非常低，但真出事的时候能救命。

第五，用Docker部署。如果你对Linux命令不熟悉，可以采用Docker Compose的方式，把MySQL和后端服务做成两个容器编排起来，一条命令就能启动全套服务。网上关于"Springboot项目Docker部署"的教程非常多，照着配置一份Dockerfile和docker-compose.yml，部署效率会提升很多。

5. 常见问题与踩坑记录

5.1 前端请求接口报跨域错误

这是前后端分离项目里最经典的问题，但很多新手一遇到就懵。报错信息里出现Access-Control-Allow-Origin或者CORS字样的，基本都是跨域问题。

排查思路很简单：先看你的前端请求地址和后端接口地址是不是不同源。开发环境下，如果前端跑在3000端口，后端跑在8080端口，直接请求就必然跨域。解决方案就两种：后端加跨域配置，或者前端用代理。我前面讲的vue.config.js里配proxy就是代理方案，这也是开发阶段最推荐的方式，因为不需要改后端代码。

如果使用了代理仍然报错，那就看请求Network面板里的Request URL，确认是不是仍然指向了后端端口。如果指向了后端端口，说明代理没生效，检查一下vue.config.js修改后有没有重启npm run dev——这个配置文件修改后必须重启才生效，很多人就是栽在这里。

5.2 Vue表格数据修改后页面不刷新

在管理系统里，你提交一个表单后，希望能刷新列表数据。如果数据已经写入数据库了，但页面上还是旧数据，问题基本出在Vue的响应式机制上。

如果你用的是push直接往里塞数据，而数组本身是响应式的，Vue2针对下标赋值和直接arr.length = 0这类操作无法触发视图更新。如果你发现this.list = res.data这种整体赋值方式仍然不刷新，那就要检查是不是数据层级嵌套太深，或者是不是在v-for中直接修改了对象的某个属性。

最省事的解决方式，是每次数据操作成功后，重新调用一次列表查询接口，用接口返回值整体覆盖。虽然多了一次请求，但在管理系统中这个成本可以忽略不计，而且逻辑最清晰、最不容易出bug。这也是我推荐新手采用的方式。

5.3 库存出现负数或超卖

库存系统最怕的是什么？库存变成负数，或者明明只剩1件商品，却出库了10件。这个问题如果出现了，一定是有并发或者校验漏洞。

首先是前端校验。出库数量大于当前库存时，应该在前端就拦截掉。这个校验可以用Vue的表单验证规则实现，但要注意——前端校验只是用户体验改善，真正的校验必须放在后端，因为接口是可以被直接调用的，完全绕过前端。

其次是后端校验。在出库审核的Service方法里，要判断当前库存是否足够，不够就抛出异常。但单纯判断和更新之间存在时间窗口：两个请求同时读到库存是10，都判断"够"，然后都执行减10，结果库存变成了-10。解决方式就是前面提过的SELECT ... FOR UPDATE行锁或者乐观锁版本号。改造时建议使用乐观锁，给商品表加一个version字段，更新时带上WHERE id = ? AND version = ?，更新成功则version加1，如果影响行数为0，说明数据已经被别人改了，此时提示用户重试即可。

5.4 Springboot版本太高导致的依赖问题

我见过太多人解压源码后，因为本机JDK或Maven版本太高，导致一堆依赖下载失败或者启动报错。Springboot和JDK的版本匹配是有讲究的，具体来说：

• Springboot 2.x系列，用JDK 8或11都行
• Springboot 3.x系列，必须JDK 17以上
• 如果源码里用的是Springboot 3.x，你用JDK 8去编译，必然报错

如果你确定源码是Springboot 2.x版本，但你本机装了JDK 17，有时候也能跑，但可能会遇到一些反射相关的警告或异常。最稳妥的做法是安装JDK 8，并在IDEA里为项目单独配置Project SDK和Module SDK。你可以在IDEA里同时安装多个JDK版本，不同项目用不同的SDK，互不影响。

Maven版本也一样，如果pom.xml里配置了某些插件版本，和你的Maven版本不兼容，会出现Unsupported major.minor version这类错误。解决办法通常是升级Maven插件版本，或者在pom.xml里添加插件版本管理的配置。不过对新手来说，最省心的方式还是直接用源码自带或配套的Maven版本，不要轻易用最新的。

5.5 问题速查表

我把上面遇到的问题整理成一张表，方便你快速定位：

注意：排查问题时不要只盯着报错信息冒出来的那个页面，把浏览器开发者工具的Network面板打开，关注每个请求的状态码、请求URL、请求头和响应体，绝大多数接口联调问题都能在这里定位到。

我个人在实际操作中的体会是，开源源码这种东西，最忌"下载即跑，跑完即扔"。一套带中文注释的Springboot和Vue库存管理系统源码，如果只是拿来跑个效果图、截个屏放简历里，那真是浪费了。真正会用的人，拿到源码第一周先把主流程读完，第二周开始动手改一个小功能，比如给商品表加一个"保质期"字段，第三周尝试自己独立实现一个模块，比如盘点功能。能完整走完这个过程，这套源码的价值就真正发挥出来了。哪怕最后你改出来的代码不够完美，但这段从"抄"到"改"再到"写"的过程，才是源码带给你的最大回报。

本文还有配套的精品资源，点击获取