Spring Boot+SSM构建ERP进销存系统：从数据库到物流全解析

不想在架构选型上反复纠结，又希望项目能快速落地的话，Spring Boot和SSM这套组合确实是做ERP进销存系统绕不开的经典路线。这篇文章我打算把整个项目的核心拆开讲，从技术选型的取舍、数据库表结构的设计，到单据流转和物流信息管理这种细节模块的落地方式，全部过一遍。如果你正打算自己做一套进销存系统，或者接了一个相关需求但还没理清头绪，这篇应该能帮你省不少时间。

1. 立项之前最该想清楚的事情：技术栈选型与项目边界

1.1 为什么Spring Boot和SSM能混在一起用，而且很搭

很多刚接触的人会有一个疑问：Spring Boot和SSM难道不是两套竞争关系的东西吗？严格来说，SSM指的是Spring、Spring MVC、MyBatis三者组合的经典架构，而Spring Boot并不是要替代它们，它是把这些组件自动装配起来的一个加速框架。Spring Boot底层依然是Spring容器和Spring MVC，只不过省掉了大量XML配置，改成了约定大于配置。

我自己做过的几个企业级项目里，最常用到的组合是Spring Boot 2.x + MyBatis Plus + MySQL，这跟传统的SSM差别在于：MyBatis Plus对单表CRUD做了增强，但在复杂报表和多表关联查询上，还是要自己写XML里的SQL。这种搭配保留了SSM的灵活性和可控性，又享受了Spring Boot自动配置带来的效率提升。

在进销存这种场景下，这种组合的优势特别明显。进销存的核心操作就是增删改查加上复杂的库存计算，MyBatis Plus可以帮你把80%的基础CRUD代码省掉，剩下那20%的核心业务逻辑（比如库存扣减前的锁定、单据审核时的状态流转）再手写SQL来精确控制。翻译成人话就是：先跑起来容易，想改什么也能改得动，不卡手。

1.2 进销存项目的范围怎么切，关键看这三个维度

我开始动手之前，一定会先把项目范围画清楚。进销存系统看起来名字简单，但往里一钻，很容易失控。我一般从三个维度来切核心范围。

第一个维度是单据链。进销存的核心是围绕一个单据的生命周期展开的：创建草稿、提交审核、审核通过、执行生效（比如确认入库或出库）、最后生成财务凭证或统计报表。研发时我会先保证这个主链路跑通，再做周边扩展。

第二个维度是角色权限。同样是进销存系统，采购员录入采购单、仓库管理员确认入库、财务人员查看成本和毛利，这几类人关注的数据和操作权限完全不同。Shiro或者Spring Security二选一，我更推荐后者，因为它跟Spring Boot的整合更自然，注解式权限控制写起来也简洁。

第三个维度是数据的追溯能力。进销存系统最怕的就是数据对不上：库存账实不符、单据状态卡住、审核链路断了。所以一开始就要设计好操作日志和快照表，任何一次单据修改、审核、作废操作都要留下痕迹。这个不做，后期上线运营会让你天天查数查到崩溃。

我在正式敲代码前一定会先画一张业务流程图，把采购、销售、库存这三条主线以及它们之间的交叉点（比如采购到货后直接发货给客户这种情况）理清楚，然后再建表。顺序反过来的话，多半要推倒重来。

2. 数据库表结构设计：进销存系统的地基在哪里

2.1 从单据主表和明细表的设计说起

不管是采购单、销售单还是出入库单，几乎所有的业务单据在数据库里都遵循同一个模式：一张主表描述单据整体信息，一张或多张明细表记录具体货品的行项目。

拿采购订单举例，主表purchase_order字段大致是这样的：

