1. 项目概述与目标定位做企业内部管理系统这件事很多人一听“ERP”就想到那种重武器级的商业套件但对几十人规模的小公司来说基于 Spring Boot 从零搭一套轻量 ERP往往是投入产出比最高的选择。我自己做这个项目起点是一个计算机方向的开发选题后来拿它去对真实的小贸易公司业务跑通了从采购、销售、库存到应收应付的核心闭环。整体开发过程相当折腾真正有技术含量的不是增删改查而是业务规则、单据状态、库存流水和对账逻辑之间的关系处理。如果你正犹豫要不要选这方面做项目实践或者已经在开发中卡住这篇经验复盘会很有参考价值。注意下面我只围绕“小型企业内部管理”这个场景展开不是写一套面向多公司多组织的重型 ERP。1.1 项目最终做成了什么样子这个系统的名字可以理解成一个“SmallERP”内部管理平台。它服务的公司模型很简单几十个员工有采购、销售、仓库、财务几个角色没有复杂的生产制造也没有多工厂协同。系统最终包含三个核心业务域每个业务域都有自己的单据流、状态流和账目流采购域供应商资料、采购订单、采购入库单、采购退货单。销售域客户资料、销售订单、销售出库单、销售退货单。库存与财务域即时库存、出入库流水、盘点单、其他出入库、应收/应付往来款。系统管理部分则是所有业务系统绕不开的地基用户、角色、菜单、部门、操作日志以及客户/供应商/货品档案。整体功能大概二十多张数据表属于典型的“中后台业务系统”没有花哨算法但对建模能力和异常处理能力要求很高。因为我定位的是小型企业内部管理不追求大而全。第一版也差点把“生产工单”“MRP运算”“全面预算”都塞进去后来发现这些需求不明确做了也是在数据库里多建几张没人维护的僵尸表。于是砍掉非核心诉求只保留能形成资金与货物流转闭环的模块整个系统才真正被高频用起来。1.2 小型企业的 ERP 需求到底是什么在实际推进中我最大的体感是小企业要的往往不是“ERP”三个字而是“别再让我用 Excel 管理客户和库存了”。他们在意几件很具体的事销售单能不能填得快一点和客户历史价格能否带出。仓库里每个东西还剩多少有没有低于安全库存。某笔采购为什么付了钱货还没到某客户欠了多少钱、账期多长。月底能不能直接拉出本月卖了什么、毛利多少。这些诉求落到系统设计里就是主数据、单据、库存账、往来账四件事。主数据要统一单据要能串起来库存账要实时准确往来账要能追溯到对应单据。整个开发过程也应该围绕这几条主线去排优先级而不是上来就琢磨用什么前端组件库、要不要上微服务。从学习或毕设的角度看这也是一个特别好的“完整项目”训练有用户权限、有CRUD、有事务、有缓存、有报表还有部署上线环节。关键是复杂度适中既不会像纯后台管理系统那样显得单薄又不会像高并发系统那样超出个人可驾驭范围。1.3 哪些人会需要这类项目经验第一类是正在准备开发类综合项目或毕业实践的同学需要一个能讲清完整业务闭环的技术案例。第二类是小型公司里想做内部信息化的开发人员这类项目可以直接做业务改造后落地。第三类是准备转 Java 后端、想用 Spring Boot 做点拿得出手作品的人——你在简历上写一套“基于 Spring Boot 的 ERP 系统”面试官大概率会追问库存、事务、权限和部署这几关你能扛住就已经胜过很多只做过 Demo 的候选人了。我强烈建议不要把这个题目理解成“CRUD 管理系统”。面试或答辩的时候讲“销售出库越库怎么防”“月底结账和库存对不上怎么排查”远比讲“我用了 Vue 和 Element Plus”更能证明能力。后面各节我会按实际开发顺序把技术选型、数据建模、业务实现、监控部署和踩坑记录完整展开。2. 技术选型与系统架构拆解2.1 技术栈清单与选型理由整套系统后端基于 Spring Boot前端采用 Vue 3 Element Plus数据库 MySQL 8.0缓存 Redis构建工具 Maven。最核心的选型逻辑是“大家都在用资料多坑少”并不在于哪项技术最新。具体清单如下层次选型主要理由后端框架Spring Boot 2.7/3.x自动配置能力成熟内置 TomcatStarter 生态完整持久层MyBatis-Plus单表 CRUD 免写 SQL复杂查询保留手写 SQL 灵活性代码校验spring-boot-starter-validationJSR 380 标准参数校验统一处理缓存Redis会话、字典、临时库存锁都能覆盖权限模型自研 RBAC Sa-Token/Spring Security小系统自研 RBAC 足够别引入太重安全框架接口文档springdoc-openapi或 knife4j注意不要用老的 springfox版本冲突多数据库MySQL 8.0默认 utf8mb4业务无特殊扩展需求这里要说一个实际经验热门项目如果打算长时间维护尽量保持 Spring Boot 大版本不要太旧。在默认配置文件、依赖坐标和部分 API 上Boot 3.x 和 2.x 有差异。如果一开始没有明确要用 JDK 17继续用 Boot 2.7 JDK 8 也完全没问题稳定压倒一切。无论如何不要在开发中途频繁跳大版本否则会踩到依赖兼容性的连环坑。2.2 单体架构下的工程分层面对小型企业内部管理这种规模微服务是负优化。它带来的注册中心、配置中心、网关、链路追踪等一系列复杂度对十几个内部用户和一个 MySQL 实例的应用来说完全没有必要。我采用标准的单体分层架构通过包名来划分边界所有代码仍然是传统 MVC 结构src/main/java ├── common ├── config ├── controller ├── service │ ├── impl ├── mapper ├── entity ├── dto ├── vo ├── enums └── SmallErpApplication.javacommon 放统一返回结果 R、分页对象、业务异常类config 放 MyBatis-Plus、Redis、WebMvc 的配置controller 只做参数接收与结果转换service 聚焦业务规则与事务边界mapper 就是持久层enums 统一管理单据状态、出入库类型这些常量。这种结构的好处是每个人一眼就懂新人接手成本低。不要为了“扩展性”把代码拆成多模块 Maven 工程除非你已经明确要做一个多项目并存的产品线。对单体应用来说包结构清晰比模块化工程更实用。2.3 用 Maven 构建并让依赖可控如果你是第一次用 Maven理解不复杂pom.xml 中声明每个依赖的 groupId、artifactId、versionMaven 会按坐标从中央仓库下载并管理整个依赖树。开发环境命令行运行项目也很简单mvn clean package -DskipTests java -jar target/small-erp-server.jar想要本地热启动开发也可以直接mvn spring-boot:run -Dspring-boot.run.profilesdev实际项目中我习惯把所有依赖版本统一写在properties里而不是散落在 dependency 内部。否则容易出现“A jar 引用 B 的旧版本”“本地能跑、打包就报错”的问题。还有个小技巧用mvn dependency:tree查看依赖冲突版本冲突时优先用排除依赖而不是全局改版本。Spring Boot 的父工程已经管理了主流第三方库默认版本自己额外引入组件时尽量选与当前 Boot 版本兼容的版本。大概就是这么一种思路不是追求技术栈“看起来高级”而是要让技术选型处处服务于开发效率和未来可维护性。很多人写到后期觉得代码乱不是码力不行而是工程边界没提前划好。3. 数据库设计与业务建模3.1 从需求文档到表结构开发前别急着建表先把需求文档变成业务流程。拿库存类 ERP 来说最基础的一条线索是采购订单 - 采购入库单 - 库存增加 - 应付增加销售订单 - 销售出库单 - 库存减少 - 应收增加。把这条主线画清楚文字即可所有表的关系就出来了。我整理的表结构可以划分为四组组织与权限组sys_user、sys_role、sys_menu、sys_user_role、sys_role_menu、sys_dept。基础档案组base_material、base_category、base_customer、base_supplier、base_warehouse。业务单据组pub_purchase_order、pub_sale_order以及两种对应的入库单/出库单和明细子表。账务与流水组stock_current、stock_flow、ar_ap_account、ar_ap_detail。主表和明细子表是业务系统的标配比如 sale_order 与 sale_order_item。主表存单据编号、客户、日期、状态、金额合计明细表存商品、数量、单价、行金额。不要让主表直接把所有商品用逗号拼成一个字段那样查询和汇总都会变成灾难。3.2 单据号、金额和时间这三个细节单据号设计必须从第一天就固定规则。为了兼顾可读和唯一我采用“前缀 日期 流水号”的方式比如入库单RK20250703001、出库单CK20250703001订单和财务往来单同理。这种编号不要依赖 MySQL 单独一张 seq 表在高并发下生成简单可靠的做法是借助 Redis INCR 生成流水号然后保存到订单表中如果不想依赖 Redis也可以用yyyyMMdd 雪花ID 后几位但可读性会差一些。金额类字段必须用DECIMAL不能简单用 double 或者 float 存价格。比如某商品单价是 19.90 元数量 3 件单价用浮点数算可能得到 59.699999展示时四舍五入能糊弄过去但累计到月底对账就会差几分钱。Java 侧对应实体属性用BigDecimal计算用add/multiply格式化和截取用setScale(2, RoundingMode.HALF_UP)。时间字段也是容易出问题的地方。MySQL 连接串要把serverTimezoneAsia/Shanghai和useUnicodetruecharacterEncodingutf8配好Java 侧日期时间优先用LocalDateTime接口接收用JsonFormat统一格式不要在每个查询里手动拼日期字符串。3.3 设计时容易踩的反直觉点有几个点我在开发中吃了不少亏库存不要只有一张总数表。除了 stock_current还必须有一张 stock_flow 流水表。数总表容易但查“某商品某天之后发生了什么”时没有流水就寸步难行。所有库存增减都必须在同一事务里同时写流水和更新总量。明细子表必须存“下单时的快照字段”比如商品名称、规格、销售单价。商品档案随时可能改名如果报表直接 join 档案表历史单据显示的商品名就跟着变了无法追溯。逻辑删除要慎用。MyBatis-Plus 默认逻辑删除会影响唯一索引校验比如商品编码唯一约束配上逻辑删除后A 删除再用原名新建 B 时如果唯一索引建在 encoding 字段上就会冲突。建议核心主数据和单据表都加删除状态字段而真正防止唯一约束冲突时需要把“是否已删除”一起放进联合唯一索引里。一个客户既是供应商又是客户的情况并不少。早期的设计里要把这两份档案合并成 partner用角色类型区分否则同一家公司录两遍后期应收应付容易混。4. 核心业务闭环从采购到收付款的实现4.1 采购入库事务与库存账目联动采购入库是整个库存体系最容易乱的一环因为“先下单后到货”意味着采购单是预占状态入库单又是实际发生。系统的设计是采购订单作为前置凭证采购入库单作为实际业务动作一张采购单允许分批到货每批对应一张入库单。入库的核心代码逻辑可以简化成这样的服务方法Transactional(rollbackFor Exception.class) public void inbound(InboundCreateRequest req) { String orderNo req.getPurchaseOrderNo(); PurchaseOrder order purchaseOrderMapper.selectByNo(orderNo); if (order null || !SO_CONFIRMED.equals(order.getStatus())) { throw new BizException(采购单不存在或状态不允许入库); } // 逐条校验本次到货数量不能超过订单剩余数量 for (InboundItem item : req.getItems()) { verifyRemainQty(orderNo, item.getMaterialId(), item.getQty()); } // 1. 生成入库单主表与明细 Long inboundId saveInbound(order, req); // 2. 写库存流水并更新即时库存 for (InboundItem item : req.getItems()) { StockFlow flow new StockFlow(); flow.setBizType(PURCHASE_IN); flow.setBizNo(getInboundNo(inboundId)); flow.setMaterialId(item.getMaterialId()); flow.setQty(item.getQty()); stockFlowMapper.insert(flow); stockCurrentService.increase(item.getMaterialId(), item.getQty()); } // 3. 累计到供应商应付 arApService.addPayable(req.getSupplierId(), req.getAmount(), getInboundNo(inboundId)); }Transactional(rollbackFor Exception.class)非常关键。如果中间任何一步失败只有事务回滚才不会出现“入库单不存在但库存已经增加了”的不一致状态。小系统能保证事务边界做对很多数据错乱问题就能在源头消除。入库单生成后下一个动作是生成应付款。采购入库业务并不是指订单本身形成应付而是以“已入库且已确认”为依据确认应付因为只有真正验收入库的货物才产生应付义务。即使采购单金额 10 万、分批只到了 2 万应付也只能增加 2 万剩余部分仍挂在采购订单剩余数量上等待后续到货。4.2 销售出库锁库存与超卖控制销售出库与采购入库在流程结构上镜像但多了“超卖”风险。库存不是无限资源多人同时开单时就可能卖超。最简单的防超卖方式是在更新即时库存时做条件更新而不是先 SELECT 出来在 Java 里做减法再 UPDATEUpdate(UPDATE stock_current SET qty qty - #{qty}, updated_at NOW() WHERE material_id #{materialId} AND qty #{qty}) int reduceStock(Param(materialId) Long materialId, Param(qty) BigDecimal qty);执行 update 的影响行数为 0说明库存扣减失败直接抛“库存不足”异常即可。这种“扣减余额校验放在 UPDATE 条件中”的方式天然具备原子性比 select for update 或悲观锁更容易避免死锁适合大多数库存扣减场景。出库环节还涉及一个业务判断销售单是否允许超卖。我当时和业务方确认后决定一般商品不允许负库存出库特殊打印品可在配置中允许。这个完全可以做成系统参数stock.allow_negative而不是写死在代码里。但在做负数库存功能前请先想清楚负库存会影响什么它会让“平均成本计算”和“月底结存金额”毫无意义还可能让应收账款数量核对非常混乱所以默认还是别开。4.3 财务对账与往来款核销应收应付是所有 ERP 里最容易和业务“打架”的部分因为财务视角和业务视角天然不同。业务说“这个客户欠我们 5 万”财务实际会说“这 5 万里有 3 万已经超期 30 天”。系统把往来款做成两张基础表应收应付主表管“某一客户当前总欠款”明细表记录每一笔业务发生时形成的应收应付变动。回款的核销处理要按明细匹配客户打来 13000 元回款系统在 ar_ap_detail 中按时间顺序/单据号找到未核销的应收明细优先核销账期最久的一张销售出库单的应收如果 13000 覆盖了某张 10000 的单据还余 3000 继续核销下一张每笔明细记录核销金额、核销时间与对应回款单号方便审计。这套核销逻辑不要用实时汇总表去硬算因为 ERP 的时间轴一旦跨月就涉及期初、本期增加、本期核销、余额四要素。用主表 明细表再加一张回款单表基本能覆盖小型企业所有往来需求了。4.4 前端接口设计与权限控制小团队若没有专职前端我建议后端接口尽量设计得“为页面而写”不要一个通用查询接口包打天下。例如“销售开单页”需要一个聚合了客户历史价格、库存余量、最近报价的接口尽管它看起来复合得不太 RESTful但对页面开发效率提升很大。权限控制采用 RBAC用户 - 角色 - 菜单/操作权限。后端在需要控权的 Controller 方法上用自定义注解做权限校验比如RequiresPermission(sale:order:create)避免所有接口裸奔。菜单权限做到前端路由显隐只是一部分真正安全还是后端的接口权限校验要拦得住否则用户直接调接口就能越过按钮限制。一个小公司 ERP 把菜单、按钮和数据范围控制到“用户自己的部门/全部”粒度就足够了不需要复杂的字段级脱敏。5. 监控、缓存与部署运维5.1 用 Actuator 和 Micrometer 做监控系统能跑只是第一步能不能稳定跑是另一回事。Spring Boot Actuator 配合 Micrometer 是项目上线初期性价比最高的监控方案。它就是两个 Starter 的事dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency dependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId /dependency配置文件里打开端点并暴露指标management: endpoints: web: exposure: include: health,info,metrics,prometheus endpoint: health: show-details: always