简介面向物流与供应链行业的汽车配件管理系统源代码围绕整车运输、仓储管理、货运代理、售后备件及包装出口等核心业务提供一套可运行的企业级 Java 解决方案。技术栈以 Spring Boot 为主融合 SSM 与 SSH 经典架构并预留微服务、Docker 等扩展思路适合 Java 开发者、供应链项目学习者用于系统设计与二次开发。资源包为 rar 压缩格式共 2016 个文件、约 311.82MB其中包含 866 个 js、409 个 html、354 个 xml、139 个 css、106 个 java 等前端页面、后端逻辑与配置脚本齐全。从内容预览可见集成了 Ext、Bootstrap 等前端框架代码中还有 sql、properties、md 等说明与配置便于还原初始化数据、理解模块划分和部署流程已有 55 人学习可作为课程设计、毕业设计或实际供应链系统开发的参考基线。 做汽配管理系统这个项目说实话最初是帮朋友的一个汽修门店处理库存混乱的问题。配件种类多、批次杂、供应商多加上进出库频繁靠Excel根本管不住。后来我把这个系统完善成了一个通用版本并且把源码整理出来了。这篇文章就把整个项目的设计思路、核心模块的实现方式、以及我在开发过程中踩过的坑一次性说透希望对准备做类似管理系统的朋友有帮助。1. 项目整体设计与模块规划1.1 汽配行业的业务痛点决定了系统边界做开发的第一步不是写代码而是搞清楚业务到底要解决什么问题。汽配管理和普通商品库存管理有本质区别普通零售商品SKU相对固定但汽车配件有极强的属性维度——同一个配件可能适配多种车型、多个年份还要区分原厂件、品牌件、副厂件甚至同一品牌下还有不同批次。我调研了几家门店后发现日常最痛的点集中在三个地方一是配件的入库出库记录混乱经常出现账实不符二是库存低于安全线时没人知道等客户要货才发现没货三是供应商信息分散采购时找不到历史报价。所以这个系统最终没有做成大而全的ERP而是聚焦在进、销、存、报这四个核心环节。1.2 技术选型为什么不选PHP也不选纯前端方案技术栈选择上我最终定了 Spring Boot 2.x MyBatis MySQL Vue 的前后端分离方案。这里有几个实际考量后端用 Spring Boot因为它的生态成熟事务管理、权限校验这些关键能力都有现成方案不需要自己造轮子。持久层用 MyBatis 而不是 JPA原因是汽配行业查询条件极其灵活——按车型查、按OE号查、按品牌查、组合条件查MyBatis 的动态 SQL 在这种场景下优势太明显了SQL 写起来可控性更强。前端用了 Vue 2 Element UI组件库现成表格、表单、弹窗这些后台管理界面常用的东西拿来就能用开发效率高。如果只做后端管理不涉及移动端这个组合完全够用。1.3 源码目录结构分层清楚才能好维护项目源码的核心结构我做了严格的分层这也是我反复调整后觉得最舒服的组织方式controller 层只做参数接收和返回结果封装service 层业务逻辑全部放在这里事务注解都加在 service 方法上mapper 层对应 MyBatis 的接口定义SQL 写在 XML 里entity 层数据库表对应的实体类vo 层专门给前端返回的视图对象避免直接把实体暴露出去common 层统一返回结果、异常处理、工具类这个结构看起来常规但实际开发中很多人会在 controller 里写业务导致后期维护非常痛苦。把事务边界放在 service 层是最保险的做法。2. 数据库表设计与关键字段解析2.1 配件基础信息表唯一索引是关键配件表是整个系统的基础我设计了这样几个核心字段配件编码parts_no全局唯一、配件名称、品牌、适配车型、OE号原厂零件号、单位、采购价、零售价、安全库存阈值。这里最重要的一点是给配件编码和OE号建立联合唯一索引。汽配行业一个常见场景是同一配件的OE号在不同品牌下是相同的如果允许多条记录入库时就无法判断是新增还是更新数据很快就会出现大量重复。我实测过没有唯一索引的情况下录入人员一个疏忽同一个火花塞就能建出三条记录库存分别存在三条记录里查询和统计全乱套。适配车型这个字段我用的是JSON格式存储比如[丰田-卡罗拉-2017-1.2T, 丰田-雷凌-2017-1.2T]。在MySQL 5.7以上版本里JSON类型可以支持查询但实际使用时我的建议是车型适配信息单独建一张关系表因为车型匹配太频繁了JSON字段不方便走索引。2.2 库存流水表这是账实相符的根基库存系统最容易犯的错误是直接在库存表上做加减一旦数据错了没有任何追溯办法。我的做法是设计一张库存流水表stock_record每一条入库、出库、盘点调整、报损都记录一条流水包含配件ID、变动数量正数为入、负数为出、变动类型、关联单号、操作人、操作时间、备注。当前库存数量不直接存储而是通过流水表实时汇总计算。当然当数据量大到千万级时实时汇总会变慢这时候可以在配件表里冗余一个当前库存字段每次流水变动时同步更新两者配合使用。流水表保证可追溯冗余字段保证查询性能。2.3 供应商与采购相关表供应商表比较简单维护名称、联系人、电话、地址。但采购价必须放在供应商报价表里而不是直接写在配件表上。原因很现实同一配件在不同供应商的价格不一样而且价格会浮动。做采购单的时候系统要能自动带出该供应商最近一次对该配件的报价这个逻辑在二开时经常用到。3. 核心功能模块的实现拆解3.1 入库操作的业务闭环入库单的流程是这样的创建入库单关联供应商→ 添加入库明细选择配件、填写数量、单价→ 确认入库 → 系统生成库存流水 → 更新配件当前库存 → 更新该供应商对该配件的最新报价。这里有一个特别容易踩坑的细节确认入库这个动作必须放在一个事务里。如果先更新了配件库存再写流水的时候报错事务回滚就来得及。但如果有人把两步拆开或者用了不同的数据源那账实不符就是迟早的事。我在代码里明确要求入库单的状态只能从草稿变到已入库不能用更新操作反复修改这样做的目的就是保证流水一旦生成就不可篡改。3.2 出库操作与先进先出的取舍出库销售或领用逻辑上比入库复杂一点。严格来说汽配行业应该做批次管理按先进先出FIFO的原则扣减库存因为不同批次的配件可能存在质量差异。但做过实际项目都知道批次管理会让系统复杂度上一个台阶——每个配件要分成多条批次记录出库时要按批次依次扣减报表统计也要按批次拆分。我在这套系统里做的是单批次加权平均模式也就是不区分批次库存数量统一管理出库时只做总量扣减。这样做的原因很简单大部分小型汽配门店和维修厂并不需要精确的批次追溯他们更关心总量够不够、剩多少。如果你的业务确实需要批次管理建议在流水表上加一个批次号字段将来扩展的时候可以平滑升级。3.3 低库存预警的实现方式低库存预警是一个看着简单但讲究细节的模块。按配置项表达当配件当前库存量小于等于安全库存阈值时系统生成预警记录。我选择用定时任务扫描方式每天凌晨跑一次全量扫描把低于阈值的配件写进预警表。为什么不用实时检测因为实时检测需要每次库存变动后都判断一次不仅增加写操作的开销而且容易漏掉批量导入和盘点调整这类旁路操作。定时全量扫描简单可靠代价是预警有最多一天的延迟这个延迟在汽配场景下完全能接受。预警列表的展示要把配件编码、名称、当前库存、安全库存、最近一次入库时间一起展示出来方便采购人员判断是马上补货还是可以等等。3.4 报表统计模块的设计报表是老板最关心的部分但也是最容易做复杂的部分。我做了三个核心报表入库明细报表按时间、供应商、配件维度统计、出库明细报表按时间、配件维度统计、库存汇总报表按品牌、分类汇总当前库存金额。报表实现的核心思路是查询走独立SQL不复用业务查询的Mapper。因为业务查询要分页报表要聚合两者混在一起不仅性能互相拖累代码也乱。我的做法是报表模块单独建一套MapperSQL直接写聚合语句用GROUP BY按维度归纳。4. 实际操作中的踩坑记录与排查方案4.1 并发扣减库存导致库存变负数这个坑几乎每个做库存系统的人都会遇到。场景是这样的两个员工同时卖出同一个配件系统同时读到库存还有1个各自扣减1个最后库存变成了-1。这就是经典的并发问题。解决方案是使用乐观锁在配件表的库存字段更新时加一个 where 条件stock_count #{减少数量}并且更新语句影响行数为0时说明库存不足主动抛异常让事务回滚。这条SQL长这样UPDATE parts SET stock_count stock_count - #{quantity}, update_time NOW() WHERE id #{partsId} AND stock_count #{quantity}这种方式比程序里先查再判断更可靠因为判断和更新合并成了一步原子操作。我也试过用Redis分布式锁但在这个业务量级下没有必要SQL层面的条件更新已经足够。4.2 模糊查询性能灾难LIKE 前面加%汽配系统很常用的一个功能是配件查询用户习惯输入刹车、丰田 卡罗拉 前刹车片这种关键词。最初我在配件名称字段上用了LIKE %关键词%配件表几千条数据时没事但数据涨到几万条时每次查询都要全表扫描页面明显卡顿。后来我做了两个优化一是把最常用的筛选条件品牌、分类、适配车型改为下拉框精确匹配走索引二是名称和OE号查询改用全文索引。MySQL自带的全文索引在处理中文分词时不完美但对这种简单包含匹配已经够用了。实测优化后百万级数据量下的查询从1秒多降到了100毫秒以内。4.3 事务边界混乱导致的数据不一致这是个非常隐蔽的问题。早期我的代码里有个习惯service 方法 A 调用了 service 方法 B两个方法都加了Transactional注解。Spring 的默认传播行为是 REQUIRED正常情况下会合并成同一个事务这没问题。但问题是如果 B 方法被同类内部调用this.B()这时候事务注解根本不生效因为Spring的事务是基于代理对象实现的内部调用走的是原始对象。这个坑排查起来很费劲。我当时遇到的情况是入库单确认后明明报了异常但库存还是被改了。查了很久才发现是 service 内部自调用导致事务失效。解决方案有两个一是把需要事务保证的方法拆到不同的类里通过注入调用二是使用AopContext.currentProxy()手动获取代理对象。我在代码注释里特意标注了这个坑防止后来维护的人再踩。4.4 数据初始化与历史数据迁移拿源码搭建系统后很多人第一批录入配件数据时会发现效率极低。我的建议是做一个Excel导入功能这是必须的。导入模板设计成三张sheet配件信息、供应商信息、初始库存。导入过程要有校验反馈哪些行导入失败失败原因是什么配件编码重复、必填字段为空、数量不是数字一次性给出完整报告。实际用下来导入5000条配件数据加初始库存两三分钟就能完成比人工录入快了一个数量级。5. 源码部署与二次开发建议5.1 本地环境启动流程拿到源码之后部署步骤是固定的照着走一般不会出问题安装JDK 8以上版本配置JAVA_HOME环境变量安装MySQL 5.7或8.0执行项目里的sql/init.sql脚本初始化数据库表结构和基础数据修改application.yml里的数据库连接信息包括URL、用户名、密码后端项目用 Maven 构建mvn clean package -DskipTests然后java -jar启动前端项目安装依赖npm install开发模式运行npm run serve有一个部署时容易忽略的问题前端请求后端的接口地址是写在前端配置文件里的比如.env.development文件不是写死在代码里。部署时一定要改对地址不然前端能起来但接口全报404。我见过不止一个人卡在这一步。5.2 安全配置修改默认密码是底线源码包里默认的账号密码是 admin/admin123这个只是为了方便本地测试。真正上线使用前必须做三件事强制修改管理员密码、关闭演示模式的调试接口、给数据库设置独立账号而不是用root直连。权限控制方面这套系统做了最基础的三角色划分管理员、采购员、库管员。管理员可以配置用户和查看所有报表采购员只能操作采购模块库管员负责出入库操作。如果你需要更细粒度的权限比如只允许查看自己负责的门店数据可以在用户表加门店字段再做过滤这个扩展点已经预留了。5.3 值得扩展的方向源码目前的完成度覆盖了核心的进销存但如果要投入实际生产环境我建议优先扩展这几个方向第一个是扫码枪支持。汽配仓库里大量操作是扫码作业前端在配件编码输入框监听回车事件扫码枪本质上是键盘输入回车的设备只要焦点在输入框里扫码后自动触发查询或录入不算复杂但很实用。第二个是移动端审批。采购单和出库单的审批如果能在手机上完成对管理者的体验提升很明显。可以不做原生App用H5页面配合消息推送就够用。第三个是多仓支持。如果业务从一个门店扩展到多个分店需要增加仓库表库存数量要按仓库维度拆开库存流水也要增加仓库ID字段。这个改动会涉及表结构和业务逻辑的多处调整建议在设计初期就预留字段哪怕暂时不启用。第四个是配件图片管理。汽配查询时能看图确认配件外观可以大幅减少发错货的情况。实现上可以用OSS存储图片数据库里存URL前端表格加图片列预览即可。6. 最后说几句实在话这套系统写下来最有价值的收获不是功能堆得有多全而是我明白了管理类软件的核心在于数据闭环。入库有单、出库有据、库存有流水、预警有提醒每一步都在一个闭环里转数据才不会烂掉。凡是数据对不上的项目十有八九是流程有缺口、代码有绕过的路。如果你准备拿这套源码做二次开发或者学习我的建议是先完整读一遍 service 层的代码和 SQL 文件把数据流梳理清楚再动手改功能。很多人一上来就改前端页面结果后端的库存逻辑没看懂改完前端发现数据还是不对来回折腾浪费时间。把进销存的底层逻辑吃透后面不管接什么管理系统的需求心里都是有底气的。本文还有配套的精品资源点击获取
基于Spring Boot的汽配进销存管理系统设计与实现全解析
简介面向物流与供应链行业的汽车配件管理系统源代码围绕整车运输、仓储管理、货运代理、售后备件及包装出口等核心业务提供一套可运行的企业级 Java 解决方案。技术栈以 Spring Boot 为主融合 SSM 与 SSH 经典架构并预留微服务、Docker 等扩展思路适合 Java 开发者、供应链项目学习者用于系统设计与二次开发。资源包为 rar 压缩格式共 2016 个文件、约 311.82MB其中包含 866 个 js、409 个 html、354 个 xml、139 个 css、106 个 java 等前端页面、后端逻辑与配置脚本齐全。从内容预览可见集成了 Ext、Bootstrap 等前端框架代码中还有 sql、properties、md 等说明与配置便于还原初始化数据、理解模块划分和部署流程已有 55 人学习可作为课程设计、毕业设计或实际供应链系统开发的参考基线。 做汽配管理系统这个项目说实话最初是帮朋友的一个汽修门店处理库存混乱的问题。配件种类多、批次杂、供应商多加上进出库频繁靠Excel根本管不住。后来我把这个系统完善成了一个通用版本并且把源码整理出来了。这篇文章就把整个项目的设计思路、核心模块的实现方式、以及我在开发过程中踩过的坑一次性说透希望对准备做类似管理系统的朋友有帮助。1. 项目整体设计与模块规划1.1 汽配行业的业务痛点决定了系统边界做开发的第一步不是写代码而是搞清楚业务到底要解决什么问题。汽配管理和普通商品库存管理有本质区别普通零售商品SKU相对固定但汽车配件有极强的属性维度——同一个配件可能适配多种车型、多个年份还要区分原厂件、品牌件、副厂件甚至同一品牌下还有不同批次。我调研了几家门店后发现日常最痛的点集中在三个地方一是配件的入库出库记录混乱经常出现账实不符二是库存低于安全线时没人知道等客户要货才发现没货三是供应商信息分散采购时找不到历史报价。所以这个系统最终没有做成大而全的ERP而是聚焦在进、销、存、报这四个核心环节。1.2 技术选型为什么不选PHP也不选纯前端方案技术栈选择上我最终定了 Spring Boot 2.x MyBatis MySQL Vue 的前后端分离方案。这里有几个实际考量后端用 Spring Boot因为它的生态成熟事务管理、权限校验这些关键能力都有现成方案不需要自己造轮子。持久层用 MyBatis 而不是 JPA原因是汽配行业查询条件极其灵活——按车型查、按OE号查、按品牌查、组合条件查MyBatis 的动态 SQL 在这种场景下优势太明显了SQL 写起来可控性更强。前端用了 Vue 2 Element UI组件库现成表格、表单、弹窗这些后台管理界面常用的东西拿来就能用开发效率高。如果只做后端管理不涉及移动端这个组合完全够用。1.3 源码目录结构分层清楚才能好维护项目源码的核心结构我做了严格的分层这也是我反复调整后觉得最舒服的组织方式controller 层只做参数接收和返回结果封装service 层业务逻辑全部放在这里事务注解都加在 service 方法上mapper 层对应 MyBatis 的接口定义SQL 写在 XML 里entity 层数据库表对应的实体类vo 层专门给前端返回的视图对象避免直接把实体暴露出去common 层统一返回结果、异常处理、工具类这个结构看起来常规但实际开发中很多人会在 controller 里写业务导致后期维护非常痛苦。把事务边界放在 service 层是最保险的做法。2. 数据库表设计与关键字段解析2.1 配件基础信息表唯一索引是关键配件表是整个系统的基础我设计了这样几个核心字段配件编码parts_no全局唯一、配件名称、品牌、适配车型、OE号原厂零件号、单位、采购价、零售价、安全库存阈值。这里最重要的一点是给配件编码和OE号建立联合唯一索引。汽配行业一个常见场景是同一配件的OE号在不同品牌下是相同的如果允许多条记录入库时就无法判断是新增还是更新数据很快就会出现大量重复。我实测过没有唯一索引的情况下录入人员一个疏忽同一个火花塞就能建出三条记录库存分别存在三条记录里查询和统计全乱套。适配车型这个字段我用的是JSON格式存储比如[丰田-卡罗拉-2017-1.2T, 丰田-雷凌-2017-1.2T]。在MySQL 5.7以上版本里JSON类型可以支持查询但实际使用时我的建议是车型适配信息单独建一张关系表因为车型匹配太频繁了JSON字段不方便走索引。2.2 库存流水表这是账实相符的根基库存系统最容易犯的错误是直接在库存表上做加减一旦数据错了没有任何追溯办法。我的做法是设计一张库存流水表stock_record每一条入库、出库、盘点调整、报损都记录一条流水包含配件ID、变动数量正数为入、负数为出、变动类型、关联单号、操作人、操作时间、备注。当前库存数量不直接存储而是通过流水表实时汇总计算。当然当数据量大到千万级时实时汇总会变慢这时候可以在配件表里冗余一个当前库存字段每次流水变动时同步更新两者配合使用。流水表保证可追溯冗余字段保证查询性能。2.3 供应商与采购相关表供应商表比较简单维护名称、联系人、电话、地址。但采购价必须放在供应商报价表里而不是直接写在配件表上。原因很现实同一配件在不同供应商的价格不一样而且价格会浮动。做采购单的时候系统要能自动带出该供应商最近一次对该配件的报价这个逻辑在二开时经常用到。3. 核心功能模块的实现拆解3.1 入库操作的业务闭环入库单的流程是这样的创建入库单关联供应商→ 添加入库明细选择配件、填写数量、单价→ 确认入库 → 系统生成库存流水 → 更新配件当前库存 → 更新该供应商对该配件的最新报价。这里有一个特别容易踩坑的细节确认入库这个动作必须放在一个事务里。如果先更新了配件库存再写流水的时候报错事务回滚就来得及。但如果有人把两步拆开或者用了不同的数据源那账实不符就是迟早的事。我在代码里明确要求入库单的状态只能从草稿变到已入库不能用更新操作反复修改这样做的目的就是保证流水一旦生成就不可篡改。3.2 出库操作与先进先出的取舍出库销售或领用逻辑上比入库复杂一点。严格来说汽配行业应该做批次管理按先进先出FIFO的原则扣减库存因为不同批次的配件可能存在质量差异。但做过实际项目都知道批次管理会让系统复杂度上一个台阶——每个配件要分成多条批次记录出库时要按批次依次扣减报表统计也要按批次拆分。我在这套系统里做的是单批次加权平均模式也就是不区分批次库存数量统一管理出库时只做总量扣减。这样做的原因很简单大部分小型汽配门店和维修厂并不需要精确的批次追溯他们更关心总量够不够、剩多少。如果你的业务确实需要批次管理建议在流水表上加一个批次号字段将来扩展的时候可以平滑升级。3.3 低库存预警的实现方式低库存预警是一个看着简单但讲究细节的模块。按配置项表达当配件当前库存量小于等于安全库存阈值时系统生成预警记录。我选择用定时任务扫描方式每天凌晨跑一次全量扫描把低于阈值的配件写进预警表。为什么不用实时检测因为实时检测需要每次库存变动后都判断一次不仅增加写操作的开销而且容易漏掉批量导入和盘点调整这类旁路操作。定时全量扫描简单可靠代价是预警有最多一天的延迟这个延迟在汽配场景下完全能接受。预警列表的展示要把配件编码、名称、当前库存、安全库存、最近一次入库时间一起展示出来方便采购人员判断是马上补货还是可以等等。3.4 报表统计模块的设计报表是老板最关心的部分但也是最容易做复杂的部分。我做了三个核心报表入库明细报表按时间、供应商、配件维度统计、出库明细报表按时间、配件维度统计、库存汇总报表按品牌、分类汇总当前库存金额。报表实现的核心思路是查询走独立SQL不复用业务查询的Mapper。因为业务查询要分页报表要聚合两者混在一起不仅性能互相拖累代码也乱。我的做法是报表模块单独建一套MapperSQL直接写聚合语句用GROUP BY按维度归纳。4. 实际操作中的踩坑记录与排查方案4.1 并发扣减库存导致库存变负数这个坑几乎每个做库存系统的人都会遇到。场景是这样的两个员工同时卖出同一个配件系统同时读到库存还有1个各自扣减1个最后库存变成了-1。这就是经典的并发问题。解决方案是使用乐观锁在配件表的库存字段更新时加一个 where 条件stock_count #{减少数量}并且更新语句影响行数为0时说明库存不足主动抛异常让事务回滚。这条SQL长这样UPDATE parts SET stock_count stock_count - #{quantity}, update_time NOW() WHERE id #{partsId} AND stock_count #{quantity}这种方式比程序里先查再判断更可靠因为判断和更新合并成了一步原子操作。我也试过用Redis分布式锁但在这个业务量级下没有必要SQL层面的条件更新已经足够。4.2 模糊查询性能灾难LIKE 前面加%汽配系统很常用的一个功能是配件查询用户习惯输入刹车、丰田 卡罗拉 前刹车片这种关键词。最初我在配件名称字段上用了LIKE %关键词%配件表几千条数据时没事但数据涨到几万条时每次查询都要全表扫描页面明显卡顿。后来我做了两个优化一是把最常用的筛选条件品牌、分类、适配车型改为下拉框精确匹配走索引二是名称和OE号查询改用全文索引。MySQL自带的全文索引在处理中文分词时不完美但对这种简单包含匹配已经够用了。实测优化后百万级数据量下的查询从1秒多降到了100毫秒以内。4.3 事务边界混乱导致的数据不一致这是个非常隐蔽的问题。早期我的代码里有个习惯service 方法 A 调用了 service 方法 B两个方法都加了Transactional注解。Spring 的默认传播行为是 REQUIRED正常情况下会合并成同一个事务这没问题。但问题是如果 B 方法被同类内部调用this.B()这时候事务注解根本不生效因为Spring的事务是基于代理对象实现的内部调用走的是原始对象。这个坑排查起来很费劲。我当时遇到的情况是入库单确认后明明报了异常但库存还是被改了。查了很久才发现是 service 内部自调用导致事务失效。解决方案有两个一是把需要事务保证的方法拆到不同的类里通过注入调用二是使用AopContext.currentProxy()手动获取代理对象。我在代码注释里特意标注了这个坑防止后来维护的人再踩。4.4 数据初始化与历史数据迁移拿源码搭建系统后很多人第一批录入配件数据时会发现效率极低。我的建议是做一个Excel导入功能这是必须的。导入模板设计成三张sheet配件信息、供应商信息、初始库存。导入过程要有校验反馈哪些行导入失败失败原因是什么配件编码重复、必填字段为空、数量不是数字一次性给出完整报告。实际用下来导入5000条配件数据加初始库存两三分钟就能完成比人工录入快了一个数量级。5. 源码部署与二次开发建议5.1 本地环境启动流程拿到源码之后部署步骤是固定的照着走一般不会出问题安装JDK 8以上版本配置JAVA_HOME环境变量安装MySQL 5.7或8.0执行项目里的sql/init.sql脚本初始化数据库表结构和基础数据修改application.yml里的数据库连接信息包括URL、用户名、密码后端项目用 Maven 构建mvn clean package -DskipTests然后java -jar启动前端项目安装依赖npm install开发模式运行npm run serve有一个部署时容易忽略的问题前端请求后端的接口地址是写在前端配置文件里的比如.env.development文件不是写死在代码里。部署时一定要改对地址不然前端能起来但接口全报404。我见过不止一个人卡在这一步。5.2 安全配置修改默认密码是底线源码包里默认的账号密码是 admin/admin123这个只是为了方便本地测试。真正上线使用前必须做三件事强制修改管理员密码、关闭演示模式的调试接口、给数据库设置独立账号而不是用root直连。权限控制方面这套系统做了最基础的三角色划分管理员、采购员、库管员。管理员可以配置用户和查看所有报表采购员只能操作采购模块库管员负责出入库操作。如果你需要更细粒度的权限比如只允许查看自己负责的门店数据可以在用户表加门店字段再做过滤这个扩展点已经预留了。5.3 值得扩展的方向源码目前的完成度覆盖了核心的进销存但如果要投入实际生产环境我建议优先扩展这几个方向第一个是扫码枪支持。汽配仓库里大量操作是扫码作业前端在配件编码输入框监听回车事件扫码枪本质上是键盘输入回车的设备只要焦点在输入框里扫码后自动触发查询或录入不算复杂但很实用。第二个是移动端审批。采购单和出库单的审批如果能在手机上完成对管理者的体验提升很明显。可以不做原生App用H5页面配合消息推送就够用。第三个是多仓支持。如果业务从一个门店扩展到多个分店需要增加仓库表库存数量要按仓库维度拆开库存流水也要增加仓库ID字段。这个改动会涉及表结构和业务逻辑的多处调整建议在设计初期就预留字段哪怕暂时不启用。第四个是配件图片管理。汽配查询时能看图确认配件外观可以大幅减少发错货的情况。实现上可以用OSS存储图片数据库里存URL前端表格加图片列预览即可。6. 最后说几句实在话这套系统写下来最有价值的收获不是功能堆得有多全而是我明白了管理类软件的核心在于数据闭环。入库有单、出库有据、库存有流水、预警有提醒每一步都在一个闭环里转数据才不会烂掉。凡是数据对不上的项目十有八九是流程有缺口、代码有绕过的路。如果你准备拿这套源码做二次开发或者学习我的建议是先完整读一遍 service 层的代码和 SQL 文件把数据流梳理清楚再动手改功能。很多人一上来就改前端页面结果后端的库存逻辑没看懂改完前端发现数据还是不对来回折腾浪费时间。把进销存的底层逻辑吃透后面不管接什么管理系统的需求心里都是有底气的。本文还有配套的精品资源点击获取