CREATE TABLE `purchase_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `order_no` varchar(32) NOT NULL COMMENT '采购单号', `supplier_id` bigint(20) DEFAULT NULL COMMENT '供应商ID', `warehouse_id` bigint(20) DEFAULT NULL COMMENT '目标仓库ID', `total_amount` decimal(12,2) DEFAULT NULL COMMENT '总金额', `status` tinyint(4) DEFAULT '0' COMMENT '状态: 0草稿 1待审核 2已审核 3已入库 4已作废', `audit_by` bigint(20) DEFAULT NULL COMMENT '审核人', `audit_time` datetime DEFAULT NULL COMMENT '审核时间', `create_by` bigint(20) DEFAULT NULL COMMENT '创建人', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='采购订单主表';

明细表purchase_order_item则记录每一行货品的信息：

CREATE TABLE `purchase_order_item` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_id` bigint(20) NOT NULL COMMENT '主表ID', `product_id` bigint(20) NOT NULL COMMENT '商品ID', `quantity` int(11) NOT NULL COMMENT '数量', `price` decimal(12,2) NOT NULL COMMENT '采购单价', `amount` decimal(12,2) NOT NULL COMMENT '行金额', `received_quantity` int(11) DEFAULT '0' COMMENT '已入库数量', PRIMARY KEY (`id`), KEY `idx_order_id` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='采购订单明细表';

我在设计的时候特别强调给明细表加上received_quantity这样的冗余字段，用来记录该行已经入库了多少。为什么要冗余？因为企业实操里一张采购单经常分批到货，今天到30箱，下周再到20箱。如果不记录这些进度，就无法判断这张采购单是否完全执行完毕，也无法为采购员提供准确的到货进度。这种冗余字段看起来跟订单表本身没有直接关系，但它恰恰是进销存系统能否支撑真实业务的关键设计。

2.2 库存表为什么会成为性能瓶颈，以及如何应对

库存表的设计直接决定了并发场景下系统的表现。最简单的设计是每个商品一个库存记录，字段包含product_id、warehouse_id、quantity——差不多就是网上绝大多数教程教你的样子。但真到了多仓库、多批次、有有效期管理的业务里，这种设计远远不够支撑。

一层更合理的拆法是分离实时库存和库存流水：实时库存表只管当前结存数量，库存流水表记录每次变动（入库、出库、盘盈、盘亏、锁定）。这样做的理由在于：业务查询需要快速看到当前库存，而审计和追溯则需要完整的变动历史。如果所有历史都堆积在一张实时库存表里，记录会越攒越多，查询性能也会逐步劣化。

实际开发时还会遇到并发扣减库存的问题。经典做法是使用UPDATE stock SET quantity = quantity - #{num} WHERE product_id = #{pid} AND quantity >= #{num}这样的原子条件更新，通过数据库行锁天然保证不会超卖。再加上乐观锁version字段做二次校验，基本能做到既安全又有性能。

还有一点是我踩过坑才悟出来的：库存表里的操作人员标识和业务单号一定要记录。两个仓管员同时在做移库调整，如果没有业务单号追溯，出了问题你根本不知道是哪个操作变更了库存。分开记录操作人和业务单号，是为了让对账和问题回溯有据可依，而不是单纯为了盘点时方便。

2.3 商品、供应商、仓库这几个基础资料表怎么关联才合理

基础资料表是进销存的元数据层。商品表除了常规的品名、编码、规格、单位，还要考虑多计量单位问题——有些商品是按箱进货、按盒出库的，就需要一张辅助计量单位换算表。分类表建议采用父子层级结构，用parent_id自关联，而不是硬编码层级字段。

供应商和客户虽然业务角色不同，但字段高度相似（名称、联系人、电话、地址、账期），我是直接用一张伙伴表partner加类型字段来区分的。好处是后续做客户和供应商互转（比如经销商退货给上游）时，只需改类型，而不用重新维护一遍档案字段。

仓库表本身不大，但它跟部门、库管员的关联往往被忽视。我的习惯是在仓库表上直接挂manager_id，同时保留一个完整的用户表。这样在做权限控制时，库管员只能看到他负责的仓库的单据，逻辑会简单很多。权限要精细到按钮级别，而不是只到菜单级别——这一步设计不好，后期每次给角色调权限都是一次繁琐的折腾。

3. 单据流转的状态机设计：业务的核心大脑

3.1 状态和事件分离，是单据流转设计的核心

做进销存系统时，最忌讳的就是把所有业务逻辑写在一个方法里，比如审核按钮里面又调了库存更新、又发消息、又记录日志，所有逻辑耦合在一起，之后每改一个需求都要在这个方法里动刀。我的做法是将单据流转拆成组件的组合模式：状态机负责驱动状态的变化，独立的业务服务在状态变化时依次被调用。

以采购单为例，状态和事件可以这样设计：

