1. 项目整体拆解与技术选型分析
1.1 进销存系统究竟在解决什么业务问题
做毕业设计最怕选到一个“看起来简单、实际写起来全是坑”的题目，进销存系统恰好属于那种“业务场景清晰、技术覆盖全面、答辩时还能讲出深度”的典型题目。先说清楚一个多数同学容易忽略的点：进销存不是简单的增删改查，它解决的是企业日常经营中“钱、货、账”三件事之间的对账问题。
以轴承销售企业为例，采购员要进货，销售员要开单发货，仓管员要管库存，老板要关心哪些型号好卖、哪些型号压了资金。传统做法是Excel管库存、纸质单据管业务、月末靠人工对账，一旦型号多、单据量大，串账漏账是迟早的事。这套系统的核心价值，就是把“采购入库”“销售出库”“库存查询”“报表统计”这些散落的业务动作，统一收口到一套数据模型中，让每一笔业务都自动产生库存流水，让老板随时能在系统里看到真实的库存和经营数据。
这个业务本质在论文里特别好写，因为你可以顺着“人工管理的痛点 → 业务流程梳理 → 系统功能设计 → 数据模型支撑 → 系统实现验证”这条线讲下来，逻辑闭环很顺。很多同学论文写得干巴巴，就是因为只罗列了功能菜单，没有讲清楚每个功能背后解决的是哪类业务问题。
1.2 为什么SpringBoot+Vue+MySQL成了毕业设计的标配组合
这个技术栈放在今天确实不算新，但它稳。SpringBoot负责后端接口和业务逻辑，Vue负责前端页面渲染和交互，MySQL存数据，三者拼起来就是一个标准的前后端分离项目。选这套组合有几个实打实的好处。
SpringBoot的起步依赖机制特别契合初学者。配一个Web项目只需要引入spring-boot-starter-web，数据库操作有mybatis-plus或JPA帮忙兜底，内置的Tomcat免去了部署配置的麻烦，写出来的接口代码也很规整。说白了，SpringBoot把Spring时代那些繁琐的XML配置全部干掉了，让你把精力花在业务实现上，而不是折腾环境。
Vue这边，采用vue-element-admin这类开源后台模板可以快速搭起管理后台的架子，登录页、侧边栏、路由权限这些脚手架功能基本开箱即用。组件化开发的好处是，采购单、销售单、库存查询这些页面可以各自维护，互不干扰。注意论文中你要写清楚为什么选Element UI而不选其他组件库，理由无非是生态成熟、组件齐全、文档友好，答辩时导师问到能讲出依据就稳了。
MySQL更不用多说，部署简单、性能足够、资料丰富，遇到问题一搜就有答案。关系型数据库的ACID事务特性，也正好能支撑进销存里最关键的库存扣减和单据写入操作。这套组合的目标很明确：用最稳妥的方式，在有限时间内做出一个完整、能跑、能演示、能讲清原理的系统。
1.3 功能边界划分：哪些功能必须有，哪些是为了答辩加分
和很多同学聊过之后发现一个共同问题：拿到题目后第一反应是“能加的功能都加上”，结果系统越做越臃肿，一个页面几十个字段，最后自己都讲不清业务逻辑。功能边界一定要以“业务闭环”为原则来划分。
核心必做模块就这么几个：
- 系统管理：用户、角色、菜单权限。这是登录后第一眼看到的东西，也是答辩时必然会问的一个功能点。
- 采购管理：采购订单、采购入库。对应“进”的业务。
- 销售管理：销售订单、销售出库。对应“销”的业务。
- 库存管理：库存查询、库存流水、库存预警。这是进销存的账本核心，所有单据的最终落点。
- 报表统计：采购汇总、销售汇总、库存周转情况。对应“经营决策”这个高层级需求。
加分功能可以选做：客户/供应商管理、多仓库调拨、批次管理、数据导入导出。注意加分的含义是“能讲清楚为什么做、怎么做”才有加分效果，如果只是堆砌一个Excel导入导出功能但谈不出应用场景，答辩时反而会被追问到卡壳。
2. 数据库设计与核心功能建模
2.1 从业务单据反推表结构设计
数据库设计是这类系统的命脉，表结构不合理，后面每个查询都写得难受。进销存系统的表设计有个实用原则：先梳理核心单据，再反推需要哪些基础信息表。
从业务角度看，一张采购入库单至少包含两部分数据：单据主表（单号、供应商、采购员、入库时间、总金额、备注等）和单据明细表（哪个型号的轴承、采购数量、单价、金额小计）。所以采购相关至少需要采购单主表、采购单明细表。销售模块对应销售单主表、销售单明细表。再加上商品信息表（轴承型号、规格、单位、库存量、预警阈值、图片等）、供应商表、客户表、用户表、角色表、权限表。
举几个实际建表时的关键细节：
- 金额字段一律用decimal(10,2)或更大精度，严禁用float/double，否则算总价时会出现0.1+0.2不等于0.3的尴尬局面。
- 库存数量也要用decimal而不是int，因为轴承可能按“套”或“公斤”计量，存在小数。别觉得少见，工业品按重量、长度计量的情况很普遍。
- 所有表都建议带create_time、update_time、create_by、update_by这几个公共字段，将来做审计追踪和报表统计时特别有用。
- 逻辑删除用deleted字段做标记，避免误删数据后在库存流水对不上账。
2.2 库存流水：把每一笔业务都变成账本记录
进销存系统容易被做成“多张表单的CRUD”，但如果只有单据表没有库存流水表，整个系统其实是散的。库存流水是这个系统的账本，它的核心逻辑是：任何改变库存数量的操作，都必须同时产生一条库存流水记录。
库存流水表建议字段：流水ID、关联业务类型（采购入库/销售出库/退货入库/盘点调整）、关联单据编号、商品ID、变动数量（正数表示入库，负数表示出库）、变动前库存量、变动后库存量、操作人、操作时间、备注。
举个具体场景：采购入库单提交后要写60套深沟球轴承，业务层要做三步操作。第一步把采购单主表和明细表写库；第二步更新商品表里该型号的库存数量，从原来的200套变成260套；第三步往库存流水表写入“数量+60，变动前200，变动后260”的记录。三步必须在一个事务里完成，任何一个失败都要全部回滚。
这个设计在论文里非常加分，因为它体现了“数据一致性”意识。面试或答辩被问到“如果库存更新失败怎么办”，你可以直接答出事务回滚和数据对账的思路，比背概念强得多。
2.3 角色权限与登录鉴权的落地方式
进销存系统涉及采购、销售、仓库、财务、管理员等不同角色，权限设计不能是一个花架子。最简单的落地方式是“用户-角色-菜单”三层模型：用户表关联角色表，角色表关联菜单权限表，后端在用户登录时一次性查出其权限列表，前端根据权限动态渲染菜单，后端接口再用拦截器或AOP做二次校验。
换个直白的说法：前端隐藏菜单只是让页面看不到，真正防越权的是后端的接口校验。有的同学只做了前端按钮级权限控制，改个URL就能看到不属于自己的数据，这就是安全隐患。建议后端用Spring Security或简单的HandlerInterceptor根据放行的路径匹配权限，把管理员接口和普通用户接口分开控制。
登录这块用JWT，生成token返回给前端，前端存到LocalStorage里，每次请求在请求头带上Authorization字段。记得处理token过期后的刷新逻辑，否则用户用着用着就被踢下线，演示系统时很尴尬。
3. 前后端联调与核心业务场景实战
3.1 采购入库全链路：从订单到库存的完整数据流
采购入库是整个进销存的第一环，捋清楚了这个链路，后面销售出库基本是同理反推。完整流程是：采购员新建采购单，选择供应商和轴承型号，填写数量和采购单价，提交后生成待入库状态的采购单；仓管员在“采购入库”菜单里选择对应单据，确认无误后执行入库。
在代码层面，这个流程涉及三个接口：一个创建采购单接口、一个执行入库接口、一个查询采购单列表接口。其中执行入库接口是核心，它的事务逻辑必须严谨。
实际编码时要注意一个细节：入库操作执行完后，采购单的状态要同步改成“已入库”，同时锁定该单据不能重复入库。压单、防重复提交的方式可以加状态字段校验，也可以在接口入参加业务流水号进行唯一性校验。否则用户在页面上手快点了两次“入库”，库存就会翻倍。
3.2 销售出库的库存校验和事务一致性处理
销售出库业务逻辑比采购入库多一层“库存是否足够”的校验。用户在创建销售单时选好轴承型号和数量，后端要立即检查商品表对应型号的当前库存量，如果不足直接抛异常提示。这不是简单的if语句问题，还要考虑并发场景。
举个例子：仓库里某型号只剩50套，A、B两个销售员几乎同时下单各要40套。如果代码是先查库存再扣减，可能出现两人都查到了50套库存，都通过校验，先后写入数据库后库存变成负数。这就是并发下的超卖问题。
解决办法不复杂，用乐观锁就行：商品表加version字段，更新库存的SQL带上“WHERE id = ? AND version = ? AND stock >= ?”这三个条件，更新成功后version加1。如果更新影响行数为0，说明版本不一致或库存不足，抛异常让用户重试。这套思路在论文的“关键技术”章节里可以作为独立小节，讲清楚“为什么不能只用if判断”比单纯写功能更能体现专业深度。
销售出库的事务处理和采购入库类似：写销售单主表和明细表、扣减库存、写库存流水，三步包裹在同一个事务方法里。
3.3 盘点管理：一个容易被忽视但必须有的功能
很多同学做进销存系统会把盘点忘记，但实际企业运营中盘点是刚需。因为理论库存和实际库存总会因为各种原因出现偏差，比如货物损坏、发错货、漏记单据。
盘点功能的业务逻辑是：新建盘点单，选择要盘点的仓库或商品范围，录入实际盘点数量，系统自动对比账面库存和实盘数量的差异，生成盘盈或盘亏数据。确认审核后，通过“盘点调整”动作将库存修正为实盘数量，同时写入库存流水，流水类型标记为“盘点调整”。
这个功能的亮点在于它能引出“账实相符”这个企业管理概念。论文里可以写：通过盘点功能，企业能够定期核对账面库存与实际库存，及时发现并纠正管理漏洞。
3.4 报表统计的SQL写法与数据可视化
报表功能是答辩时的加分区间。不建议用复杂的大数据可视化方案，进销存系统里最实用的就是ECharts+后端聚合统计接口。
常用报表有三类：销售趋势图（按日期统计销售总金额）、采购趋势图、库存结构图（各类轴承品种的库存金额占比）。SQL层面用GROUP BY加时间函数对订单日期做分组，SUM求总和。注意日期格式的坑：MySQL里针对日期分组的函数有date_format(create_time, '%Y-%m-%d')，跨年统计时记得按年分组，否则不同年份的同一天会揉在一起。
报表查询接口最好加个时间范围参数，前端日期选择器选好起止时间传给后端。ECharts这边引入cdn资源即可，精华在option配置：
option = { xAxis: { type: 'category', data: days }, series: [{ type: 'line', smooth: true, data: amounts }] }4. 部署交付与论文撰写要点
4.1 本地部署到服务器部署的完整路径
毕业设计答辩现场最怕的事就是“环境一换系统跑不起来”。提前把部署文档写清楚，不光是为了交付，更是为了你自己演示的时候不翻车。
本地部署相对简单，后端改一下application.yml的数据库连接和端口，前端npm run build打包后配置Nginx指向dist目录。服务器部署就要注意几个细节了：Linux上MySQL的编码要设置成utf8mb4，否则存中文会乱码；JVM堆内存按云服务器配置调整，常规2G内存的云主机建议把启动参数设成-Xms256m -Xmx512m。
最容易踩的坑是前后端联调时的接口地址。前端开发时用proxy做代理指向localhost:8080，打包后如果还有硬编码的axios baseURL指向localhost，换到服务器上就请求不通了。正确做法是把接口路径设计成相对路径，部署时用Nginx做反向代理，把/api前缀的请求转发到后端服务。
4.2 配置文件管理与加密注意项
毕业设计项目一般不需要上配置中心，但基本的配置管理意识要有。application.yml里建议区分开三块：数据源配置、redis配置、自定义业务配置比如文件上传路径。
数据库密码明文写在配置文件里是开发阶段的做法，如果论文里写到“系统安全”相关章节，可以提一下加密存储的思路。比如用jasypt这个库对密码做加解密，配置里放密文，启动时解密。不太复杂的替代方案是使用环境变量：spring.datasource.password=${DB_PASSWORD}，部署时在系统环境变量里给值，这样配置文件里不会出现明文密码。
4.3 论文中系统实现章节的写作思路
论文章节里最核心的是“系统设计”和“系统实现”两章。很多同学把系统实现写成“我用了什么框架，调用什么方法”，这几百字就交代完了，答辩自然没东西讲。实际应该分模块拆开写：每个功能模块一个小节，包含功能描述、页面设计、业务逻辑流程、核心代码片段、部分运行截图。
比如采购入库这个小节，你可以这样组织：先写业务目标一句话；然后描述用户操作流程，从点击菜单到选择供应商到提交审单分成3步；然后讲核心数据表；再把控制器的入库接口核心代码贴出来，贴代码的旁边加一段注释说明事务边界；最后放两张页面截图展示效果。这样的论文答辩没问题，读者照着写也能复现。
5. 常见问题与实战避坑速查
5.1 BigDecimal的精度问题
涉及金额、数量计算，超过两个人的开发团队都要立规矩：不能用double。哪怕商品单价是纯整数，计算总价时double也可能丢精度。所有金额字段类型用decimal，Java代码里用BigDecimal，构造BigDecimal最好用字符串入参的构造函数，不要用new BigDecimal(0.1)。
5.2 时间字段时区错乱的坑
本地开发好好的，部署到服务器发现所有单据时间比实际时间多了8小时。这是MySQL连接参数没有加serverTimezone=Asia/Shanghai导致的问题。
5.3 跨域请求配置
前后端分离项目必然遇到跨域问题。后端写一个CorsConfig配置类添加允许跨域的请求映射即可。个别同学遇到的问题是不带Cookie时跨域没问题，带上Cookie就报错，这是因为allowedOrigin要写具体域名而不能用*，并且需要给allowedOrigin单独配置。
5.4 前端路由刷新404
部署到Nginx后，点击页面跳转正常，一按F5刷新就404。这是前端路由历史的经典问题：Nginx默认找不带.html后缀的路径时直接返回404。需要在Nginx的location块里配置try_files参数。
5.5 依赖版本冲突
SpringBoot和MyBatis-Plus版本不匹配会导致启动报错。项目初始化时建议直接到MyBatis-Plus官网找对应SpringBoot版本的starter版本号，不要自己猜。也可以统一采用Spring Initializr生成的版本基线。
6. 一些个人经验总结
写这类毕业设计项目，我个人体会最深的一点是：功能做得再花哨，不如把一条核心业务链路做扎实。只要把“采购入库 → 库存变动 → 销售出库 → 库存校验 → 报表统计”这条链路在代码和文档里完整打通，系统逻辑自洽、数据能对账，答辩就能站得住。如果时间紧张，先把核心链路做完再动加功能的心思，千万不要本末倒置。
另外，部署文档不要最后才写，开发过程中每配置一个环境就顺手记录下来。很多同学项目做完后启动步骤自己都忘了，回头补文档不仅费时还容易漏关键步骤。把自己当成一个使用者，从零开始按文档操作一遍，能一次跑通，这份文档才算合格。
最后再分享一个小技巧：答辩前适当地多准备几张业务数据截图，比如采购单列表、销售趋势图、库存流水明细，讲到对应模块时随手展示，比光讲代码有效得多。数据是“实”的，页面是“活”的，这两样东西放在面前，答辩委员会的所有提问都能围绕系统本身的业务展开，胜算自然更高。
