简介一份docx格式的毕业设计论文完整阐述基于Java与Vue框架的珠宝首饰进销存管理系统的设计与实现主要面向计算机相关专业学生、毕业设计选题者以及珠宝行业信息化开发人员。系统采用B/S架构与MySQL数据库设计管理员与操作员两类角色核心模块涵盖首页、个人中心、操作员管理、总库库存管理、出库单管理、入库单管理、门店管理及销售单管理清晰展示了进销存业务的完整数字化流转过程。压缩包内仅含1个docx文档大小3.69MB文档内容从摘要、绪论到需求分析、系统设计、数据库设计及测试环节均有详实论述可作为系统开发与论文写作的双重参考。目前已有190人学习下载尤其适合需要借鉴J2EE/Vue技术栈完成课程设计或毕业项目的读者能够帮助快速梳理功能架构与实现思路。1. 项目起点为什么珠宝行业需要一套专属的进销存系统先交代一下背景。我接触这个项目时客户是一家做珠宝零售的线下门店主营黄金、钻石、翡翠三类货品门店不大但SKU管理却比普通百货零售复杂得多。问题主要体现在三个层面一是珠宝货品有唯一的证书编号、克重、成色、工费每件货品几乎是“一物一参数”不能像卖衣服那样按尺码批量入库二是拿货、退换、调拨、旧金回收这些业务混在一起传统Excel表格早就不够用了三是老板要的报表不是简单的进销存流水而是要按货品类别、时间段、销售渠道去算毛利还要追踪每一件货品的实时状态——在库、锁定、已售、返修、调拨中。当时市面上通用的进销存软件我也评估过功能齐全但过于臃肿且针对珠宝行业的“一物一码”和旧料换新业务支持很弱定制改造的成本比从零开发还高。经过几轮沟通最终确定了用SpringBoot Vue Java这套主流技术栈从零搭建一套面向珠宝门店的进销存管理系统。这个项目本身也作为课题写成了论文标题就叫“springboot Vue java珠宝首饰进销存管理系统”。那为什么选这套技术栈而不是别的SpringBoot在Java后端领域已经是事实标准生态成熟招人容易后续维护不会卡脖子Vue作为前端框架上手快、响应式交互做得好单据录入这类高频操作页面的体验能够做得比较细腻而Java本身跨平台、稳定适合做进销存这种对数据一致性要求高的业务系统。整套方案在中小型企业管理软件里属于性价比最稳的选型。这套系统最终能做什么我直接列一下核心能力货品档案管理含证书编号、克重、成色、图片、采购入库、销售出库、门店调拨、旧金回收置换、库存盘点、毛利统计、会员管理、员工权限控制。后续所有章节我都会围绕这些功能模块展开讲设计思路和实操细节。2. 整体架构设计与技术选型解析2.1 前后端分离为什么要拆开而不是用传统模板早期的Java Web项目页面和服务端是耦合在一起的用JSP或者Thymeleaf渲染页面开发效率低前后端分工也不清晰。这个项目我直接采用前后端分离架构后端只提供JSON接口前端用Vue独立工程开发通过HTTP调用接口完成所有交互。这样做的直接好处有三个。第一前后端可以并行开发后端定义好接口文档后前端人员不需要等服务端代码写完就能开始写页面第二系统后续如果要对接微信小程序或者平板端前端代码可以复用Vue组件只需要新增一个小程序端工程后端接口完全不用动第三部署时可以分开处理前端静态资源丢Nginx后端打成Jar包独立运行排查问题时边界也清晰。后端技术选型如下SpringBoot 2.7.x稳定版本兼容性好不追新避免版本太高导致的一些第三方组件适配问题。MyBatis-Plus单表CRUD基本不用写SQL复杂统计自己写XML效率和可控性兼顾。MySQL 8.0数据存储珠宝门店的数据量完全够用。Redis做登录Token缓存、字典数据缓存、热点数据加速。Sa-Token轻量级的登录认证框架比Shiro配置简单比Spring Security的门槛低很多适合中小型管理系统。前端选型Vue 2.6 Element UIVue 2的生态最稳Element UI的表格、表单、弹窗组件开箱即用非常适合管理后台这种强交互、重表单的场景。Axios统一封装HTTP请求拦截器处理Token附加和异常提示。ECharts用于首页的数据看板做月度销售趋势、品类占比等图表。2.2 为什么不用微服务单应用够吗我在设计初期也想过要不要拆微服务毕竟现在简历上写微服务是加分项。但冷静下来分析珠宝门店系统用户量撑死几十号人并发量极低业务边界也没有复杂到需要独立拆分的程度。强行上微服务只会引入分布式事务、服务注册发现、配置中心这些复杂度对实际业务毫无帮助。最终采用了单应用多模块的Maven结构按功能拆分成几个modulecommon通用工具、system用户权限、goods货品中心、stock库存交易、report报表统计。这样既保持了代码层面的逻辑隔离又不引入分布式复杂度。如果将来业务量真的增长了再按module边界拆成微服务也不迟这是成本最低的演进路径。提示做中小型管理系统的架构选型核心原则是“按业务量级做适配”不要为了技术而技术。单体应用撑不住的场景通常是成千上万的并发请求珠宝门店的管理系统完全不在这个范畴内。3. 数据库设计珠宝库存的“一物一码”核心模型3.1 核心表结构与字段设计数据库设计是整个系统最关键的部分珠宝行业的特殊性在表结构上体现得非常明显。普通商品进销存按SKU汇总即可但珠宝必须做到“一物一码”也就是每一件货品都有一条独立的记录从入库到销售全程可追踪。这一点决定了主表的设计思路。以货品表为例核心字段如下CREATE TABLE goods_info ( id bigint(20) NOT NULL AUTO_INCREMENT, goods_code varchar(32) NOT NULL COMMENT 货品唯一编码, goods_name varchar(64) NOT NULL COMMENT 货品名称, category varchar(16) NOT NULL COMMENT 品类黄金/钻石/翡翠/K金, material varchar(16) DEFAULT NULL COMMENT 材质, weight decimal(10,3) DEFAULT NULL COMMENT 克重, gold_price decimal(10,2) DEFAULT NULL COMMENT 金料单价, work_fee decimal(10,2) DEFAULT NULL COMMENT 工费, cert_no varchar(64) DEFAULT NULL COMMENT 鉴定证书编号, stone_name varchar(32) DEFAULT NULL COMMENT 主石名称, stone_weight decimal(10,3) DEFAULT NULL COMMENT 主石重量, cost_price decimal(10,2) NOT NULL COMMENT 成本价, sale_price decimal(10,2) NOT NULL COMMENT 销售标价, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1在库 2锁定 3已售 4调拨中 5返修, supplier_id bigint(20) DEFAULT NULL COMMENT 供应商ID, warehouse_id bigint(20) DEFAULT NULL COMMENT 所属门店/仓库, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_goods_code (goods_code), KEY idx_category (category), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT货品档案表;这张表的设计要点在于goods_code这个唯一编码它相当于货品的“身份证号”。门店入库时每件货品生成一个唯一编码可以是证书号入库日期的组合也可以直接用雪花算法生成后续所有表都通过这个编码关联货品确保全程可追溯。权重字段全部用decimal尤其是克重精确到小数点后三位这是珠宝行业的硬性要求。黄金克重差0.01克在实时金价下就有几块钱的出入用float或者double做金额计算会累积误差这在财务上是绝对不能接受的。3.2 库存流水表进销存系统的“总账本”除了货品档案表库存流水表是整个系统的账本核心。每次采购入库、销售出库、调拨出入库、盘点调整都会在这个表里追加一条流水记录。库存表只存当前实时数量流水表存所有的历史变动两者配合既能查询现状也能回溯历史。CREATE TABLE stock_flow ( id bigint(20) NOT NULL AUTO_INCREMENT, goods_code varchar(32) NOT NULL COMMENT 货品编码, flow_type tinyint(4) NOT NULL COMMENT 流水类型1采购入库 2销售出库 3调拨出库 4调拨入库 5盘点盘盈 6盘点盘亏 7其他, warehouse_id bigint(20) NOT NULL COMMENT 仓库ID, quantity int(11) NOT NULL DEFAULT 1 COMMENT 变动数量, before_stock int(11) NOT NULL COMMENT 变动前库存, after_stock int(11) NOT NULL COMMENT 变动后库存, order_no varchar(32) DEFAULT NULL COMMENT 关联单号, remark varchar(255) DEFAULT NULL COMMENT 备注, create_by varchar(32) NOT NULL COMMENT 操作人, create_time datetime NOT NULL COMMENT 操作时间, PRIMARY KEY (id), KEY idx_goods_code (goods_code), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存流水表;这里我要特别强调一个编码约定所有库存变动业务必须在同一个数据库事务里完成“写流水更新库存”两步操作任何一步失败都要整体回滚。不然就会出现流水记录和实际库存对不上的情况后期对账会异常痛苦。这个是我在开发过程中踩过坑后强化的设计约束。4. 核心功能模块实现从采购到销售的全链路4.1 采购入库最容易被忽视的批量处理细节采购入库这个模块看起来就是填一张入库单选供应商、扫货品、填价格、保存。但实际落地时有个非常关键的体验问题需要处理一次采购几十件货品怎么做才能不让人烦躁如果按传统表单一行一行录录一件货品要填十几个字段50件货品就是几百次鼠标点击操作员容易崩溃。我的做法是做了一个“批量录入面板”支持两种方式一种是逐件录入表单自动清空光标回到第一个输入框连续录入能力要顺滑另一种是Excel批量导入系统提供标准模板操作员在门店电脑上填好后再上传。这两种方式覆盖了大多数场景实测下来50件货品的入库操作时间从原来的半个多小时压缩到十分钟以内。采购入库时还要自动完成一个动作根据金价行情和工费计算出成本价。门店采购黄金时成本价金料重量×当日金价工费这个计算逻辑在入库时就要算好并写入货品表后续毛利统计直接基于这个成本价不再重复计算。4.2 销售出库挂单、锁库存与优惠折扣销售出库是门店每天使用频率最高的功能设计的流畅度直接影响收银效率。这里最核心的操作是“挂单”和“锁库存”。挂单是什么意思顾客可能同时看中两三件货品犹豫要哪件或者要等家里人拍板。这时候收银员先把意向货品锁住避免被其他顾客买走。这个锁库存操作在系统里就叫“锁定”锁定的货品在库状态从1变为2。锁定时长为30分钟超时自动释放不然一件货品被锁住半天其他顾客就看不了了。锁库存的实现也不复杂就是在货品状态上做一个原子更新// 锁定货品加条件 status 1在库防止并发下重复锁定 boolean locked goodsInfoService.update( new LambdaUpdateWrapperGoodsInfo() .eq(GoodsInfo::getGoodsCode, goodsCode) .eq(GoodsInfo::getStatus, 1) .set(GoodsInfo::getStatus, 2) ); if (!locked) { throw new ServiceException(货品已被锁定或售出请刷新后重试); }这个条件更新的写法很关键它保证了并发场景下同一件货品不会被两个收银员同时锁定。如果不加status1这个条件两个请求同时更新就会出现超卖问题。这个场景在珠宝门店虽然并发不高但也是数据一致性的基本功。销售开单时还要支持会员折扣、满减、旧金抵扣这些促销逻辑。优惠金额的计算我放在后端统一处理前端只传业务参数避免不同终端计算结果不一致。销售完成后货品状态变为已售同时自动扣减对应门店的库存写入销售流水。4.3 库存盘点用状态机管住“差异审批”盘点这个功能珠宝门店的刚需程度甚至比销售还高。黄金这类高价值货品每天下班都要盘点账实不符是老板最担心的事。系统设计了“盘点单→盘点录入→差异生成→审核调整”的流程。盘点的核心是盘点差异的处理。盘点单创建后系统会生成当前账面库存列表操作员在手持终端上扫码或手动录入实际库存提交后系统自动比对账面和实盘数据有差异的货品生成差异明细。这里有个设计细节差异并不会直接修改库存而是先进入“待审核”状态由店长或财务确认后执行盘盈或盘亏调整。为什么要加这个审核环节因为盘点差异可能不是真的少了货可能是录错了货品编号、放错了仓位直接改库存会把问题掩盖掉。先审核确认再调整库存同时写入调整流水和备注这样每一笔差异都有迹可循。4.4 毛利统计按时间段、品类、渠道多维度报表报表模块直接决定老板对这个系统的满意度。老板看得最多的不是库存数而是赚了多少钱。毛利统计的核心SQL要能按时间段、品类、销售渠道进行多维度组合查询。实际实现时销售单表和销售明细表分开存储。销售单记录整笔交易的订单信息包括订单号、客户、应付金额、实付金额、优惠金额、销售渠道销售明细记录每一件售出货品的货品编码、成本价、成交价。毛利实付金额合计-成本金额合计。为了让报表查询高效我用了MyBatis-Plus的LambdaQueryWrapper配合GroupBy不需要写复杂的存储过程// 按品类统计毛利 ListMapString, Object result saleDetailMapper.selectMaps( new QueryWrapperSaleDetail() .select(goods_category AS category, SUM(actual_amount - cost_price) AS profit, COUNT(*) AS sale_count) .between(sale_time, startDate, endDate) .groupBy(goods_category) );这里的字段别名要注意MyBatis-Plus的select传入的是SQL片段不能直接用Lambda表达式我最初在这里踩过坑老是写错后来统一改用字符串方式。注意财务相关字段的加减运算Java后端一定要用BigDecimal不能直接用double。数据库端金额字段用decimal(10,2)Java实体类用BigDecimal类型映射防止浮点数精度问题在统计报表中放大。5. 权限设计与数据安全5.1 基于RBAC的权限模型门店系统里有老板、店长、收银员、库管几种角色不同角色的操作权限差异很大。收银员只能操作销售出库和查看库存店长可以审核盘点差异和调拨单老板可以看到全部报表和毛利数据。权限模型采用经典的RBAC基于角色的访问控制设计用户表、角色表、菜单权限表、用户角色关联表、角色菜单关联表五张表。后端的权限控制通过Sa-Token的注解实现前端则通过动态路由控制菜单显示和按钮级权限。后端的核心代码如下SaCheckPermission(sale:order:create) PostMapping(/sale/order) public Result createSaleOrder(RequestBody Validated SaleOrderDTO dto) { // 只有拥有销售开单权限的用户才能访问 saleService.createOrder(dto); return Result.success(); }前端动态路由的思路是用户登录后后端返回该用户有权限的菜单列表前端遍历菜单列表动态注册路由。这样在界面上收银员看不到报表菜单老板看不到收银员的操作界面细节权限在前后端双重校验。5.2 密码存储与登录安全密码存储不能明文这是基本要求。系统使用BCrypt算法加密存储密码这个算法的特点是一次一密即使两个用户密码相同加密后的密文也不同防彩虹表攻击能力比MD5强得多。登录认证使用Sa-Token的Token机制登录成功后将Token缓存在Redis中设置有效期用户操作时自动续期。还有一点容易被忽略的是操作日志。像删除货品、调整库存、修改价格这类敏感操作必须记录操作人、操作时间、操作前后值。我实现了一个简单的操作日志切面通过AOP拦截标注了OpLog注解的方法自动记录日志OpLog(module 库存管理, type 盘点调整, desc 盘点盘亏调整) PostMapping(/stock/adjust) public Result stockAdjust(RequestBody StockAdjustDTO dto) { // ... }这个切面在方法执行后自动记录日志不需要在每个Service方法里手动写日志逻辑。后续查账、追责、审计都有据可依。提示珠宝门店系统虽然不像互联网应用那样面临大规模攻击但涉及资金和高价值货品的数据安全必须严谨。操作日志这个功能千万不能省宁可多记录不要等出了问题才发现无据可查。6. 部署上线与性能优化实践6.1 环境准备与部署流程项目部署我采用的是经典的单机部署方案一台4核8G的云服务器就能带起来整个系统部署结构如下Nginx监听80/443端口托管前端Vue构建产物同时反向代理后端接口后端SpringBoot应用以Jar包方式运行通过systemd守护进程管理MySQL和Redis用Docker部署方便版本管理和备份。后端启动时的JVM参数我做了针对性优化java -Xms512m -Xmx1024m -XX:UseG1GC -jar jewelry-erp.jar-Xms和-Xmx控制堆内存大小4G内存的机器给JVM分配1G完全够用G1垃圾回收器适合这种多线程、中低并发的应用场景响应时间更稳定。前端构建时也有几个值得注意的点。Vue项目的publicPath要设置为相对路径或绝对路径的根目录不能默认的/否则部署到子目录或者用域名访问会出现静态资源404的问题。打包产物的gzip压缩可以交给Nginx的gzip模块处理不用在build阶段压缩减少构建时间。6.2 接口性能优化让报表不再卡顿系统上线后用户反馈最多的性能问题集中在报表模块尤其是按年统计毛利的时候页面要等将近十秒才出数据。排查后发现原因是销售明细表数据量到了几十万条关联查询时没有走索引而且统计SQL一次性加载了所有明细数据到内存中再聚合。针对这个问题做了两个优化。第一在销售明细表的sale_time、goods_category字段上加了联合索引让时间段过滤走索引而非全表扫描。第二把统计逻辑从“先查明细再内存聚合”改为“数据库端直接聚合”减少数据传输量。优化后的SQL执行时间从8秒降到了0.3秒左右效果立竿见影。这给团队一个教训报表类的统计查询尽量让数据库完成聚合计算而不是把明细数据拉到应用层再算。数据库存在的意义就是处理这类运算别浪费它的能力。6.3 数据备份策略进销存系统的数据安全绝对优先级最高数据库必须定期备份。我的方案是每天凌晨2点执行一次mysqldump全量备份保留最近30天的备份文件同时每天将备份文件同步到异地存储。这样一来即使服务器硬盘损坏也能在半小时内恢复数据。# 每天凌晨2点执行备份 0 2 * * * mysqldump -u root -pJewelry2024 jewelry_erp /backup/jewelry_erp_$(date \%Y\%m\%d).sql # 异地同步 0 3 * * * rclone sync /backup oss:bucket-backup/jewelry-erp数据备份的恢复演练也很重要。我在测试环境做过一次模拟恢复从备份文件恢复到启动可用大约需要10分钟。这个恢复时效对珠宝门店来说完全可接受真遇到服务器故障也不至于慌乱。7. 遇到过的坑与高频问题排查记录实际开发过程中踩过的坑不少挑几个典型的分享一下希望能帮后来者少走弯路。7.1 并发锁库存时出现数据不一致这是我最早遇到的一个问题。最初锁库存的逻辑是先查询货品状态再在代码里判断然后执行更新。结果测试时发现两个账号同时操作同一件货品两个请求都读到了“在库”状态也都在代码里通过了判断最后两笔销售单竟然都开成功了。这就是典型的“先读后写”并发问题解决方案就是我在前面提到过的条件更新方式把状态判断放在UPDATE语句的WHERE条件里数据库层面保证原子性。加上之后第二个请求执行更新时发现status已经不是1了更新行数为0直接抛出异常问题彻底解决。7.2 Vue打包后刷新页面404前端路由用的history模式开发阶段一切正常打包部署到Nginx后点击页面内跳转没问题但手动刷新就会出现404。原因是history模式的路由是前端控制的Nginx不知道这个路径应该交给前端处理于是按文件路径去找找不到就404了。解决方案是在Nginx配置中添加try_files指令将所有非静态文件的请求都重写到index.html让前端路由接管。配置如下location / { try_files $uri $uri/ /index.html; }加了这一行配置刷新404的问题就消失了。这个坑在前端路由部署时非常经典十有八九的团队都会遇到。7.3 前端请求跨域问题开发模式下前端跑在8080端口后端跑在8081端口浏览器直接请求就会出现跨域报错。我在后端配置了全局CORS过滤器允许指定来源的跨域请求同时设置允许携带凭证这样前端Axios请求就能正常携带Token了。但部署到服务器后前端和后端同域访问通过Nginx代理就不存在跨域问题了。所以我在配置CORS时特意做了区分只在开发环境开放宽松的跨域配置生产环境关闭防止跨域配置过于宽松带来的安全隐患。7.4 常见问题速查表问题现象可能原因排查方法登录报错“用户不存在或密码错误”数据库密码未加密存储或加密算法不一致检查用户表password字段是否BCrypt加密后的结果新增货品保存失败货品编码重复检查goods_code是否已存在是否满足唯一约束报表数据为0查询时间范围不正确检查SQL中时间字段与参数类型是否匹配库存盘点差异过大盘点单录入时漏扫货品核对盘点单中货品数量与实物数量附件上传失败Nginx client_max_body_size限制在Nginx配置中调整上传文件大小限制8. 项目总结与个人体会这套珠宝首饰进销存管理系统从需求梳理到上线运行前后历时大约三个月。整体评估SpringBoot Vue Java这套技术栈在中小型管理系统中确实是效率与稳定性的最佳平衡点SpringBoot让后端开发摆脱了大量繁琐配置Vue让管理后台的交互体验上了一个台阶Java的类型安全与生态积累则为业务逻辑的严谨性提供了保障。对我个人来说感触最深的一点是开发这类业务系统真正的难点从来不是某个技术点有多深而是对业务场景的理解是否足够到位。比如珠宝行业的“一物一码”、锁库存的时间窗口、盘点差异的审批流这些设计决策如果不深入到门店实际运营中凭空想是想不出来的。技术可以靠资料学习和框架迁移快速提升但对业务的理解只能靠深入一线去沉淀两者缺一不可。如果后续还有机会在这个项目上扩展我觉得可以从三个方向继续深耕一是增加移动端适配让库存盘点和销售开单可以在平板上操作门店使用会更灵活二是引入更智能的报表分析比如按客户复购率、滞销货品占比等维度做经营建议三是考虑对接电子发票和电商平台的库存同步进一步拓展系统的应用边界。当然这些都是后话了先把现有的系统用好、用稳才是当下的重点。本文还有配套的精品资源点击获取 基于SpringBoot+Vue+Java的珠宝进销存系统设计与实践
简介一份docx格式的毕业设计论文完整阐述基于Java与Vue框架的珠宝首饰进销存管理系统的设计与实现主要面向计算机相关专业学生、毕业设计选题者以及珠宝行业信息化开发人员。系统采用B/S架构与MySQL数据库设计管理员与操作员两类角色核心模块涵盖首页、个人中心、操作员管理、总库库存管理、出库单管理、入库单管理、门店管理及销售单管理清晰展示了进销存业务的完整数字化流转过程。压缩包内仅含1个docx文档大小3.69MB文档内容从摘要、绪论到需求分析、系统设计、数据库设计及测试环节均有详实论述可作为系统开发与论文写作的双重参考。目前已有190人学习下载尤其适合需要借鉴J2EE/Vue技术栈完成课程设计或毕业项目的读者能够帮助快速梳理功能架构与实现思路。1. 项目起点为什么珠宝行业需要一套专属的进销存系统先交代一下背景。我接触这个项目时客户是一家做珠宝零售的线下门店主营黄金、钻石、翡翠三类货品门店不大但SKU管理却比普通百货零售复杂得多。问题主要体现在三个层面一是珠宝货品有唯一的证书编号、克重、成色、工费每件货品几乎是“一物一参数”不能像卖衣服那样按尺码批量入库二是拿货、退换、调拨、旧金回收这些业务混在一起传统Excel表格早就不够用了三是老板要的报表不是简单的进销存流水而是要按货品类别、时间段、销售渠道去算毛利还要追踪每一件货品的实时状态——在库、锁定、已售、返修、调拨中。当时市面上通用的进销存软件我也评估过功能齐全但过于臃肿且针对珠宝行业的“一物一码”和旧料换新业务支持很弱定制改造的成本比从零开发还高。经过几轮沟通最终确定了用SpringBoot Vue Java这套主流技术栈从零搭建一套面向珠宝门店的进销存管理系统。这个项目本身也作为课题写成了论文标题就叫“springboot Vue java珠宝首饰进销存管理系统”。那为什么选这套技术栈而不是别的SpringBoot在Java后端领域已经是事实标准生态成熟招人容易后续维护不会卡脖子Vue作为前端框架上手快、响应式交互做得好单据录入这类高频操作页面的体验能够做得比较细腻而Java本身跨平台、稳定适合做进销存这种对数据一致性要求高的业务系统。整套方案在中小型企业管理软件里属于性价比最稳的选型。这套系统最终能做什么我直接列一下核心能力货品档案管理含证书编号、克重、成色、图片、采购入库、销售出库、门店调拨、旧金回收置换、库存盘点、毛利统计、会员管理、员工权限控制。后续所有章节我都会围绕这些功能模块展开讲设计思路和实操细节。2. 整体架构设计与技术选型解析2.1 前后端分离为什么要拆开而不是用传统模板早期的Java Web项目页面和服务端是耦合在一起的用JSP或者Thymeleaf渲染页面开发效率低前后端分工也不清晰。这个项目我直接采用前后端分离架构后端只提供JSON接口前端用Vue独立工程开发通过HTTP调用接口完成所有交互。这样做的直接好处有三个。第一前后端可以并行开发后端定义好接口文档后前端人员不需要等服务端代码写完就能开始写页面第二系统后续如果要对接微信小程序或者平板端前端代码可以复用Vue组件只需要新增一个小程序端工程后端接口完全不用动第三部署时可以分开处理前端静态资源丢Nginx后端打成Jar包独立运行排查问题时边界也清晰。后端技术选型如下SpringBoot 2.7.x稳定版本兼容性好不追新避免版本太高导致的一些第三方组件适配问题。MyBatis-Plus单表CRUD基本不用写SQL复杂统计自己写XML效率和可控性兼顾。MySQL 8.0数据存储珠宝门店的数据量完全够用。Redis做登录Token缓存、字典数据缓存、热点数据加速。Sa-Token轻量级的登录认证框架比Shiro配置简单比Spring Security的门槛低很多适合中小型管理系统。前端选型Vue 2.6 Element UIVue 2的生态最稳Element UI的表格、表单、弹窗组件开箱即用非常适合管理后台这种强交互、重表单的场景。Axios统一封装HTTP请求拦截器处理Token附加和异常提示。ECharts用于首页的数据看板做月度销售趋势、品类占比等图表。2.2 为什么不用微服务单应用够吗我在设计初期也想过要不要拆微服务毕竟现在简历上写微服务是加分项。但冷静下来分析珠宝门店系统用户量撑死几十号人并发量极低业务边界也没有复杂到需要独立拆分的程度。强行上微服务只会引入分布式事务、服务注册发现、配置中心这些复杂度对实际业务毫无帮助。最终采用了单应用多模块的Maven结构按功能拆分成几个modulecommon通用工具、system用户权限、goods货品中心、stock库存交易、report报表统计。这样既保持了代码层面的逻辑隔离又不引入分布式复杂度。如果将来业务量真的增长了再按module边界拆成微服务也不迟这是成本最低的演进路径。提示做中小型管理系统的架构选型核心原则是“按业务量级做适配”不要为了技术而技术。单体应用撑不住的场景通常是成千上万的并发请求珠宝门店的管理系统完全不在这个范畴内。3. 数据库设计珠宝库存的“一物一码”核心模型3.1 核心表结构与字段设计数据库设计是整个系统最关键的部分珠宝行业的特殊性在表结构上体现得非常明显。普通商品进销存按SKU汇总即可但珠宝必须做到“一物一码”也就是每一件货品都有一条独立的记录从入库到销售全程可追踪。这一点决定了主表的设计思路。以货品表为例核心字段如下CREATE TABLE goods_info ( id bigint(20) NOT NULL AUTO_INCREMENT, goods_code varchar(32) NOT NULL COMMENT 货品唯一编码, goods_name varchar(64) NOT NULL COMMENT 货品名称, category varchar(16) NOT NULL COMMENT 品类黄金/钻石/翡翠/K金, material varchar(16) DEFAULT NULL COMMENT 材质, weight decimal(10,3) DEFAULT NULL COMMENT 克重, gold_price decimal(10,2) DEFAULT NULL COMMENT 金料单价, work_fee decimal(10,2) DEFAULT NULL COMMENT 工费, cert_no varchar(64) DEFAULT NULL COMMENT 鉴定证书编号, stone_name varchar(32) DEFAULT NULL COMMENT 主石名称, stone_weight decimal(10,3) DEFAULT NULL COMMENT 主石重量, cost_price decimal(10,2) NOT NULL COMMENT 成本价, sale_price decimal(10,2) NOT NULL COMMENT 销售标价, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1在库 2锁定 3已售 4调拨中 5返修, supplier_id bigint(20) DEFAULT NULL COMMENT 供应商ID, warehouse_id bigint(20) DEFAULT NULL COMMENT 所属门店/仓库, create_time datetime NOT NULL, update_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_goods_code (goods_code), KEY idx_category (category), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT货品档案表;这张表的设计要点在于goods_code这个唯一编码它相当于货品的“身份证号”。门店入库时每件货品生成一个唯一编码可以是证书号入库日期的组合也可以直接用雪花算法生成后续所有表都通过这个编码关联货品确保全程可追溯。权重字段全部用decimal尤其是克重精确到小数点后三位这是珠宝行业的硬性要求。黄金克重差0.01克在实时金价下就有几块钱的出入用float或者double做金额计算会累积误差这在财务上是绝对不能接受的。3.2 库存流水表进销存系统的“总账本”除了货品档案表库存流水表是整个系统的账本核心。每次采购入库、销售出库、调拨出入库、盘点调整都会在这个表里追加一条流水记录。库存表只存当前实时数量流水表存所有的历史变动两者配合既能查询现状也能回溯历史。CREATE TABLE stock_flow ( id bigint(20) NOT NULL AUTO_INCREMENT, goods_code varchar(32) NOT NULL COMMENT 货品编码, flow_type tinyint(4) NOT NULL COMMENT 流水类型1采购入库 2销售出库 3调拨出库 4调拨入库 5盘点盘盈 6盘点盘亏 7其他, warehouse_id bigint(20) NOT NULL COMMENT 仓库ID, quantity int(11) NOT NULL DEFAULT 1 COMMENT 变动数量, before_stock int(11) NOT NULL COMMENT 变动前库存, after_stock int(11) NOT NULL COMMENT 变动后库存, order_no varchar(32) DEFAULT NULL COMMENT 关联单号, remark varchar(255) DEFAULT NULL COMMENT 备注, create_by varchar(32) NOT NULL COMMENT 操作人, create_time datetime NOT NULL COMMENT 操作时间, PRIMARY KEY (id), KEY idx_goods_code (goods_code), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT库存流水表;这里我要特别强调一个编码约定所有库存变动业务必须在同一个数据库事务里完成“写流水更新库存”两步操作任何一步失败都要整体回滚。不然就会出现流水记录和实际库存对不上的情况后期对账会异常痛苦。这个是我在开发过程中踩过坑后强化的设计约束。4. 核心功能模块实现从采购到销售的全链路4.1 采购入库最容易被忽视的批量处理细节采购入库这个模块看起来就是填一张入库单选供应商、扫货品、填价格、保存。但实际落地时有个非常关键的体验问题需要处理一次采购几十件货品怎么做才能不让人烦躁如果按传统表单一行一行录录一件货品要填十几个字段50件货品就是几百次鼠标点击操作员容易崩溃。我的做法是做了一个“批量录入面板”支持两种方式一种是逐件录入表单自动清空光标回到第一个输入框连续录入能力要顺滑另一种是Excel批量导入系统提供标准模板操作员在门店电脑上填好后再上传。这两种方式覆盖了大多数场景实测下来50件货品的入库操作时间从原来的半个多小时压缩到十分钟以内。采购入库时还要自动完成一个动作根据金价行情和工费计算出成本价。门店采购黄金时成本价金料重量×当日金价工费这个计算逻辑在入库时就要算好并写入货品表后续毛利统计直接基于这个成本价不再重复计算。4.2 销售出库挂单、锁库存与优惠折扣销售出库是门店每天使用频率最高的功能设计的流畅度直接影响收银效率。这里最核心的操作是“挂单”和“锁库存”。挂单是什么意思顾客可能同时看中两三件货品犹豫要哪件或者要等家里人拍板。这时候收银员先把意向货品锁住避免被其他顾客买走。这个锁库存操作在系统里就叫“锁定”锁定的货品在库状态从1变为2。锁定时长为30分钟超时自动释放不然一件货品被锁住半天其他顾客就看不了了。锁库存的实现也不复杂就是在货品状态上做一个原子更新// 锁定货品加条件 status 1在库防止并发下重复锁定 boolean locked goodsInfoService.update( new LambdaUpdateWrapperGoodsInfo() .eq(GoodsInfo::getGoodsCode, goodsCode) .eq(GoodsInfo::getStatus, 1) .set(GoodsInfo::getStatus, 2) ); if (!locked) { throw new ServiceException(货品已被锁定或售出请刷新后重试); }这个条件更新的写法很关键它保证了并发场景下同一件货品不会被两个收银员同时锁定。如果不加status1这个条件两个请求同时更新就会出现超卖问题。这个场景在珠宝门店虽然并发不高但也是数据一致性的基本功。销售开单时还要支持会员折扣、满减、旧金抵扣这些促销逻辑。优惠金额的计算我放在后端统一处理前端只传业务参数避免不同终端计算结果不一致。销售完成后货品状态变为已售同时自动扣减对应门店的库存写入销售流水。4.3 库存盘点用状态机管住“差异审批”盘点这个功能珠宝门店的刚需程度甚至比销售还高。黄金这类高价值货品每天下班都要盘点账实不符是老板最担心的事。系统设计了“盘点单→盘点录入→差异生成→审核调整”的流程。盘点的核心是盘点差异的处理。盘点单创建后系统会生成当前账面库存列表操作员在手持终端上扫码或手动录入实际库存提交后系统自动比对账面和实盘数据有差异的货品生成差异明细。这里有个设计细节差异并不会直接修改库存而是先进入“待审核”状态由店长或财务确认后执行盘盈或盘亏调整。为什么要加这个审核环节因为盘点差异可能不是真的少了货可能是录错了货品编号、放错了仓位直接改库存会把问题掩盖掉。先审核确认再调整库存同时写入调整流水和备注这样每一笔差异都有迹可循。4.4 毛利统计按时间段、品类、渠道多维度报表报表模块直接决定老板对这个系统的满意度。老板看得最多的不是库存数而是赚了多少钱。毛利统计的核心SQL要能按时间段、品类、销售渠道进行多维度组合查询。实际实现时销售单表和销售明细表分开存储。销售单记录整笔交易的订单信息包括订单号、客户、应付金额、实付金额、优惠金额、销售渠道销售明细记录每一件售出货品的货品编码、成本价、成交价。毛利实付金额合计-成本金额合计。为了让报表查询高效我用了MyBatis-Plus的LambdaQueryWrapper配合GroupBy不需要写复杂的存储过程// 按品类统计毛利 ListMapString, Object result saleDetailMapper.selectMaps( new QueryWrapperSaleDetail() .select(goods_category AS category, SUM(actual_amount - cost_price) AS profit, COUNT(*) AS sale_count) .between(sale_time, startDate, endDate) .groupBy(goods_category) );这里的字段别名要注意MyBatis-Plus的select传入的是SQL片段不能直接用Lambda表达式我最初在这里踩过坑老是写错后来统一改用字符串方式。注意财务相关字段的加减运算Java后端一定要用BigDecimal不能直接用double。数据库端金额字段用decimal(10,2)Java实体类用BigDecimal类型映射防止浮点数精度问题在统计报表中放大。5. 权限设计与数据安全5.1 基于RBAC的权限模型门店系统里有老板、店长、收银员、库管几种角色不同角色的操作权限差异很大。收银员只能操作销售出库和查看库存店长可以审核盘点差异和调拨单老板可以看到全部报表和毛利数据。权限模型采用经典的RBAC基于角色的访问控制设计用户表、角色表、菜单权限表、用户角色关联表、角色菜单关联表五张表。后端的权限控制通过Sa-Token的注解实现前端则通过动态路由控制菜单显示和按钮级权限。后端的核心代码如下SaCheckPermission(sale:order:create) PostMapping(/sale/order) public Result createSaleOrder(RequestBody Validated SaleOrderDTO dto) { // 只有拥有销售开单权限的用户才能访问 saleService.createOrder(dto); return Result.success(); }前端动态路由的思路是用户登录后后端返回该用户有权限的菜单列表前端遍历菜单列表动态注册路由。这样在界面上收银员看不到报表菜单老板看不到收银员的操作界面细节权限在前后端双重校验。5.2 密码存储与登录安全密码存储不能明文这是基本要求。系统使用BCrypt算法加密存储密码这个算法的特点是一次一密即使两个用户密码相同加密后的密文也不同防彩虹表攻击能力比MD5强得多。登录认证使用Sa-Token的Token机制登录成功后将Token缓存在Redis中设置有效期用户操作时自动续期。还有一点容易被忽略的是操作日志。像删除货品、调整库存、修改价格这类敏感操作必须记录操作人、操作时间、操作前后值。我实现了一个简单的操作日志切面通过AOP拦截标注了OpLog注解的方法自动记录日志OpLog(module 库存管理, type 盘点调整, desc 盘点盘亏调整) PostMapping(/stock/adjust) public Result stockAdjust(RequestBody StockAdjustDTO dto) { // ... }这个切面在方法执行后自动记录日志不需要在每个Service方法里手动写日志逻辑。后续查账、追责、审计都有据可依。提示珠宝门店系统虽然不像互联网应用那样面临大规模攻击但涉及资金和高价值货品的数据安全必须严谨。操作日志这个功能千万不能省宁可多记录不要等出了问题才发现无据可查。6. 部署上线与性能优化实践6.1 环境准备与部署流程项目部署我采用的是经典的单机部署方案一台4核8G的云服务器就能带起来整个系统部署结构如下Nginx监听80/443端口托管前端Vue构建产物同时反向代理后端接口后端SpringBoot应用以Jar包方式运行通过systemd守护进程管理MySQL和Redis用Docker部署方便版本管理和备份。后端启动时的JVM参数我做了针对性优化java -Xms512m -Xmx1024m -XX:UseG1GC -jar jewelry-erp.jar-Xms和-Xmx控制堆内存大小4G内存的机器给JVM分配1G完全够用G1垃圾回收器适合这种多线程、中低并发的应用场景响应时间更稳定。前端构建时也有几个值得注意的点。Vue项目的publicPath要设置为相对路径或绝对路径的根目录不能默认的/否则部署到子目录或者用域名访问会出现静态资源404的问题。打包产物的gzip压缩可以交给Nginx的gzip模块处理不用在build阶段压缩减少构建时间。6.2 接口性能优化让报表不再卡顿系统上线后用户反馈最多的性能问题集中在报表模块尤其是按年统计毛利的时候页面要等将近十秒才出数据。排查后发现原因是销售明细表数据量到了几十万条关联查询时没有走索引而且统计SQL一次性加载了所有明细数据到内存中再聚合。针对这个问题做了两个优化。第一在销售明细表的sale_time、goods_category字段上加了联合索引让时间段过滤走索引而非全表扫描。第二把统计逻辑从“先查明细再内存聚合”改为“数据库端直接聚合”减少数据传输量。优化后的SQL执行时间从8秒降到了0.3秒左右效果立竿见影。这给团队一个教训报表类的统计查询尽量让数据库完成聚合计算而不是把明细数据拉到应用层再算。数据库存在的意义就是处理这类运算别浪费它的能力。6.3 数据备份策略进销存系统的数据安全绝对优先级最高数据库必须定期备份。我的方案是每天凌晨2点执行一次mysqldump全量备份保留最近30天的备份文件同时每天将备份文件同步到异地存储。这样一来即使服务器硬盘损坏也能在半小时内恢复数据。# 每天凌晨2点执行备份 0 2 * * * mysqldump -u root -pJewelry2024 jewelry_erp /backup/jewelry_erp_$(date \%Y\%m\%d).sql # 异地同步 0 3 * * * rclone sync /backup oss:bucket-backup/jewelry-erp数据备份的恢复演练也很重要。我在测试环境做过一次模拟恢复从备份文件恢复到启动可用大约需要10分钟。这个恢复时效对珠宝门店来说完全可接受真遇到服务器故障也不至于慌乱。7. 遇到过的坑与高频问题排查记录实际开发过程中踩过的坑不少挑几个典型的分享一下希望能帮后来者少走弯路。7.1 并发锁库存时出现数据不一致这是我最早遇到的一个问题。最初锁库存的逻辑是先查询货品状态再在代码里判断然后执行更新。结果测试时发现两个账号同时操作同一件货品两个请求都读到了“在库”状态也都在代码里通过了判断最后两笔销售单竟然都开成功了。这就是典型的“先读后写”并发问题解决方案就是我在前面提到过的条件更新方式把状态判断放在UPDATE语句的WHERE条件里数据库层面保证原子性。加上之后第二个请求执行更新时发现status已经不是1了更新行数为0直接抛出异常问题彻底解决。7.2 Vue打包后刷新页面404前端路由用的history模式开发阶段一切正常打包部署到Nginx后点击页面内跳转没问题但手动刷新就会出现404。原因是history模式的路由是前端控制的Nginx不知道这个路径应该交给前端处理于是按文件路径去找找不到就404了。解决方案是在Nginx配置中添加try_files指令将所有非静态文件的请求都重写到index.html让前端路由接管。配置如下location / { try_files $uri $uri/ /index.html; }加了这一行配置刷新404的问题就消失了。这个坑在前端路由部署时非常经典十有八九的团队都会遇到。7.3 前端请求跨域问题开发模式下前端跑在8080端口后端跑在8081端口浏览器直接请求就会出现跨域报错。我在后端配置了全局CORS过滤器允许指定来源的跨域请求同时设置允许携带凭证这样前端Axios请求就能正常携带Token了。但部署到服务器后前端和后端同域访问通过Nginx代理就不存在跨域问题了。所以我在配置CORS时特意做了区分只在开发环境开放宽松的跨域配置生产环境关闭防止跨域配置过于宽松带来的安全隐患。7.4 常见问题速查表问题现象可能原因排查方法登录报错“用户不存在或密码错误”数据库密码未加密存储或加密算法不一致检查用户表password字段是否BCrypt加密后的结果新增货品保存失败货品编码重复检查goods_code是否已存在是否满足唯一约束报表数据为0查询时间范围不正确检查SQL中时间字段与参数类型是否匹配库存盘点差异过大盘点单录入时漏扫货品核对盘点单中货品数量与实物数量附件上传失败Nginx client_max_body_size限制在Nginx配置中调整上传文件大小限制8. 项目总结与个人体会这套珠宝首饰进销存管理系统从需求梳理到上线运行前后历时大约三个月。整体评估SpringBoot Vue Java这套技术栈在中小型管理系统中确实是效率与稳定性的最佳平衡点SpringBoot让后端开发摆脱了大量繁琐配置Vue让管理后台的交互体验上了一个台阶Java的类型安全与生态积累则为业务逻辑的严谨性提供了保障。对我个人来说感触最深的一点是开发这类业务系统真正的难点从来不是某个技术点有多深而是对业务场景的理解是否足够到位。比如珠宝行业的“一物一码”、锁库存的时间窗口、盘点差异的审批流这些设计决策如果不深入到门店实际运营中凭空想是想不出来的。技术可以靠资料学习和框架迁移快速提升但对业务的理解只能靠深入一线去沉淀两者缺一不可。如果后续还有机会在这个项目上扩展我觉得可以从三个方向继续深耕一是增加移动端适配让库存盘点和销售开单可以在平板上操作门店使用会更灵活二是引入更智能的报表分析比如按客户复购率、滞销货品占比等维度做经营建议三是考虑对接电子发票和电商平台的库存同步进一步拓展系统的应用边界。当然这些都是后话了先把现有的系统用好、用稳才是当下的重点。本文还有配套的精品资源点击获取