这里最关键的一步是状态变迁时附加动作的处理。以前我习惯在方法体中直接调用库存服务，后来发现这种写法存在较大的维护成本。后来我改成发布事件，让库存模块、日志模块自己去订阅处理。这样做的优势在于，新增一个模块（比如发送消息给采购员）时，不需要修改原有审核逻辑，代码的侵入性大大降低。

可能有人会说Spring Boot自带的@EventListener事件机制够用了，但涉及强一致性的操作（比如扣库存和生成出入库单必须同时成功），还是要放到同一个本地事务里，不能用异步事件。我的原则很简单：强一致性的走同步事务，最终一致性的（比如通知、报表刷新）才用事件解耦。

3.2 审核链路里的数据一致性怎么保证

审核链路是进销存系统里数据一致性要求最高的环节。一张采购单审核通过之后，可能同时触发库存锁定、可用金额变更、供应商应付更新这三件大事。任何一个成功而另外两个失败，都会造成脏数据。

我用的方案是Spring的声明式事务，核心方法上打@Transactional注解，然后在事务内依次执行以下操作：

1. 更新订单状态为已审核
2. 调用库存服务锁定库存
3. 写入库存流水记录
4. 插入一条操作日志

为什么强调这些操作必须在一个事务里？因为库存一旦被锁定但订单状态没更新，用户会觉得单据没有审核通过，但库存却被占住了，时间久了可用库存越来越少，问题极其隐蔽。与其事后对账，不如在设计阶段就用事务把它们绑在一起，任何一步失败，整条链路的操作全部回滚。

事务的粒度也有讲究。我见过一种情况是把整个订单创建逻辑（包括校验、保存主表、保存明细）统统放在一个事务里，导致某些无谓的长事务堆积。多张表的大事务会让数据库连接池吃紧，高并发下尤其明显。我的习惯是只把那些需要强一致性的核心操作放进事务，查询和外部接口调用尽量放到事务之外执行。

3.3 批量审核和驳回的边界条件

实际业务里，采购员每天可能录入几十张单据，然后财务或主管一次性批量审核。批量审核听起来简单，实际上暗藏很多边界条件。比如：这批单据里有一张超预算了应该驳回，另一张明细数量为0不能审核，还有一张已经被别人审核过了——这些情况都要分别处理，不能因为一张失败就整批回滚。

我的处理方式是批量审核时，采用“逐条独立事务 + 汇总失败原因”的思路：

• 循环遍历待审核单据
• 每条单据单独开启一个事务
• 成功后收集到成功列表
• 失败时捕获异常，把失败原因记录到结果列表

这样前端可以清楚地展示“3张审核成功，2张失败，失败原因分别是XXX”。用户操作体验好，代码逻辑也清晰。

批量驳回也是一样，驳回操作通常需要填写驳回原因，这个原因一定要落库。试想一下，采购单被驳回了，但采购员完全不知道被驳回的原因是什么，还得线下沟通询问——这在真实业务中是明确缺乏效率的。我在设计表结构时专门留了audit_remark字段，让每一次审核操作都携带原因备注。

4. 精细化的物流信息管理：不止是记录一个快递单号

4.1 为什么单独的物流表会比给订单表加字段更靠谱

很多初级的进销存系统会把物流信息压缩成订单表上的几个字段，比如express_company、express_no、deliver_time。这种做法在发货场景单一的情况下没什么问题，但一旦业务复杂起来，很快就撑不住。

真实的进销存业务里，一张销售订单经常拆成多次发货：一批今天发走，走的是顺丰；另一批备货中，下周发德邦。如果物流信息只是订单表上的几个字段，第一次发货覆盖第二次发货的信息，那前面那批货的轨迹就彻底丢了。

我习惯单独建一张物流记录表delivery_record：

