上周刚交付了一套给本地连锁超市做的 POS 收银管理系统项目代号就是标题里的 springboot_ssm866。很多朋友一听“POS”就以为只是收银台扫码收钱实际做完才发现它其实是把商品、库存、会员、促销、订单、报表串起来的一套收银运营系统。这套系统上线后稳定跑了三个门店单量不算大但每一个环节都要保证账目能对上、库存不超卖这里面踩过的坑和总结出来的经验值得单独写一篇。如果你正准备做 Java 方向的毕业设计或者公司想自建一套超市/便利店收银系统又或者刚接手类似项目不知道从哪下手这篇可以帮你少走不少弯路。1. 先弄清楚这套POS系统要解决超市的哪几件事1.1 POS不是一张收银页面我见过不少人把 POS 系统简化成“前端扫码 后端记录订单”导致需求评审时漏了一堆核心功能。真实超市收银流程远比想象中要重收银员扫码商品要能立刻被识别出来顾客有会员卡要自动带出会员价商品参加满减要能在结算时自动算一笔单子付完款库存要同步扣减小票还要能打印出来晚上关店店长要看当天的销售额、毛利、退货情况月底还要对账。这套 springboot_ssm866 项目的完整定位是面向中小型超市、便利店的 Web 端收银与后台管理系统一台普通电脑加一台小票打印机就能支撑一个收银台。1.2 拆出六类核心业务我在做需求分析时把整个系统拆成了六个核心域这也是后续建表、分模块的底层依据商品中心商品分类、商品档案、条码管理、进价/售价/会员价、库存数量。收银中心购物车、结算、支付方式现金/微信/支付宝、小票打印。会员中心会员档案、会员价、积分累计、充值余额。库存中心入库、销售出库、退货入库、盘点调整、库存流水。促销中心整单折扣、单品促销、满减规则跟着收银结算一起生效。报表系统日结报表、商品销售排行、利润统计、经营趋势。这六个域一旦理清后面写代码就有了明确的边界。很多新手项目做不好不是技术不行而是上来就建表结果业务逻辑全堆在一个 Controller 里改一个功能牵一发动全身。1.3 技术选型Spring Boot SSM 为什么够用标题里的“springboot SSM”其实是这样分工的Spring Boot 负责快速搭建项目、内嵌 Tomcat、自动配置数据源SSM 指的是 Spring、Spring MVC、MyBatis 这三件套。Spring 管对象Spring MVC 接管 Web 请求MyBatis 负责跟 MySQL 打交道。选这套组合的直接原因是团队对这套技术栈最熟而且它是 Java 后端项目里社区资料最多的方案之一遇到问题网上基本都能查到解决方案。对于小型超市的规模完全不需要上 Spring Cloud 微服务那套单体应用加一个 Tomcat 就足够运维成本还低。有一点要提醒搭项目时建议用 Spring Boot 2.7 系列别一上来就上 3.x。原因在于 Spring Boot 3 要求 JDK 17而且把javax.*换成了jakarta.*很多老的 MyBatis 兼容方案要跟着改。如果你用的还是 JDK 8老老实实 Spring Boot 2.7 MyBatis-Plus 3.5这一套我已经跑通好几次最省心。2. 整体架构从收银终端到数据库的分层设计2.1 部署形态先想清楚超市的收银场景和普通的后台管理系统不一样收银台是高频操作界面要简洁、按钮要大、回车键能快速结账。我在这个项目里选了传统 B/S 架构前端用 Thymeleaf 模板加 Bootstrap 加 jQuery后端负责接口和页面渲染。新手容易纠结要不要前后端分离。我明确说如果是单店或几台收银机的中小超市服务端渲染就够了省掉 Vue、跨域、JWT 这一堆事。反过来如果要做大商城、多端开放那再考虑 Spring Boot Vue 前后端分离也不迟。2.2 后端分层结构项目目录结构我按标准的三层架构来组织com.cloud.pos ├── controller // 接收请求、参数校验 ├── service // 业务逻辑、事务控制 ├── mapper // MyBatis 数据持久层 ├── entity // 数据库实体 ├── dto // 前端交互对象 ├── config // 拦截器、全局异常配置 └── utils // 条码生成、小票格式化等工具Controller 要薄Service 要厚事务放在 Service 层。这条原则看着简单很多人实际写的时候就把查询逻辑直接堆在 Controller 里后面想加事务和权限时非常痛苦。不同角色的操作入口分为两类收银员进入“收银台”页面操作扫码、结算、退货店长/老板进入“后台管理”页面操作商品、库存、报表、员工账号。这个角色分界在权限设计里非常关键。2.3 模块间的数据流整个系统最核心的一条数据流是收银链路收银台扫码 → 根据条码查到商品 → 加入购物车 → 结算时校验会员和促销 → 计算应收金额 → 生成订单主表和明细表 → 扣减库存 → 生成支付流水 → 打印小票 → 同步累计会员积分。这个链路里的每一步都要有对应的数据落库不能只在前端算完就完事。否则日结时你根本无法还原某一笔交易当时到底发生了什么。3. 数据库设计核心表的落地方案数据库设计是这类系统能不能稳定跑起来的分水岭。很多项目翻车都是因为表设计太随意比如金额用 Float、库存没有版本控制、订单没有状态字段。这里我把核心表结构直接整理出来你可以照着改。3.1 商品相关表商品分类表t_category字段比较简单id、name、parent_id、sort、status。商品表t_product是库存和价格的源头字段我列几个最关键的字段类型说明idbigint主键barcodevarchar(32)商品条码有索引namevarchar(100)商品名称category_idbigint所属分类unitvarchar(10)单位例如“瓶”“袋”purchase_pricedecimal(10,2)进价/成本价sale_pricedecimal(10,2)正常售价member_pricedecimal(10,2)会员价stockint当前库存versionint乐观锁版本号statustinyint1上架 0下架金额字段必须用decimal(10,2)绝不能用 float 或 double。二进制浮点数在计算金额时会出现 0.1 0.2 0.30000000000000004 这种问题收银算错一分钱都会让你头疼。商品条码字段一定要加索引因为收银台最高频的操作就是按条码查询。3.2 订单主表与明细表订单一定要拆主表和明细表。主表记录一笔订单的整体信息明细表记录这一笔单里包含哪些商品。t_order主表字段字段类型说明idbigint主键order_novarchar(32)订单号唯一索引store_idbigint门店IDcashier_idbigint收银员IDmember_idbigint会员ID可为空item_countint商品种类数total_amountdecimal(10,2)商品原价合计discount_amountdecimal(10,2)优惠总金额pay_amountdecimal(10,2)实际应收pay_typetinyint支付方式statustinyint1正常 2已退货create_timedatetime下单时间t_order_item明细表字段id、order_id、product_id、barcode、product_name、sale_price、quantity、amount、discount_amount、cost_price。明细表里冗余存商品名称和条码很关键。商品档案以后可能改名但历史订单要保留当时的商品信息所以不能只存 product_id 再去关联查。3.3 库存与库存流水表库存字段直接冗余在商品表里但这个方案必须有“防超卖”机制我在第四章具体讲。同时还需要一张t_stock_log库存流水表记录每一笔库存变动。t_stock_log字段id、product_id、change_type1采购入库、2销售出库、3退货入库、4盘点调整、quantity、before_stock、after_stock、operator_id、create_time。流水表存在的意义是溯源某一天某个商品库存突然对不上可以通过流水把每一笔变动还原出来。超市库存盘点是高频操作没有流水表盘点差异根本查不出发在哪一天哪一单。3.4 编码风格与索引设计主键统一用自增 bigint。订单号不要用自增主键直接展示要用业务号我这里的生成规则是yyyyMMdd storeId 6位随机数/当天序号。需要加索引的字段barcode、order_no、order_item.order_id、stock_log.product_id、order.create_time。索引不是越多越好但上述这些是查询高频字段没有索引会出大事。4. 核心代码落地扫码、结算、会员、促销一条链路4.1 收银页面的交互设计收银台页面在 Web 端要做成全屏布局中间一个大输入框收银员光标默认停留在扫码框内。扫码枪本质上就是键盘输入设备扫一下条码字符串再加一个回车所以前端只需要监听回车事件。后端查询商品接口可以做成防重查询同样的条码在 1 秒内连续请求直接返回缓存结果。因为顾客买同一种商品连续扫两次是很常见的没必要每次都查数据库。Controller 里查询商品的核心逻辑Controller RequestMapping(/cashier) public class CashierController { GetMapping(/product) ResponseBody public ResultProductVO getProduct(RequestParam String barcode) { // 优先查Redis缓存没有则查数据库 ProductVO product productService.findByBarcode(barcode); if (product null) { return Result.error(未找到该商品); } return Result.success(product); } }4.2 购物车与结算的事务控制前端购物车可以放在 Session 或 Redis 里。收银员扫一个加一个每一行展示商品名、单价、数量和小计。点击“结算”或者按快捷键 F1前端把购物车数据提交给后端。这里有个关键设计购物车数据只是展示用的草稿真正的金额计算必须在后端重新算一遍前端传过来的单价和总价一律不信任。后端结算伪代码Service public class CheckoutServiceImpl implements CheckoutService { Override Transactional(rollbackFor Exception.class) public PayResult checkout(CheckoutRequest request) { // 1. 校验收银员权限 // 2. 遍历明细逐个查询商品最新价格 // 3. 计算会员价/促销折扣 // 4. 调扣库存方法逐个商品做条件更新 // 5. 生成订单主表、明细表、支付流水 // 6. 累计会员积分 return PayResult.success(orderNo); } }注意结算方法上要加Transactional这保证了“扣库存失败则订单不落库”这个业务约束。如果不用事务会出现订单生成了但库存没扣或者库存扣了但订单没生成日结时对账必出问题。4.3 扣库存的防超卖写法库存扣减我用的是不带版本号的原子更新写法本质上是一个条件更新update iddeductStock update t_product set stock stock - #{quantity} where id #{productId} and stock #{quantity} /updateand stock #{quantity}这个条件就是防超卖的关键。如果影响行数为 0说明库存不足业务层立即抛异常回滚。这样即使两个收银员同时买同一件最后一件商品数据库层面的行锁也能保证只有一个人成功。我之前还见过用程序先查库存再判断够不够的写法并发一上来必超卖。这种校验放到 SQL 条件里是数据库层面最便宜的防超卖方案。4.4 会员价与促销的计算顺序会员和促销是收银链路里最容易算错的地方。我的处理顺序是先判断是否会员会员价取商品表里的member_price。再判断该商品是否参与单品促销如果促销价更低取促销价。最后做整单满减优惠。这里面要特别注意促销区间的时间判断比如某商品 6 月 1 日到 6 月 7 日促销收银当天必须落在区间内才能生效。我把促销规则单独放在t_promotion_rule表里结算时先加载生效中的规则再逐项匹配避免把促销逻辑写死在代码里。4.5 小票打印的落地Web 端打印小票有两种方案一种是前端window.print()打印 HTML 样式另一种是后端生成纯文本拼接走小票打印机指令。我项目里选的是前端打印方案页面里单独放一个隐藏的小票模板区结算成功后用 CSS 控制只打印该区域打印结束自动清空。小票固定输出内容阳光超市 单号: 20250612001 收银员: 张三 ------------------------ 商品名 数量 金额 农夫山泉 1 2.00 ------------------------ 合计: 2.00 实收: 2.00 支付方式: 微信 时间: 2025-06-12 10:30:00小票打印是收银员每天要操作几十次的功能宁可在开发时多花一天调样式也不要在上线后让收银员骂一周。5. 库存、退货、日结对账收银系统最容易翻车的三个点5.1 库存扣减的补充要点前面提到的条件更新扣库存解决了并发超卖问题但还有两个坑要说明。第一个坑是代码里的库存同步。如果每次下单都直接更新t_product.stock同时还要写t_stock_log流水这两个操作必须在同一个事务里。否则扣了库存但流水没记录盘点时就无法追踪。第二个坑是数据库行锁可能导致的死锁。多个商品在一个订单里同时扣库存时要对商品 ID 做排序。比如购物车里有商品 A、B、C要保证所有并发请求都按 A、B、C 的顺序去执行更新而不是 A→C→B 或者 B→A→C 乱序。“边扫边结算”的场景很少但一旦并发起来乱序更新就容易死锁回滚重试又导致收银员体验变差。5.2 退货逻辑怎么设计退货在 POS 系统里极其常见顾客买完发现不合适回头就退。退货设计有两个主流方案一种是直接把原订单删除或者标记退货状态然后生成一张负数订单另一种是从头到尾生成一张order_type 2的退货单正向销订单状态不变。我推荐第二种。原因是删除订单和负数单都会让日结报表算法变得很绕而完整的退货单可以让报表和库存流水完全串联起来。退货时主表t_order.status置为“已退货”同时新增一张退货单明细中商品数量为负库存做“退货入库”处理。退货单和原单之间要有refund_order_no字段关联。对账时看到一笔退款能立刻找到原始销售单看到原始销售单也能知道它是否已经退过避免重复退货。5.3 日结对账每天关店后店长要看到一张清晰的日结报表。报表要展示当天销售总单数、销售额、退款额、实际净销售额、商品销售排行。我实现了一个定时任务每天凌晨跑前一天的汇总数据写入独立的t_daily_report表。这里特别提醒日结报表的数据不要实时汇总订单表因为订单表数据量大之后每次读报表都全表扫描会拖慢收银性能。定时任务在凌晨跑一次把结果落表白天查报表直接读聚合结果。对于中小超市的量级这个方案简单高效。日结报表的 SQL 核心逻辑SELECT DATE(create_time) AS biz_date, COUNT(*) AS order_count, SUM(pay_amount) AS pay_amount, SUM(CASE WHEN status 2 THEN pay_amount ELSE 0 END) AS refund_amount FROM t_order WHERE create_time #{date} AND create_time DATE_ADD(#{date}, INTERVAL 1 DAY) GROUP BY DATE(create_time);报表落表后还要对账系统里的销售额要和支付渠道的对账单对上。如果不一致优先查退货单、支付流水和磁盘上的小票日志。我在这套系统里额外加了一张t_pay_log每一笔支付成功都写一条流水对账时逐笔比对问题能缩小到具体某一笔交易。6. 权限设计、操作日志与多门店支持6.1 用户-角色-权限模型超市入职的收银员可能很多但权限不能人人相同。核心原则是收银员只能进收银台可以查自己的销售记录但不能看成本价也不能改后台配置店长可以做日结、看报表、管商品老板/管理员能管员工账号和各门店数据。我用的是经典 RBAC基于角色的访问控制模型三张表用户表、角色表、用户角色关联表。权限点可以在代码里用注解或拦截器实现。Spring Boot 里最简单的做法是自定义一个HandlerInterceptor在进入 Controller 前校验当前用户的角色和权限。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { HttpSession session request.getSession(); User user (User) session.getAttribute(user); if (user null) { response.sendRedirect(/login); return false; } // 角色和操作权限校验 return true; } }用拦截器而不是每个 Controller 复制粘贴校验逻辑代码能清爽很多。6.2 操作日志涉及钱的功能全都要记日志登录、改价、退货、库存调整、给会员充值。我建了t_oper_log表字段包括操作人、操作类型、操作内容、IP、时间。这些日志不仅是审计需要更是排查问题时的重要现场。之前有一次退货金额对不上就是靠日志还原了操作人手动改了一个折扣参数才找到原因。6.3 多门店的数据隔离如果是连锁超市多门店是最常见的需求。我在这里的设计是所有业务表都带store_id字段查询时强制带门店维度。商品档案可以在总部统一维护但各门店库存独立。订单表、库存表、报表表全部按 store_id 区分。这一步做在前面很重要。表结构已经上线再补门店维度要改的不仅是表还有所有查询 SQL工作量翻倍。7. 打包部署与上线后踩到的坑7.1 从源码到生产环境的打包项目基于 Maven 构建打包命令很简单mvn clean package -DskipTests打完包在target目录下会生成一个可执行 jar比如pos-server.jar部署方式可以直接用java -jar pos-server.jar --spring.profiles.activeprod如果是正式环境我习惯用外部配置文件和 jar 分离部署修改数据库连接或端口时不用重新打包。配置项写在application-prod.yml里启动命令带上 profile 就能切环境。数据库连接串里最容易踩的坑是时区MySQL 8 必须显式指定spring: datasource: url: jdbc:mysql://localhost:3306/pos_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai不写serverTimezoneJava 和 MySQL 的时区不一致订单时间会差 8 个小时日结报表一眼看过去全是错账。7.2 实测踩过的三个坑第一个坑是金额精度。初期代码里用 double 算金额结果某天报表发现一笔订单多了一分钱。排查后发现是商品单价 3.45 元乘以数量 7二进制浮点数计算出来是 24.150000000000002。改成 BigDecimal 后后端所有金额计算统一走setScale(2, RoundingMode.HALF_UP)问题消失。第二个坑是内嵌 Tomcat 的并发限制。Spring Boot 默认内嵌 Tomcat 是工作线程池配置参数太高或太低都会出问题。中小超市收银高并发压力不大但遇到节假日促销会有短时集中结算。我在配置里显式设置了server: tomcat: max-threads: 200 min-spare-threads: 20 max-connections: 10000别小看这几个参数。默认配置在促销高峰期会排队收银员那边按了结算半天没反应体验非常差。第三个坑是拿到别人的 jar 包想逆向改成自己的项目。有一次同事接手一个部署好的 jar没有源码只有一份可执行文件。我用了反编译工具把 class 还原成源码大致看懂了表结构和接口但这种操作只能用来应急学习和排查千万别依赖它做二次开发。最好还是拿到完整源码用 Git 管理版本后续改需求才靠谱。7.3 上线后的一点个人体会这套系统上线之后我自己回访过两次收银台。第一次去发现收银员把扫码框的输入法设置成了中文导致条码扫码进去变成汉字后来在页面里限制了输入法自动切换。第二次去发现小票打印经常空半张纸排查后是打印样式里用了固定高度 div改了样式后解决。做这类业务系统真正拉开差距的不是框架用得多花哨而是能不能在收银员按下那一下“结算”的时候把所有账算对、让库存扣准、让小票顺利打出来。Spring Boot SSM 这套组合足够可靠剩下的就是耐心把业务细节抠到位。希望这篇项目拆解能帮你把自己的收银系统做稳少踩几个我已经替你踩过的坑。