做后台管理系统做了几年SSM 这套组合是我用得最顺手的。最近整理代码库翻到一个给某批发超市做的库存管理系统用的是 SSM MySQL Maven Tomcat 这套经典技术栈。项目不大但特别有代表性——商品进销存、供应商结算、库存预警、盘点调库这些场景全都有代码里还埋了不少针对真实业务的设计取舍。这篇就把整个项目彻底拆开聊一遍从设计思路、数据库表结构、核心代码实现到部署运行和踩坑记录尽量写成一份可以直接照着复现的参考手册。这个系统适合谁看我觉得就两类人一类是刚学完 SSM 想做完整项目练手的同学另一类是要接外包或者给中小超市做信息化的小团队。前者拿它当课设、毕设的底子很合适后者可以直接拿过去改业务逻辑省掉从零搭框架的时间。项目里没有花里胡哨的东西但每个模块都能跑每个功能都在真实业务里验证过。1. 项目背景与设计思路1.1 批发超市的库存管理和普通零售有什么不一样很多人一想到库存管理第一反应就是不就是增删改查吗。真正做下去你会发现批发超市和楼下便利店完全不是一回事。批发超市走的是整进整出、整进散出的模式供应商送货不是按箱或者件这种自然单位来对接的它要面对的是大批量的多规格商品一笔进货单可能包含几十上百个SKU每个SKU还有不同批次、不同进货价。零售店卖一单扣一个库存批发超市则可能一张销售单就扣掉几十上百件。这些特点直接决定了系统的核心诉求进货单要有主表和明细表明细可以很多条而且要记录进货价因为批发生意的毛利核算是按批次走的。库存必须有流水日志不能只知道当前剩多少还得能回答这批货是哪天进的上次盘点多了还是少了。库存预警不是装饰功能批发业务里断货影响比零售更大下游小卖部就指望你供货断货意味着丢失一批稳定的复购客户。价格是波动的今天进价 85明天可能涨到 88系统要能区分不同批次虽然不需要做到批次追踪那么重但至少要保留进货价记录。所以这个项目在设计上完全没有照搬教科书上的简单仓库管理系统而是把批发两个字真正吃透了再去建模。1.2 为什么坚持用 SSM不换 Spring Boot做这个项目的时候 Spring Boot 已经开始流行了但我还是选了 SSM原因很现实第一这套系统要跑在客户现有的服务器上客户那边是传统的 Tomcat WAR 包部署方式运维只会点解压和启动 TomcatSSM 这种结构对他们来说反而熟。Spring Boot 虽然内嵌容器更方便但客户不一定接受换部署方式。第二SSM 是很多团队现有代码的基底接手维护的人大概率都熟悉这套。我见过太多项目一上来用 Spring Boot结果代码里三层外三层全是注解扫描和自动装配出了问题排查链路比 SSM 长得多。SSM 的 XML 配置虽然啰嗦但每个 Bean 都能看得见来源出问题一眼就能定位这对给传统企业做的管理系统来说反而是优点。第三MyBatis 写动态 SQL 是真的好用。库存管理里有大量多条件组合查询比如查某段时间内进货价大于 80 的商品如果用 JPA 或者 Hibernate条件一多要么拼接字符串要么写 Specification别扭得很。MyBatis 的where、if标签对这种场景是降维打击SQL 长什么样完全由自己控制优化起来也直接。当然对准备找工作的同学我也建议学有余力时把 Spring Boot 版本也练一练但思路完全一样Service 层代码和数据库设计可以直接平移。1.3 功能模块与角色划分这个系统按角色拆成四个维度管理员拥有全部权限主要负责商品维护、用户管理、系统初始化。采购员创建进货单、确认入库、管理供应商资料。销售员/收银员开销售单、打印小票、查询商品库存。库管员库存盘点、库存预警处理、损益单录入。角色权限我用的是最简单粗暴的role字段 拦截器实现没有引入 Shiro 或者 Spring Security。为什么因为这种规模的项目引安全框架配一套拦截规则的时间比手写还长。手写一个拦截器在preHandle里判断 session 里的 user 权限码不够的就重定向到无权限页面完全够用。后面业务如果真的复杂到要细粒度权限比如采购员只能看华东区的供应商再上 Shiro 也不迟底子留好了。功能模块上系统主要分为六大块模块核心功能商品管理商品分类、商品信息维护、条码管理、上下架状态供应商管理供应商档案、联系人、结算账期进货管理创建进货单、供应商送货确认、入库、退货销售管理开销售单、出库、销售退货库存管理实时库存、流水记录、盘点、预警系统管理用户、角色、修改密码、操作日志这里有一个设计细节进货和销售都拆成了单据和出入库动作两层。也就是说创建进货单只是登记我们打算进这批货状态是待入库等到供应商货到了库管点一下确认入库库存才真正增加。这样拆的好处是采购和仓库职责分离账面上还没到的货不会提前占库存避免出现账上有货货架没货的尴尬情况。2. 核心功能与业务流拆解2.1 商品与分类管理要注意的细节商品管理看起来最简单就是 CRUD但里面有几个细节特别容易踩坑。一个是商品编码不能随便用自增 ID。我给商品设计了独立的goods_code规则是分类前缀 序号比如DZ-0001表示电器类第一个商品。这个编码是要打到条码上、贴到货架上的如果直接用数据库自增 ID导数据、对接外部系统的时候会非常痛苦。而且要注意goods_code必须加唯一索引否则并发下可能生成重复编码。另一个是单位字段。这个项目里我在商品表上直接存unit值就是箱件瓶这种。有同学会问要不要做计量单位换算比如1 箱 12 瓶我的建议是——先别做。批发超市的库存管理要做到箱瓶切换不是不行但它会把所有入库、出库、库存逻辑都乘以一个换算因子复杂度成倍上升。实际业务中很多批发超市的做法是用最小单位记库存比如瓶但是进货单上可以显示箱数作为参考。第一版上线千万不要贪这种功能等到业务方明确提出来再迭代。还有商品的状态字段。我设计了status1 正常、0 停用。停用的商品不再出现在销售选择列表里但历史单据还能正常显示名称和编码这一点很重要——数据库里永远不要物理删除商品记录否则以前卖过的单子统计报表时全成了空白。删除商品这个操作我在系统里隐藏了只有停用没有删除。2.2 进货入库怎么设计才不容易出错进货入库是批发超市库存系统中业务逻辑最重的一环。一笔采购订单从采购员创建到供应商送货再到库管验收中间可能会发生很多情况部分到货、验收数量不符、有破损拒收等等。我在系统里把进货单状态设计成下面几个待审核采购员创建单据后需要业务主管审核防止乱下单。待入库审核通过供应商还没送货或者送了还没验收入库。部分入库一批货分两车送到可以分两次点确认入库每次只入一部分。已完成全部入库完成单据关闭。已取消审核没通过或者采购取消。对应到数据库就是purchase_order主表加一个status字段明细表purchase_order_item加一个inbound_quantity字段记录本次已入库数量。每次点确认入库系统只允许输入本次实收数量校验它不超过订单数量 - 已经入库数量然后更新主表的累计入库数字。这里有个细节实际业务里供应商送来的数量可能会比订单多比如按整车配送的时候多了几箱。我是怎么处理的给确认入库弹窗里加了一个可选项超收部分按无订单商品入库但默认不允许超过订单量。系统是工具不能替业务流程做决定只能把灵活性和规范性同时提供给用户——超过数量必须选超收入库走另外一个专门的入库流程这样财务对账时能查出来这批多出来的货是谁收的、没下过订单怎么进来的。另外进货价记录在明细行上这一点很多人会漏掉。同样一个商品不同批次进货价不同销售毛利算的是销售收入 - 对应批次的进货成本。虽然做的是移动加权平均还是先进先出这个项目里没做那么深只在明细行存每次进货价方便后续扩展成本核算。但如果你要把毛利算得准至少要保证进货价的字段不丢别在商品表上共享一个 purchase_price否则一旦进价变了历史单据的成本全串了。2.3 销售出库与库存扣减防超卖是第一原则销售出库相对直接选择商品、填数量、生成销售单然后扣减库存。但这里有个所有库存系统都绕不开的技术点——并发扣库存的防超卖。最常见的错误写法是这样的// 错误示范先查再扣线程不安全 Stock stock stockDao.selectByGoodsId(goodsId); if (stock.getQuantity() quantity) { stock.setQuantity(stock.getQuantity() - quantity); stockDao.update(stock); }两个收银员同时卖同一件商品都查到库存还剩 10 件都判断够卖然后各自扣减数据库最后可能只剩 5但实际已经卖出 15 件——库存变成负数了这就是超卖。这个项目的正确做法是在 SQL 层面用原子操作扣减UPDATE stock SET quantity quantity - #{quantity}, update_time NOW() WHERE goods_id #{goodsId} AND quantity #{quantity}这条 SQL 本身就保证了库存不够时更新不会成功受影响行数为 0 时程序抛异常回滚超卖就被挡在了数据库层之外。这里没有用SELECT ... FOR UPDATE悲观锁是因为行级锁在并发量不算特别高单店收银场景时会影响下单响应速度用条件更新这种乐观方式既安全又高效生产环境跑了很久都没出过负数。销售单则和进货单结构对称sale_order主表 sale_order_item明细表。唯一多出来的环节是出库后要写一条库存流水。流水表我专门拆出来了下一节详细讲。2.4 库存预警与盘点让系统帮你发现问题库存预警的逻辑很简单商品表上有warning_stock字段安全库存查询列表的时候实时比较stock.quantity和goods.warning_stock小于或等于就标红提示。但只有这种看列表时提醒是不够的我加了一个预警商品列表页面专门把低于安全库存和高于滞销库存的商品拉出来采购员一上班打开就能看到要补哪些货。盘点这一块我建议做成盘点单模式而不是直接让库管把库存改成实际数。盘点单的模式是选择要盘点的商品 → 系统冻结当前库存数快照 → 库管录入实际盘点数 → 生成盈亏记录 → 确认后一次性更新库存。为什么这么麻烦因为库存账面数和实际数不一致的时候一定要有记录可追查。是漏入库了还是出库多扣了还是被偷了如果没有盘前账存数和盘后实存数的对比就没有任何依据去复盘问题。系统里我加了一个stock_check表和stock_check_item表盈亏结果直接生成流水类型标记为盘点调整这样以后查流水能看到每笔变动的原因。3. 数据库设计与核心实现3.1 表结构设计先画清楚关系再动手数据库设计是这种系统最核心的部分建表之前先理关系。我的核心表有 11 张表名用途关键字段user系统用户username, password, real_name, role_idrole角色role_name, role_codecategory商品分类name, parent_idgoods商品goods_code, goods_name, category_id, unit, purchase_price, sale_price, warning_stock, statussupplier供应商supplier_name, contact, phone, addresspurchase_order进货单主表order_no, supplier_id, total_amount,status, create_user_idpurchase_order_item进货单明细order_id, goods_id, quantity, inbound_quantity, purchase_pricesale_order销售单主表order_no, total_amount, customer_name, create_user_idsale_order_item销售单明细order_id, goods_id, quantity, sale_pricestock库存表goods_id(唯一), quantity, update_timestock_flow库存流水goods_id, flow_type, order_id, change_quantity, balance_quantity, create_time额外还有一张stock_check盘点表和stock_check_item盘点明细表实现方式比较标准就是记录盘点前后的数量差异。一个反常识的设计是库存表没有设计主键 ID只让goods_id做唯一键。因为库存和商品是严格一对一关系加入自增主键反而容易出现两条记录指向同一个商品的数据错误。让goods_id做主键从数据库层面杜绝了一个商品两条库存的问题。进货价和销售价我都存进了明细表这样历史单据不会被商品现价影响。商品表的purchase_price和sale_price只作为默认值开单的时候带出来然后允许用户改。这个设计保证了财务统计时按明细来算才是真实的。3.2 库存流水回答现在有多少和怎么变成这样库存流水是库存管理系统的灵魂。只有库存表你只能知道现在剩多少想知道这个月进来了多少卖出多少损耗多少就完全没辙了。我的stock_flow表每次入库、出库、退货、盘点调整都写一条流水字段包括商品 ID、业务类型1 表示进货入库、2 表示销售出库、3 表示销售退货、4 表示进货退货、5 表示盘点调整、关联单据 ID、变动数量正数增加、负数减少、变动后结存数、操作时间。其中变动后结存数这个字段非常关键。虽然通过流水明细可以一步步推算当时结存但数据量一大推算是很费劲的而且中途如果有手工改动过数据推算结果就会错位。直接在写流水时把当时的结存数记下来后面做任何对账、审计都能快速核对。举个例子某商品当天开单前库存 100早上进了 50流水余额 150中午卖了 30流水余额 120下午盘点调整少了 2流水余额 118到了晚上你在系统里看到的实时库存就是 118。这 4 条流水完整还原了一天的库存变化过程每一笔都有单据号可溯源。3.3 关键 SQL 与动态查询MyBatis 里where和if配合做多条件筛选非常舒服。比如商品列表的综合查询select idselectGoodsList resultTypegoods SELECT g.*, c.name AS category_name FROM goods g LEFT JOIN category c ON g.category_id c.id where if testkeyword ! null and keyword ! AND (g.goods_code LIKE CONCAT(%, #{keyword}, %) OR g.goods_name LIKE CONCAT(%, #{keyword}, %)) /if if testcategoryId ! null AND g.category_id #{categoryId} /if if teststatus ! null AND g.status #{status} /if /where ORDER BY g.id DESC /select再比如销售报表按月统计SELECT DATE_FORMAT(create_time, %Y-%m) AS month, COUNT(*) AS order_count, SUM(total_amount) AS total_sales FROM sale_order WHERE create_time gt; #{startTime} AND create_time lt; #{endTime} GROUP BY DATE_FORMAT(create_time, %Y-%m) ORDER BY month DESC这里提醒两个容易踩的点。第一DATE_FORMAT分组统计很直观但数据量大后性能不行到时候可以用日期维度表或者前端传开始时间和结束时间精确到天替代直接按格式化列 GROUP BY。第二用户输入的时间范围页面端拿到的startTime和endTime要注意别把endTime当天的记录漏掉正确做法是结束日期加一天作为条件或者但把时分秒设为 23:59:59。4. 项目搭建与代码实现4.1 工程结构与框架整合项目是标准 Maven 目录结构ssm-market/ ├── pom.xml └── src/main ├── java/com/market/ │ ├── controller/ // 控制器层 │ ├── service/ // 业务接口 │ ├── service/impl/ // 业务实现 │ ├── dao/ // MyBatis Mapper 接口 │ ├── pojo/ // 实体类 │ └── interceptor/ // 登录拦截器 ├── resources/ │ ├── spring/ │ │ ├── spring-dao.xml // 数据源、SqlSessionFactory、事务 │ │ ├── spring-service.xml // Service 层 事务切面 │ │ └── spring-mvc.xml // 控制器扫描、视图解析器 │ ├── mapper/ // MyBatis 映射 XML │ ├── jdbc.properties │ └── log4j.properties └── webapp/ ├── WEB-INF/ │ ├── web.xml // 配置 Spring、SpringMVC、CharacterEncodingFilter │ └── jsp/ // 视图页面 └── static/ // css、js、image框架整合的核心配置都在spring-dao.xml里!-- 数据源 -- bean iddataSource classorg.springframework.jdbc.datasource.DriverManagerDataSource property namedriverClassName value${jdbc.driver}/ property nameurl value${jdbc.url}/ property nameusername value${jdbc.username}/ property namepassword value${jdbc.password}/ /bean !-- SqlSessionFactory -- bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource/ property namemapperLocations valueclasspath:mapper/*.xml/ property nametypeAliasesPackage valuecom.market.pojo/ /bean !-- 扫描 Mapper 接口 -- bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.market.dao/ /bean事务管理直接用DataSourceTransactionManagerTransactional注解。重点强调一下事务一定要加在 Service 实现类上不要加在 Controller 上。原因很简单一个 Service 方法里做更新主表 写明细 更新库存 写流水四步操作任何一个失败都要全部回滚。如果事务放在 Controller 上等于把业务操作和控制逻辑耦合在一起后续改接口的时候很容易漏掉事务范围。4.2 入库业务的 Service 实现进货入库是整个系统事务性最强的操作核心代码我在PurchaseServiceImpl里是这么写的Override Transactional(rollbackFor Exception.class) public void inbound(PurchaseOrder order, ListPurchaseOrderItem items) { // 1. 创建进货单默认状态待审核 purchaseOrderDao.insert(order); // 2. 批量插入明细 for (PurchaseOrderItem item : items) { item.setOrderId(order.getId()); purchaseOrderItemDao.insert(item); } } Override Transactional(rollbackFor Exception.class) public void confirmInbound(Integer orderId, MapInteger, Integer actualQuantityMap, Integer userId) { PurchaseOrder order purchaseOrderDao.selectById(orderId); if (!2.equals(order.getStatus()) !3.equals(order.getStatus())) { throw new BusinessException(当前单据状态不允许入库); } // 逐行校验实收数量 ListPurchaseOrderItem items purchaseOrderItemDao.selectByOrderId(orderId); for (PurchaseOrderItem item : items) { Integer actualQty actualQuantityMap.get(item.getId()); if (actualQty null) continue; // 本次未入库的行跳过 if (actualQty 0) { throw new BusinessException(实收数量不能小于 0); } if (item.getInboundQuantity() actualQty item.getQuantity()) { throw new BusinessException(累计入库数量超过订单数量商品 item.getGoodsName()); } } // 更新明细的已入库数量 // 更新每个商品的库存原子加 // 写库存流水 // 更新主表状态部分入库/已完成 }这个方法里最关键的是先校验、再更新的顺序。我见过很多新手先把入库数量加到库存里再判断有没有超入结果一旦超入前面已经更新的库存就得再回滚虽然事务能保证回滚但这个逻辑本身就有问题——正确的顺序应该是先算清楚能不能入能入再动手。4.3 出库扣库存的防超卖处理销售出库的 Service 核心逻辑是先插入销售单主表和明细然后循环调用库存扣减每条扣减都是一次条件更新。Override Transactional(rollbackFor Exception.class) public void createSaleOrder(SaleOrder order, ListSaleOrderItem items) { saleOrderDao.insert(order); for (SaleOrderItem item : items) { saleOrderItemDao.insert(item); int rows stockDao.decreaseStock(item.getGoodsId(), item.getQuantity()); if (rows 0) { throw new BusinessException(商品库存不足无法出库 item.getGoodsName()); } // 查询最新库存并写流水 int currentStock stockDao.selectQuantityByGoodsId(item.getGoodsId()); stockFlowDao.insert(StockFlow.builder() .goodsId(item.getGoodsId()) .flowType(2) .orderId(order.getId()) .changeQuantity(-item.getQuantity()) .balanceQuantity(currentStock) .build()); } }这里有一个小坑要提醒decreaseStock返回 0 不代表商品不存在也可能是库存不足。所以如果stock表里根本没有这个商品的记录比如商品刚创建还没有库存记录应当在写库存的时候初始化一条。我的做法是在decreaseStock里先查一下如果没记录就尝试插入一条默认quantity 0的然后再次执行扣减——直接用INSERT IGNORE也能达到类似效果。4.4 前端页面与交互实现前端部分没有用什么特别新的框架用的是 JSP Bootstrap jQuery jQuery Validate。为什么不上 Vue两个原因一是这个系统运行在客户内网浏览器版本可能很老现代前端框架打包出来的产物对老浏览器兼容性不好二是项目开发维护的人对 JSP 熟悉改起来顺手而且报表、打印这些功能在 JSP 里直接拼 HTML 更直白。虽然是传统技术栈但交互上我给了一些体验优化进货单的商品选择用弹窗搜索输入关键字模糊匹配后点选不会一大串下拉列表卡死。销售单支持扫码枪录入商品条码扫进去自动匹配匹配到就加入列表匹配不到就提示未识别商品。库存预警页面上直接用红色高亮低于安全库存的行并且提供一个一键生成采购建议单的按钮把预警商品按不足量带出来。说实话做管理系统前端不需要多炫酷只要操作路径短、常用功能一眼能看到用户就很满意了。5. 部署运行与高频问题排查5.1 本地运行和环境要求我把整个项目打包成标准 WAR 包部署过程基本上是三步环境准备JDK 1.8、Maven 3.6、Tomcat 8.5、MySQL 5.7。初始化数据库执行项目根目录下的init_database.sql脚本会自动建库、建表、插入初始分类和默认管理员账号用户名 admin初始密码 123456系统强制首次登录修改密码。配置数据源修改resources/jdbc.properties里的数据库地址、账号、密码。jdbc.drivercom.mysql.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/market_db?useSSLfalsecharacterEncodingutf8 jdbc.usernameroot jdbc.passwordroot然后把 WAR 包丢到 Tomcat 的webapps目录下启动即可。访问路径默认是http://localhost:8080/ssm-market/。5.2 高频报错与排查思路我整理了几个用户报得最多的错误和处理方法报错信息原因解决办法Access denied for user rootlocalhost数据库密码不对核对 jdbc.properties注意 MySQL 8 以下驱动和 8 驱动 URL 写法不同HTTP Status 404 - Not Found没部署成功或路径不对先确认 Tomcat 启动日志没报异常再检查访问路径是否包含ssm-market上下文页面中文显示乱码请求/响应编码不一致确认 web.xml 里配置了CharacterEncodingFilter且 forceEncoding 设置为 true数据库连接 URL 带characterEncodingutf8登录成功后页面秒跳回登录页Session 失效或拦截器路径配置错误检查拦截器excludePath是否把静态资源和login请求排除了商品列表分页数据重复分页 SQL 的 ORDER BY 不唯一给分页查询加ORDER BY g.id DESC作为兜底排序No qualifying bean of type启动报错Mapper 接口没扫描到检查 MapperScannerConfigurer 的 basePackage 是不是对应 dao 接口所在包Invalid bound statement (not found)Mapper XML 没对应上接口方法确认 mapper XML 的 namespace 是接口全限定名select的 id 和方法名一致5.3 实战中容易踩的坑第一个坑是MyBatis 的大小驼峰映射。数据库字段习惯用下划线命名比如goods_codecreate_user_id但实体类里的字段是驼峰goodsCode、createUserId。如果没在 mybatis-config 里开启驼峰映射查出来所有字段都是 null。settings setting namemapUnderscoreToCamelCase valuetrue/ /settings这个配置我建议所有 SSM 项目都默认开启不然每个resultMap都要手写。但注意开启驼峰后resultType返回 Map 时键名依然是下划线形式这是很多人没注意到的细节。第二个坑是JSP 页面里使用 JSTL 核心标签时格式化问题。库存和金额字段在页面上显示比如 0.00 元和 120.5 件如果没有用fmt:formatNumber格式化会出现 120.5 这种对不上小数位的数字财务那边看着就别扭。正确做法是在 JSP 页面对数字做统一格式处理或者后端 Service 返回前就转成字符串。第三个坑是Tomcat 部署路径大小写。Windows 服务器上没问题Linux 服务器上如果 WAR 包名有大小写访问路径必须严格一致否则 404。我习惯统一用小写命名部署包省得排查这种无意义的问题。第四个坑是退出登录没有销毁 Session。这个问题不报错但隐患挺大——用户在公共电脑上登录关掉页面再打开直接访问销售单页面还能看到上次的数据因为 Session 没超时。我在退出登录的方法里加了session.invalidate()并且在拦截器里对全路径做登录判断这样能确保每次访问都先验证身份。6. 项目扩展方向这套底子还能往哪走这个 SSM 版本的库存系统已经完整跑通核心业务链了但如果你拿它做课设、做毕设或者接了一个乙方项目想往更高的方向扩展这里提供几条我实际思考过的路线。对接条码打印与扫描终端。商品条码目前只是录入和查询用扩展一步可以对接条码打印机把 goods_code 生成 Code128 条码直接打印。扫描枪扫码入库、扫码出库也能做逻辑不复杂就是在 Controller 里加一个按条码定位商品的接口前端一扫就触发。增加库存成本核算。目前进货价存在明细里还没做移动加权平均或先进先出。如果客户需要财务报表要在 stock_flow 表里扩展一个成本单价字段每次入库写流水时计算新的平均成本。这是财务模块最关键的一步。多门店支撑。现在结构是单门店单库存。扩展多门店需要在stock表和stock_flow表加一个shop_id字段再增加一个门店调拨单模块门店 A 出库、门店 B 入库中间算一步调拨流水。表结构已经留了余量改动成本不算大。数据可视化报表。目前报表都是表格形式如果要卖相更好可以用 ECharts 做销售趋势和库存结构分析前端页面加一个仪表盘首页。ECharts 引入是纯静态文件不需要后端改动工作量主要在接口聚合数据上。Spring Boot 重构。如果客户运行环境比较新或者你更熟悉 Spring Boot把 SSM 项目迁到 Spring Boot 的改动主要在配置层。Controller、Service、Dao、Mapper XML 这些代码几乎完全保留把 XML 配置改成自动配置加上少量注解就行。我实测迁移一个模块大约半天到一天时间建议在功能全部验收之后再迁移不要边开发边迁否则问题根源都分不清是业务还是框架。关于采购审批流程、多级审核这些属于通用后台系统的范畴如果有精力可以继续扩展工作流引擎但对库存管理这个核心场景来说先把进销存和库存流水做深做透比堆功能有意义得多。最后分享一点个人心得。库存管理系统看起来到处都是增删改查但真正把业务吃透后你会发现每个字段、每个状态、每张流水表背后都有它存在的理由。我做这个项目时最大的体会是单纯懂技术还不够要蹲在仓库里看库管怎么收货、怎么盘货、怎么对账你才知道系统应该怎么设计。把业务流程走一遍画成状态流转图再回来写代码效率比闷头写高得多。这个项目的源码、初始化 SQL、部署文档都已经打包好了需要的朋友可以直接拿来参考改改包名和业务字段就能架一套自己的库存管理系统。也欢迎在评论区交流你在做 SSM 项目时踩过的坑尤其是库存并发、事务回滚、部署环境这几块经常会有意想不到的惊喜。