CREATE TABLE `delivery_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `biz_type` tinyint(4) NOT NULL COMMENT '业务类型: 1销售出库 2采购退货 3调拨', `biz_no` varchar(32) NOT NULL COMMENT '业务单号', `delivery_no` varchar(32) NOT NULL COMMENT '发货单号', `express_company` varchar(64) DEFAULT NULL COMMENT '物流公司', `express_no` varchar(64) DEFAULT NULL COMMENT '物流单号', `package_count` int(11) DEFAULT NULL COMMENT '包裹数量', `weight` decimal(10,3) DEFAULT NULL COMMENT '重量(kg)', `delivery_status` tinyint(4) DEFAULT '0' COMMENT '物流状态: 0待发货 1已揽收 2运输中 3已签收 4异常', `expect_arrive_time` datetime DEFAULT NULL COMMENT '预计到达时间', `actual_arrive_time` datetime DEFAULT NULL COMMENT '实际签收时间', `remark` varchar(255) DEFAULT NULL COMMENT '备注', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_biz_no` (`biz_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='物流发货记录表';

这张表独立出来后，一张销售单可以关联多条发货记录，每条记录都有自己的物流公司和单号，互不覆盖。查询物流进度时，按biz_no查这张表就能拿到所有发货批次的状态，前端也可以按批次分别展示。这是实现“精细化的物流信息管理”最基本的数据前提。

4.2 物流状态是我们自己更新还是接快递接口

物流状态有两种获取方式：一种是定时调用快递100、快递鸟这类第三方接口同步轨迹，另一种是内网系统里手动更新（比如内部司机送货时人工点“已送达”）。实际项目中经常是两种方式混合用。

接第三方接口时，最需要注意的是频率控制和数据冗余。快递查询接口大多有每日调用次数限制，不可能每秒钟对所有运单做轮询。我的做法是写一个定时任务，每隔一定时间只查询状态还在进行中（未签收、非异常）的运单，签收后就不再重复查询。每次查询结果除了更新状态字段，还会把完整的轨迹内容追加保存到一张快递轨迹明细表里——不要只存一个最新状态，因为一旦快递公司数据接口出现延迟，你至少还有一份历史快照可以用来排查问题。

如果是内部配送，没有第三方物流轨迹，那就把状态拆细一点：待出库、已出库、配送中、已签收、拒收退回。每一环由对应角色在系统里点击确认，同时要求填写签收人姓名和签收时间。这看似多了一步操作，但到了月底对账，你会庆幸自己保留了这个签字依据。

4.3 物流模块怎么跟库存、销售、财务联动

物流模块不是孤岛。发货动作本身会触发一系列连锁反应：

• 生成销售出库单，扣减库存
• 更新销售订单的“已发货数量”
• 同步生成应收记录（如果发货即确认收入）
• 通知客户（短信或站内信）

这个联动同样要遵循“同一事务内完成强一致性操作”的原则。我一般把“生成出库单 + 扣减库存 + 更新订单已发货数量”放在一个事务里，只有这三个操作全部成功，才允许创建物流记录；如果创建物流记录失败，会抛出异常让前面的回滚，从而保证不会出现“库存已经扣了但物流信息没有生成”这类问题。

物流异常处理也是一个容易遗漏的细节，比如快递被退回。这种情况下，我的处理方式是在物流记录上做标记，同时反向生成一张销售退货单草稿，原销售订单的“已发货数量”保持不变，由业务人员根据实际情况决定是否重新发货还是退款。很多系统在这里因为缺乏设计漏洞而出错，往往就是没有把物流异常映射回业务单据上。

5. 系统落地时的关键配置：从Maven依赖到部署运维

5.1 如何用Maven方式构建一个Spring Boot项目

用Maven构建Spring Boot项目是当前的主流做法，原因很简单：依赖管理方便、打包部署标准化、团队协作时版本统一。核心是pom.xml文件，它决定了项目引入了哪些依赖以及如何构建。

基础的工程结构长这样：

erp-system/ ├── pom.xml ├── src/main/java/com/example/erp │ ├── ErpApplication.java │ ├── controller/ │ ├── service/ │ ├── mapper/ │ ├── entity/ │ ├── dto/ │ └── config/ ├── src/main/resources │ ├── application.yml │ ├── mapper/ │ └── db/ └── src/test/java

项目启动类就一个带@SpringBootApplication注解的类，然后定义好各层分包。Controller只负责参数接收和简单校验，具体的业务逻辑放在Service层，数据访问放在Mapper层。这种分层结构刚开始看起来繁琐，但一旦项目规模变大、多人协作时，分层的优势就非常明显：每个人的工作边界清楚了，代码冲突也少了。

Maven构建的核心命令不复杂，常用的是：

mvn clean package -DskipTests

打包出来的erp-system-1.0.0.jar内置了Tomcat，直接java -jar就能跑。如果项目里有多个环境（开发、测试、生产），可以用application-dev.yml、application-prod.yml，启动时通过--spring.profiles.active=prod指定用哪套配置。这个机制一定要用起来，不然每次部署前都要手动改数据库地址，极容易出错。

5.2 application.yml里的关键配置和容易忽略的参数

application.yml是整个系统的配置中心，进销存项目里最容易出问题的是三个地方：数据源、事务管理、MyBatis的配置。以下是核心配置示例：

spring: datasource: url: jdbc:mysql://localhost:3306/erp_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowMultiQueries=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB max-request-size: 50MB mybatis-plus: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.erp.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

map-underscore-to-camel-case: true这一行很重要——数据库里的create_time会自动映射到实体类的createTime字段，省了很多手工resultMap的编写工作。

allowMultiQueries=true允许一条SQL里执行多条语句，这在一些批量初始化和复杂报表场景下很有用。不过要注意，这也可能带来SQL注入的风险面扩大，生产环境如果对安全有要求，建议关闭而非开启。

还有一个容易被忽略的参数是数据库连接池。Spring Boot 2.x 默认用的是 HikariCP，它在高并发下表现很不错，但默认的maximum-pool-size只有10。如果进销存系统的并发操作比较多，建议适当调大，比如配到20~50之间：

spring: datasource: hikari: maximum-pool-size: 30 minimum-idle: 5 connection-timeout: 30000

连接池太小，高峰期会出现获取连接超时；连接池太大，数据库本身又扛不住。建议根据实际压测情况调整，没有绝对适合所有项目的标准值。

5.3 部署到Tomcat和actuator健康检查的问题

Spring Boot项目有两种常见部署方式：直接java -jar用内置Tomcat，或者打包成WAR放到独立Tomcat的webapps目录下。如果是小团队、小体量，我强烈建议直接用内置Tomcat的方式，部署一台机器只需要装一个JDK，不需要单独维护Tomcat环境。

真要用独立Tomcat部署（比如公司运维统一管理），需要注意三点：

• 在启动类上继承SpringBootServletInitializer并重写configure方法
• 打包方式改成WAR
• 内置Tomcat的依赖scope改成provided

@SpringBootApplication public class ErpApplication extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) { return builder.sources(ErpApplication.class); } public static void main(String[] args) { SpringApplication.run(ErpApplication.class, args); } }

在独立Tomcat下部署，还容易踩一个坑：Tomcat的server.xml里默认的maxPostSize是2MB。进销存系统里有批量导入Excel的功能，偶尔还会上传图片附件，超过2MB直接报413错误，排查起来很隐蔽。要么调大这个参数，要么直接把上传接口走multipart的配置，避免把大文件内容塞进URL参数。

Spring Boot Actuator是另一个值得提的点。它的/actuator/health接口可以被监控系统定期探测，判断服务是否存活。但要注意的是，老版本Actuator暴露的端点很多，生产的敏感信息存在泄露风险，线上部署一定要显式配置只开放health和info：

management: endpoints: web: exposure: include: health,info

开发环境开env、beans这些端点没问题，但生产环境必须收敛。另外一个容易被忽视的细节是health端点默认会检查数据源连接状态，如果数据库挂了，健康检查会返回DOWN，配合监控告警非常实用。

5.4 部署上线后的高频坑位盘点

代码层面写得再顺，部署上线之后还是有一堆环境类的问题等着你。我把自己踩过的几个高频坑整理一下，有备无患。

第一个是时区问题。服务器默认时区如果不是Asia/Shanghai，数据库连接的serverTimezone没配，或者spring.jackson.time-zone没设，就会出现所有时间差8个小时的诡异现象。我一般在配置文件里直接加spring.jackson.time-zone: GMT+8，从源头消除这个问题。

第二个是静态资源缓存导致前端看不到最新的代码。修改了前端页面之后，浏览器还在用旧的缓存文件，我原来的习惯是每次发布后在静态资源路径上加版本号参数，后来用统一网关统一处理的方案替代了前端文件名加哈希的做法，因为维护成本更低。

第三个是内存溢出问题。进销存系统里有大量导出报表的操作，一次性把几十万条数据查出来放内存里，轻轻松松OOM。我的解法是MyBatis的流式查询，配合分批处理和临时文件落盘，这样JVM内存占用始终保持在可控范围内。导出操作耗时较长，前端也建议改成异步任务：点击导出后返回一个任务ID，后端处理完再通知下载，而不是让HTTP请求干等着。

我的经验是：导出功能一定要加异步化设计。同步导出一旦数据量大，用户等几分钟都没反应，会觉得系统卡死了。异步导出再配一个导出记录表，用户可以查看导出进度和下载文件，这是企业客户很看重的一个体验点。

6. 从进销存到更广阔的系统边界：那些你可能需要知道的事

6.1 企业为什么要从单机版ERP走向MES等外延系统

做完一套进销存系统之后，常会遇到客户问：能不能把生产车间的工单报工、设备运行状态、产量数据接进来？这就引出了ERP和MES的关系。

简单说，进销存管的是“账”和“库存”，MES管的是“车间实况”。ERP看的是结果数据（今天出了多少货），MES看的是过程数据（产线A现在在跑什么工单、这台设备当前转速多少）。两者对不上会是企业运营中的隐患：账面上显示有100件成品库存，但产线上其实有20件还在返工，这20件到底算不算库存；如果只以ERP数据为准，那这20件其实并没有进入真实的可用库存。这正是很多工厂要把两套系统打通的原因。

从技术实现角度看，对接方案通常是由MES把每个班次的生产完工数、良品数、不良品数推给ERP，ERP自动生成一张生产入库单或报工记录。接口设计一般是RESTful风格，MES定时推送或者ERP主动拉取。我当时做过的项目中，放在数据库中间表做接口交换是最省事的——两边不直接依赖对方的表结构，只约定中间表，出错时排查也直观。

6.2 ERP系统里的报表需求，往往是项目真正的加分项

进销存系统的基础功能差别都不大，真正拉开差距的是报表：老板要看每日销售汇总、采购部要看供应商准时交付率、财务要看毛利和应收账龄。这些需求每个都是独立的查询课题，我会建议把统计类的报表单独建一个模块，用只读的汇总表或视图来支撑，而不是在业务表上直接跑大查询。

技术重点有两个：一是按时间维度分组汇总，比如按日、月、季度、年；二是多维对比如按商品、按客户、按仓库、按业务员。这些指标在SQL层面通常就是GROUP BY和SUM的组合，关键是在索引设计上做优化，千万不能让全表扫描发生在几百万条数据的表上。可以按需建联合索引，比如idx_orders_order_date_product = (order_date, product_id, status)，查询效率和全表扫描完全不同。

不在乎报表性能的系统只能算半个进销存系统，因为一个能快速响应、直接看到经营状况的报表模块，才是企业真正愿意为系统付费的理由。

6.3 开源ERP的坑与价值

很多团队在做技术选型时会问：要不要直接用开源ERP产品？我自己用过几款知名的开源ERP，太深的定制需求往往比从零开发还要痛苦。因为开源ERP本身是一个集成了财务、制造、供应链的庞然大物，它的数据结构是经过多年行业抽象沉淀下来的，你想改一个字段，可能要牵扯几十张表的关联。更不用说升级时你本地做的改动和官方版本产生冲突的痛苦了。

开源ERP的价值在于参考学习了。它的表结构设计、业务流程划分、多公司多币种支持方案，这些通过阅读源码能学到很多宝贵的设计思路。但从零做一套轻量级进销存，基于Spring Boot自主开发，再根据客户业务做适度定制，往往是中小型项目里性价比最优的选择。

7. 编码之外的一些心得与碎碎念

最后分享几点我做这类项目时沉淀下来的经验体会。

不要低估数据库设计的重要性。代码写得再漂亮，表结构设计不合理，后期一样要成倍返工。进销存项目中我一般会花掉整个项目近三分之一的时间在表结构设计上，反复推演各种业务状态下的数据流向，确认无误后才开始编码。

测试阶段一定要引入真实的业务数据，不要只用自己造的那几条干干净净的测试数据。真实业务数据里会有退货单、换货、部分到货、跨月单据修改等千奇百怪的情况，只有被真实数据折腾过一遍，系统的健壮性才能经受住考验。

团队里如果有业务人员，一定要让他从项目开始就参与进来。进销存系统的很多隐藏规则（比如特价订单不能走普通审核流程）都藏在业务流程的细节里，研发人员自己想是想不出来的。有一句话说得好：进销存系统不难写，难的是搞清楚业务里的那些例外情况。