做Java后端这几年经手过不少“销售管理系统”类的项目但真正让我觉得骨架完整、可以直接上手改的还是这套企业级Web电子产品销售系统。它不是那种只有几个增删改查页面的教学Demo而是把SpringBoot、Vue、MyBatis、MySQL这套经典技术栈按真实企业项目的思路串了起来商品档案、库存台账、订单流转、客户管理、采购入库、销售统计业务闭环完整前后端源码齐全拿来就能跑。这篇文章我不打算把代码贴一遍而是把系统里我认为值得关注的架构决策、核心实现和落地过程中的坑按自己的实操顺序讲一遍。如果你正在做Java课程设计、毕业设计或者想完整跑通一套前后端分离项目这篇应该能帮你少走不少弯路。1. 项目整体架构与业务模块拆解1.1 为什么选 SpringBoot Vue MyBatis 这套组合先说说技术选型。现在Java Web项目可选的方向不少有Spring Cloud微服务、SpringBoot整合JPA、也有各种代码生成器配合MyBatis-Plus但国内大量中小企业项目的真实情况是单体应用够用开发效率优先团队里Java程序员普遍更熟悉MyBatis的XML写法。这套系统选SpringBoot Vue MyBatis MySQL本质上选的是“最不容易翻车”的组合。SpringBoot负责把原来Spring MVC那一大堆配置收敛掉自动配置机制让人把注意力放在业务代码而不是XML配置上。Vue负责前端交互用组件化方式组织页面配合Vue Router和Axios就能把前后端分离的架子撑起来。MyBatis则在SQL层面保留了最大灵活性——电子产品销售系统里商品筛选条件多变、统计报表复杂直接写SQL比完全依赖ORM自动生成更可控。实际开发中我见过不少团队纠结“用MyBatis还是MyBatis-Plus”。这套系统用原生MyBatis我认为是合理的销售系统涉及订单、库存、财务流水很多查询都是多表联查原生XML可以精细控制每一条SQL对初学者来说把SQL本身写明白比会调用Wrapper方法更重要。后期如果觉得单表CRUD写起来烦再引入MyBatis-Plus也不冲突两者本身是兼容关系。另外这套组合的方案在招聘市场也很常见。SpringBoot、Vue、MyBatis、MySQL几乎是Java全栈开发的标配技能树用这套系统练习学到的东西可以直接迁移到真实项目中比学一个偏门框架实用得多。1.2 业务模块划分从商品到订单的完整闭环电子产品销售系统的业务并不复杂但要做到闭环。这套系统的模块划分我比较认可整理出来大概是这样的商品管理商品档案、分类、品牌、型号、规格参数、售价与成本价管理库存管理入库、出库、库存盘点、库存预警所有库存变动都留流水采购管理采购订单、供应商档案、入库单采购入库直接驱动库存增加销售管理销售订单、订单明细、发货退货、销售统计客户管理客户档案、联系记录、客户等级系统管理用户、角色、菜单权限、操作日志模块之间不是孤立的我给你还原一个典型场景销售员创建一笔销售订单订单明细里的商品会校验库存是否充足订单确认后触发库存扣减同时写一条库存流水如果客户退货则生成退货单回补库存并生成负向流水采购员从供应商采购商品采购入库会更新商品库存和成本价。整个流程里订单、库存、采购、客户四张核心表被串成了一条线。这种跨模块的数据联动是这套系统最值得看的地方。我看到很多新手做类似系统时喜欢把模块彻底割裂商品模块只管商品表、订单模块只管订单表结果订单创建后库存不变退货后库存也不回补整个系统没法真实使用。模块之间有清晰的数据流、保证业务闭环是“企业级”这三个字最基本的含义。2. 后端核心实现SpringBoot MyBatis MySQL2.1 数据库设计电子产品销售场景的表结构要点先看数据库。电子产品销售场景有个明显特点商品属性不统一。手机有内存、屏幕尺寸、电池容量笔记本有CPU型号、显卡、重量耳机有佩戴方式、续航时间。如果每类商品都建一张表表结构会迅速膨胀如果所有属性都塞进一个字段查询又很难写。这套系统的做法是“基础主表 扩展参数表”的思路。商品主表存通用字段比如商品编码、名称、分类ID、品牌ID、销售价、成本价、库存量、状态商品参数表用键值结构存不同品类的差异化属性。查询时主表关联分类表、品牌表需要筛参数时再关联参数表。这种方案虽然没有NoSQL文档模型那么灵活但在MySQL里最稳定也方便后台管理页面用统一表单渲染。注意商品表里有一个字段容易被忽略——状态。电子产品有上架、下架、停用等状态状态字段建议用TINYINT类型1表示上架0表示下架默认值设为1。很多初学者不做状态管理导致停售商品仍然能下单这是很尴尬的线上事故。订单相关表建议重点看两个订单主表和订单明细表。主表存订单号、客户ID、订单总金额、订单状态、支付状态、创建时间明细表存商品ID、单价、数量、小计金额。为什么必须拆两张表而不是把多个商品塞在一条记录里三个原因一是订单金额需要按明细聚合统计二是退货时可能只退其中一部分商品三是统计商品销量时直接查明细表效率更高。这是销售系统的通用设计也是最容易踩坑的地方——有些人把订单明细用逗号分隔字符串存在主表里后续统计和退货处理时非常痛苦。库存表的设计也有讲究。库存量字段不建议只存一个总数字。电子产品销售一般涉及多仓库同一个商品在不同仓库的库存可能不同。更合理的方案是商品表保存汇总库存库存表按“商品ID 仓库ID”维度保存可用库存和锁定库存。锁定库存是什么意思客户下单但未付款时先把库存锁住避免超卖付款后再真正扣减订单取消则释放锁定。落实到代码里就是一串带条件更新的SQL配合事务稍后我会细说。2.2 分页与缓存MyBatis 的两个高频实践点MyBatis在项目里有两个使用频率极高、也最容易写错的点一个是分页一个是缓存。先说分页。销售系统的商品列表、订单列表都是典型列表页数据量一大就必须分页。手工写LIMIT当然可以但每张表都写一遍而且还要额外写一条COUNT查询代码很冗余。实际项目里最常见的办法是引入PageHelper这类分页插件。它的原理是拦截MyBatis的Executor在执行查询前自动改写SQL并拼上LIMIT同时自动执行COUNT查询返回总数。这里有个关键细节必须提醒PageHelper的Page对象是线程绑定的所以分页参数和查询SQL必须在同一个线程内连续执行中间不能夹别的查询语句。我见过一个线上案例开发人员在PageHelper.startPage和Mapper查询之间顺手查了一次数据库连接状态结果分页直接失效接口返回了全量数据列表页差点被拖垮。排查时看SQL日志才发现LIMIT根本没拼上。再说缓存。MyBatis自带一级缓存和二级缓存。一级缓存是SqlSession级别的默认开启同一个SqlSession内多次查询相同SQL会命中缓存二级缓存是Mapper级别的需要在XML里手动开启。但在销售这种数据实时性要求高的系统里我不建议过度依赖MyBatis二级缓存——订单库存数据改一下缓存里还是旧值数据一致性很难保证。我的建议是商品分类、品牌这类基本不变的数据用Redis做缓存订单和库存这类频繁变化的数据直接查数据库配合索引优化完全够用。如果你用的SpringBoot整合MyBatis还有一个细节值得留意——在application.yml里配置打印SQL日志。设置mybatis.configuration.log-impl为StdOutImpl或者把Mapper包名的logger级别设为DEBUG控制台就能看到每条SQL和绑定参数。排查分页失效、参数没传进去这类问题这套日志几乎是第一手段。电子产品商品搜索这块初期用LIKE模糊查询就好。如果后续商品数据量大了、想要更智能的搜索体验可以再考虑接千亿级检索或分词组件比如HanLP。但注意搜索功能的复杂度是逐步递进的不要在项目初期就引入重型搜索中间件。2.3 事务与库存扣减的并发控制销售系统里最怕的就是库存超卖。两个用户同时下单库存只剩1件如果代码先SELECT库存再判断再UPDATE在并发场景下就可能出现两个请求都读到库存为1然后都下单成功库存变成-1。解决办法有两个层面。一个是用数据库行锁在扣减库存的UPDATE语句里加上库存大于0的条件比如UPDATE product SET stock stock - 1 WHERE id ? AND stock 0如果影响行数为0说明库存不够直接抛业务异常。另一个是加事务把“检查并锁定库存→扣减库存→生成订单明细→计算订单金额”这几步放在一个Transactional事务里。这里的核心是把数据库的原子性用起来而不是靠Java代码里的synchronized。synchronized只对单机有效一旦以后做集群部署就完全失效而数据库行锁天然支持分布式场景。注意Transactional注解默认只对RuntimeException回滚对CheckedException不会回滚。很多业务异常习惯做成了自定义CheckedException如果不手动指定rollbackFor事务会静默提交库存扣减和订单生成就可能只成功一半。我的习惯是业务异常一律继承RuntimeException或者在Transactional上显式写明rollbackFor { Exception.class }避免埋雷。还有一个容易被忽略的场景订单取消和超时关单。用户下单锁了库存但一直不付款库存会一直被占用。企业级系统一般会配合定时任务比如每分钟扫描超过15分钟未支付的订单自动关闭并释放锁定库存。这套系统里如果看到类似的定时任务逻辑一定要仔细读这是库存准确度的重要保障。2.4 安全细节登录鉴权与文件上传安全企业级系统不能只有功能安全是底线。这套系统在安全方面有几个做得比较到位的点挑两个讲讲。一是登录鉴权。前端登录成功后拿到令牌后续请求在请求头里带上令牌后端通过拦截器或切面解析并校验权限。令牌推荐用JWT无状态、不需要在服务端存Session天然适合前后端分离架构。JWT密钥一定放在配置文件里用环境变量注入绝不能硬编码在源码里过期时间也别太长一般2小时左右配合前端路由守卫做自动跳转。二是文件上传的XSS过滤。搜索热词里有一条“SpringBoot项目全局过滤器处理上传pdf文件时XSS攻击”这个点确实很多项目会忽略。上传PDF本身不等于XSS攻击但PDF文件名、上传者备注、附件描述这些字段如果不做过滤可能被塞进恶意脚本展示时就会执行。做法是在全局加一个过滤器对所有请求参数做HTML标签转义和敏感关键词过滤但要小心只过滤“要输出到前端页面”的字段避免误伤商品描述里的正常富文本标签。我的建议是商品详情这类富文本字段单独做白名单过滤普通文本字段统一转义两条路径分开处理别一把抓。如果附件数量大、类型多后续还可以考虑把文件存储从本地目录切换到MinIO这类对象存储中间件。MinIO接入SpringBoot不算复杂需要引入对应SDK、配置endpoint和accessKey上传时用putObject下载时用getObject。好处是文件可以独立扩展存储容量也方便做访问控制。3. 前端Vue工程化与业务页面实现3.1 从零搭建 Vue 开发环境前端部分用的Vue工程化第一步就是环境搭建。很多新手卡在Node版本上——Vue CLI 4以上要求Node 10Vue 3配合Vite要求Node 14.18如果你的电脑里装的是老版本Node安装依赖时报EINTEGRITY或者engine相关的错误基本都是版本不匹配。建议直接用nvm管理Node版本装一个LTS版本就够日常开发。装完Node之后npm install这一步在国内网络环境下经常很慢甚至卡死。我一般先检查npm registry如果不是国内镜像就换掉。装完依赖后执行npm run dev浏览器打开本地访问地址Vue的启动页面出来就算环境跑通。再提一个高频坑前后端分离项目启动时前端端口和后端端口不一样浏览器会报跨域错误。解决方案常见有两种一种是在Vue的vue.config.js里配置devServer.proxy代理把接口请求转发到后端端口另一种是后端加CORS配置。我更推荐前者的proxy方式部署时直接用Nginx做反向代理前后端路径统一跨域问题从根源上消失。搜索引擎里经常看到“vue安装及环境配置”“vue安装依赖”“vue devtools插件下载”这类词说明环境问题确实是很多人的第一道坎。再补充一个实用建议Vue Devtools插件强烈建议装上调试组件状态、路由跳转、Vuex变化都靠它比在代码里到处console.log高效得多。3.2 路由、权限控制与动态菜单前端的核心逻辑在路由和权限控制上。这套销售系统的角色有管理员、采购员、销售员、仓管员不同角色看到的菜单是不同的。实现方案通常是登录时后端返回当前用户的角色和权限码前端根据权限码动态生成路由表。可以借助Vue Router的动态路由机制用router.addRoute在登录后添加有权限的路由而不是把所有路由都写在静态路由表里让所有人可见。路由参数这块也提一句。订单详情页、商品详情页这类从列表跳转过去的场景通常用路由参数传递主键ID。Vue Router支持两种传参方式一种是在路由路径里定义/order/detail/:id跳转时用params带上参数另一种是query方式类似/order/detail?id123。区别在于params方式的参数不会出现在URL问号后面刷新后参数还在而query方式参数就在URL上方便分享。实际项目中详情页我习惯用params方式列表筛选条件用query方式这样刷新页面后筛选条件还能保留。权限控制除了路由级还有按钮级。比如销售员能创建订单但不能审核订单这种细粒度权限可以在菜单表里配置按钮级别的权限码前端根据权限码决定按钮是否渲染。这套系统的权限结构是“用户→角色→菜单权限”三层模型扩展新角色时不需要改代码只改数据库配置就行。很多新手把权限码写死在页面里后面加角色就得改前端代码这是设计上的一大败笔。3.3 组件封装与销售报表可视化前端开发里组件的抽象程度直接决定后期迭代速度。这套系统里有些组件值得参考。第一个是表格组件。销售系统的列表页非常多如果每个页面都自己写表格和分页逻辑会非常痛苦。更常见的做法是二次封装一个通用表格组件接收列配置、数据源、分页参数内部处理加载状态、空数据提示、分页事件。页面里几行代码就搞定一个列表。类似的还有表单弹窗、状态标签这类高频组件都可以封装成全局组件统一风格也减少重复代码。第二个是报表可视化。销售统计页一般会展示销售额趋势、热销商品Top10、库存预警数量这里需要用到ECharts这类图表库。Vue里用ECharts的基本套路是在组件mounted时初始化实例然后通过setOption传入数据和配置。要提醒的是图表数据更新时要注意销毁并重建ECharts实例否则会出现图表不刷新或内存泄漏的问题另一个细节是图表容器必须有固定高度否则ECharts初始化时会拿到高度为0的容器画出来的图是空白的。封装组件的核心原则是“约定优于配置”。组件的输入输出接口要想清楚再动手别一上来就写一堆逻辑。复用是好事但过度抽象会让代码变得难以阅读遇到差异很大的页面宁可单独写一个页面组件也不要硬套通用组件。4. 完整源码部署与本地运行指南4.1 环境版本搭配JDK、MySQL、Node各版本怎么选这套系统既然叫完整版拿到源码后的第一步就是让它在本地跑起来。版本搭配这块很多问题都是版本乱配引起的。后端SpringBoot建议用2.x系列比如2.7.x配套JDK 8或JDK 11都可以。SpringBoot如果上3.xJDK必须17起步MyBatis相关依赖坐标也要注意兼容性调整。MySQL用5.7或8.0都行但8.0默认的认证插件是caching_sha2_password老版本的数据库连接驱动会连不上需要升级mysql-connector-java版本或者调整数据库用户认证方式。前端Vue用2.7或3.x都行关键是Node版本不要太老。数据库这块再补充一句。源码里如果有SQL脚本用Navicat或命令行导入时字符集要选utf8mb4否则商品描述里的特殊符号和生僻字会变成乱码。导入之前先建好数据库导入之后检查表数量确认商品表、订单表、库存表这些核心表都建出来了。MySQL安装本身也有不少细节Windows安装器版本选MySQL Installer会帮你配好服务Linux环境用包管理器安装后记得初始化数据目录、设置root密码、配置远程访问权限。很多人Navicat连不上本地MySQL多半是root用户默认只允许localhost登录需要单独创建远程账号或修改权限。4.2 从导入源码到首次启动的完整流程拿到源码后我习惯按这个顺序走导入SQL脚本到MySQL确认数据库名和配置文件里的JDBC连接串一致。修改application.yml里的数据库账号密码、端口号。用IDEA导入后端工程等待Maven下载依赖检查pom.xml里的依赖能否全部解析。启动SpringBoot主类看控制台日志出现Tomcat started on port(s)就说明后端起来了。前端进入项目目录npm install装依赖npm run dev启动。浏览器访问前端地址登录系统。这套流程看着简单但每步都有卡住的可能。Maven依赖下载慢是常态建议在Maven的settings.xml里配置国内镜像。IDEA导入项目时要选对Maven仓库否则项目会报找不到依赖。前端npm install如果出现node-sass安装失败多半是Node版本和node-sass版本不匹配换成dart-sass或者升级Node版本都能解决。首次启动后没有数据怎么办正常情况下SQL脚本会包含初始化数据比如管理员账号、基础分类、几个测试商品。如果没有初始化数据可以用CommandLineRunner写一段初始化逻辑或者手动往库里插几条数据保证页面不是空白的。这里也推荐去看一下SpringBoot启动时那个彩色的ASCII Banner网上有一些在线Banner生成器可以定制成公司名或者项目名团队开发时统一一下也蛮有意思。4.3 上线部署前必须改的几个配置本地跑通只算第一步真正对外开放前有几个配置必须动。第一是数据源配置。开发时的数据库密码和线上密码不能一样建议用Jasypt做配置加密或者干脆用环境变量注入让配置文件里不出现明文密码。第二是服务端口。默认8080在开发环境没问题上线时要么改端口要么用Nginx做反向代理把80端口转发到8080。用Nginx的好处是可以同时托管前端静态文件和后端接口还能做HTTPS切换、Gzip压缩、静态资源缓存。第三是日志配置。本地可以打印DEBUG日志上线一定要改成INFO以上避免把SQL参数和敏感业务数据打到日志里。建议配置按天滚动和文件大小切割别让日志把磁盘撑爆。第四是安全配置。JWT密钥、上传文件大小限制、跨域配置都要按生产环境重新设置。特别提醒一个容易被忽略的文件上传目录一定不能放在Web应用的静态资源目录下否则用户可以直接通过URL访问到上传的文件轻则信息泄露重则被上传恶意脚本。正确做法是把上传目录放在应用外面通过接口鉴权后再下载访问。5. 常见问题与排错实录5.1 启动阶段的高频报错我把以前带新人做这类项目时遇到的报错整理成了一张速查表能省不少排查时间。报错现象可能原因处理方式Access denied for user数据库账号密码错误核对application.yml中用户名密码Unknown database数据库名不对或未创建先建库再启动确认JDBC URL中的库名Table doesnt existSQL脚本未导入或导入不完整重新导入SQL检查核心表清单Port 8080 was already in use端口被占用改端口或结束占用端口的进程Invalid bound statement (not found)Mapper接口和XML不对应检查接口名、XML的namespace和id是否匹配npm ERR! node-sass missing bindingnode-sass版本问题删除node_modules重装或换dart-sassCannot find module vue-router依赖没装完整重新npm install以上只是启动阶段。很多项目跑不起来的原因真的就是版本环境问题和代码质量无关。所以接到陌生源码第一件事不是改代码而是确认环境版本和文档说明一致再动手启动。5.2 运行阶段的业务问题启动通过不代表业务没坑。运行阶段容易遇到几个典型问题我挑几个说说。一个是分页失效。表现是接口返回全部数据或者分页参数不生效。排查思路先看PageHelper.startPage和Mapper查询之间有没有其它数据库操作再看SQL日志里有没有拼接LIMIT最后看返回的Page对象有没有被手动转换成普通List类型。如果项目里做了DTO转换pageNum和total信息很容易丢失需要手动处理后返回。另一个是库存扣减不一致。以前遇到订单取消后库存没回补的问题定位到最后是事务回滚顺序写错了。建议在订单状态流转的关键节点都打印业务日志比如“开始扣减库存→扣减成功→生成订单→订单保存成功→事务提交”日志级别用INFO排查时按时间线就能看出哪一步断了。第三个是前后端字段对不上。后端返回的字段是下划线命名比如user_name前端JS里习惯用驼峰写法userName结果页面上怎么都不显示。处理方式是在SpringBoot配置里开启map-underscore-to-camel-case或者在SQL里使用别名。这个属于低级但常见的坑我每次接手项目都会先检查这个配置项。还有一个和IDE工具有关的小提示MyBatis的XML文件默认不会被高亮显示建议装上MyBatis相关的IDE插件XML里写SQL时会有语法高亮和提示少拼错几个表名字段名排查问题的速度能快不少。5.3 排错工具与调试习惯最后聊聊排错工具和调试习惯。后端排错最常用的就是IDEA断点调试但要提醒在事务方法里断点时事务还没提交你用数据库客户端查询可能查不到未提交的记录别误判成代码问题。正确做法是先把断点停在这一步看代码里的变量值确认数据正确后再放行最后查数据库确认最终落库结果。前端排错优先看浏览器开发者工具。Network面板能看接口请求和响应Console面板看JS报错Sources面板给JS断点。遇到接口返回正常但页面渲染不出来的情况多半是数据结构映射不对在Network面板里对比接口字段和页面绑定字段最直接。MySQL方面慢查询日志值得打开。销售系统的报表查询数据量一大SQL稍微写得不好就慢。在MySQL里执行EXPLAIN语句看执行计划检查有没有走索引。我见过最典型的案例是订单表按订单号查询时没建索引数据量涨到几十万行时一个查询要十几秒加上索引后瞬间变成毫秒级。凡是订单号、商品编码这类高频查询字段建索引都是必须的。调试习惯上我有一条经验改动之前先写日志不要等出了Bug再补。日志是整个系统的“黑匣子”线上出了问题第一件事就是翻日志。日志格式里建议包含请求ID、用户ID、关键业务参数这样能把一次操作的完整链路串起来几分钟就能定位问题所在。说实话这套系统的技术栈并不是最新最潮的但它的价值恰恰在于“不新”这两个字。SpringBoot、Vue、MyBatis、MySQL至今仍然是国内大量企业实际在用的技术组合把这一套跑通、吃透比追着热点框架看一堆Hello World要实用得多。我个人在改造这类销售系统的过程中最大的体会是业务闭环比技术选型重要数据一致性比功能丰富重要。商品、库存、订单、客户这几条线的数据流转先说清楚再写代码后面所有模块都会顺很多。如果看完这篇你想自己动手跑一遍建议先从“库存扣减”这个场景入手把事务和行锁的逻辑吃透这算是整张业务网里最值得花时间的一个节点。
