SSM在线收银系统源码解析：从环境搭建到事务与库存设计

简介：面向小型零售企业的在线收银系统毕业设计源码，采用Java + SSM框架（Spring、SpringMVC、MyBatis）与MySQL 5.7数据库，基于Tomcat 7部署，开发环境搭配JDK 1.8、Maven 3.3及Navicat 11，可用Eclipse或IDEA直接导入运行。系统覆盖系统用户管理、员工管理、用户管理、商品类别与商品管理、入库管理、销售管理及销售统计等核心模块，适用于超市、便利店等零售场景，也可作为高校计算机专业毕业设计或课程设计的完整参考。压缩包约23.97MB，内含项目源码、说明文档及LW论文材料，已有78人学习下载。研读源码可掌握SSM框架整合、MyBatis持久化操作、前后端数据交互和异常处理等关键环节，说明文档对系统架构、数据库设计及功能模块亦有完整梳理，便于快速搭建环境并开展二次开发。从商品录入、入库到销售统计，覆盖完整业务闭环，对理解电商后台开发很有帮助。

1. 在线收银系统源码：为什么这类 SSM 项目至今还是毕业设计常青树

打开任何一个招聘软件，Java 后端岗位的 JD 里几乎都写着 SSM 或 Spring Boot；而打开任何一个毕业设计选题库，在线收银系统又是最高频出现的名字之一。在线收银系统源码（SSM+Mysql+说明文档+LW）看起来是一个老掉牙的管理系统，但它恰好把 Java Web 开发里最该练的东西都串起来了：SSM 三层架构、MySQL 表关系设计、订单与库存的事务一致性、权限角色划分、还有一套可以拿去做论文支撑的说明文档和 LW（论文/答辩稿）。对即将毕业的学生来说，它不是一个炫技项目，而是一个能在两个月内真正做完、讲清楚、能答辩的完整闭环。

这套源码的典型玩法是：拿来跑通，看懂每张表和每个 Mapper，再自己改几个需求点，比如加一个会员折扣、换一套前端样式、加一个出货单打印，就足够撑起一篇像样的毕业设计论文。本文不编造这份压缩包里到底有几个文件，而是从从业者的角度，讲清楚这类在线收银系统的标准结构、怎么在本机把它跑起来、哪些参数必须调、以及最容易被答辩老师问住的几个坑。

2. 先把 SSM 在线收银的底细摸清楚：模块划分与数据库设计

2.1 在线收银系统到底在管什么：五个核心业务域

市面上能见到的在线收银系统源码，无论前端界面长什么样，后端业务域高度一致。收银系统的本质是「订单 + 商品 + 支付 + 库存 + 权限」五件事的联动，少了任何一个环节，系统都只能叫「商品展示页」而不是收银系统。

第一个域是商品管理，包括商品分类、商品信息、进货价、售价、库存量、预警阈值。第二个域是收银台业务，也就是 POS 的核心：创建订单、选择商品、计算总价、提交订单。第三个域是订单管理，包括订单列表、订单详情、退货/退款操作。第四个域是会员与促销，很多课程设计会把会员折扣、积分抵扣做进来。第五个域是系统管理，涉及用户登录、角色权限、操作日志。

这五个域的关联关系决定了数据库表不会太少。一类典型的表结构是：user用户表、role角色表、menu菜单权限表、category商品分类表、product商品表、orders订单主表、order_item订单明细表、member会员表、stock_log库存流水表。其中orders和order_item是一对多关系，product和stock_log也是一对多关系。这四组关系如果能在论文里画成 ER 图，再用 PowerDesigner 或 Navicat 导出来，答辩时基本就不会被质疑数据库设计能力。

2.2 MySQL 建表语句：订单主表和订单明细表怎么设计才不翻车

在线收银系统中，最容易设计错的是订单表。很多新手会把商品名称、单价、数量直接塞进订单主表里，做成一行一个商品的大宽表。这种做法在数据量小的时候看不出问题，但一旦要统计「某段时间内哪个商品卖得最好」，SQL 就得在订单主表上做字符串拆解，完全没法写。

标准的做法是把订单拆成主表和明细表。主表保存一次收银的整体信息，明细表保存每一件商品的购买信息。以下是这套系统最核心的两张建表语句，可以直接在 Navicat 或 MySQL 命令行里执行：

-- 订单主表：一次收银一条记录 CREATE TABLE `orders` ( `id` int(11) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号，格式如20260612001', `user_id` int(11) DEFAULT NULL COMMENT '操作收银员的用户ID', `member_id` int(11) DEFAULT NULL COMMENT '会员ID，非会员为NULL', `total_amount` decimal(10,2) NOT NULL COMMENT '应收总金额', `discount_amount` decimal(10,2) DEFAULT '0.00' COMMENT '优惠金额', `pay_amount` decimal(10,2) NOT NULL COMMENT '实付金额', `pay_type` tinyint(4) DEFAULT '1' COMMENT '支付方式：1现金 2微信 3支付宝', `status` tinyint(4) DEFAULT '0' COMMENT '0正常 1已退货', `create_time` datetime NOT NULL COMMENT '下单时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';

订单明细表则与主表通过order_id关联。注意这里的一个关键点：明细表里必须冗余保存商品名称和成交单价，而不是通过product_id去实时关联商品表。原因是商品的价格和名称会变，如果订单明细只存 ID，将来查历史订单时价格已经被改掉了，对账就会翻车。

-- 订单明细表：每个商品一条记录 CREATE TABLE `order_item` ( `id` int(11) NOT NULL AUTO_INCREMENT, `order_id` int(11) NOT NULL COMMENT '关联订单主表ID', `product_id` int(11) NOT NULL COMMENT '商品ID', `product_name` varchar(100) NOT NULL COMMENT '商品名称（冗余存储）', `price` decimal(10,2) NOT NULL COMMENT '成交单价（冗余存储）', `quantity` int(11) NOT NULL COMMENT '购买数量', `subtotal` decimal(10,2) NOT NULL COMMENT '小计金额', PRIMARY KEY (`id`), KEY `idx_order_id` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';

这两张表的逻辑说明很简单：orders管整体，order_item管细节。查询订单详情时，先按order_no或id定位主表，再通过order_id把明细列表带出来。subtotal字段是冗余计算列，它的值等于price * quantity，可以在 Service 层算好再插入，不要在 SQL 里每次现算。price和product_name的冗余是表设计里最值得在论文里写一笔的地方——这是典型的「以空间换一致性」的设计取舍。

2.3 收银核心事务：扣库存和生成订单为什么必须放在同一个事务里

在线收银系统里最容易被答辩老师追问的问题是：用户下单成功后库存是怎么扣的？很多人写出的代码是「先插入订单，再更新库存」，中间如果插入订单成功但更新库存失败，就会出现收了钱但库存没扣的脏数据。这就是事务边界没划对。

正确的做法是把「插入订单主表 + 插入订单明细 + 扣减库存 + 写入库存流水」放在同一个 Spring 事务里，任何一步失败，全部回滚。以下是在 SSM 架构中 Service 层标准的事务写法，用的是 Spring 的声明式事务：

@Service public class OrderServiceImpl implements OrderService { @Autowired private OrderMapper orderMapper; @Autowired private OrderItemMapper orderItemMapper; @Autowired private ProductMapper productMapper; @Autowired private StockLogMapper stockLogMapper; @Override @Transactional(rollbackFor = Exception.class) public boolean createOrder(OrderDTO dto) { // 1. 创建订单主表记录，状态为正常 Orders order = new Orders(); order.setOrderNo(generateOrderNo()); order.setUserId(dto.getUserId()); order.setMemberId(dto.getMemberId()); order.setTotalAmount(dto.getTotalAmount()); order.setPayAmount(dto.getPayAmount()); order.setCreateTime(new Date()); orderMapper.insert(order); // 2. 遍历购物车商品，逐条写入明细并扣减库存 for (OrderItemDTO item : dto.getItems()) { OrderItem orderItem = new OrderItem(); orderItem.setOrderId(order.getId()); orderItem.setProductId(item.getProductId()); orderItem.setProductName(item.getProductName()); orderItem.setPrice(item.getPrice()); orderItem.setQuantity(item.getQuantity()); orderItem.setSubtotal(item.getPrice().multiply(new BigDecimal(item.getQuantity()))); orderItemMapper.insert(orderItem); // 扣库存：UPDATE 语句中带库存条件，防止超卖 int rows = productMapper.deductStock(item.getProductId(), item.getQuantity()); if (rows == 0) { throw new RuntimeException("商品库存不足，订单已回滚"); } // 3. 写入库存流水，方便后期追溯 StockLog log = new StockLog(); log.setProductId(item.getProductId()); log.setChangeType(1); // 1出库 2入库 log.setChangeCount(item.getQuantity()); log.setCreateTime(new Date()); stockLogMapper.insert(log); } return true; } private String generateOrderNo() { return "DS" + System.currentTimeMillis(); } }

逻辑说明：@Transactional(rollbackFor = Exception.class)是 SSM 项目里最标准的声明式事务写法，注意一定要指定rollbackFor，否则 Spring 默认只在遇到 RuntimeException 时才回滚，而很多检查异常会被错误地提交。deductStock这个 Mapper 里的 UPDATE 语句必须写成UPDATE product SET stock = stock - #{count} WHERE id = #{productId} AND stock >= #{count}，通过受影响行数rows == 0来判断是否超卖。这是防止并发超卖最简单也最实用的手段，比先 SELECT 再 UPDATE 的方式可靠得多。

关于generateOrderNo()，实际项目中建议把时间戳做得更细，例如yyyyMMddHHmmss加三位随机数，避免同一毫秒内并发生成重复单号。这里为了演示简洁用了时间戳，你在改造时可以把加一个 Redis 自增或数据库序列。

3. 把在线收银系统跑起来：SSM 项目从导入到启动的完整路径

3.1 拿到源码后第一件事：检查 JDK、Maven、MySQL 三个版本对不对得上

很多同学从网上下载 SSM 在线收银系统源码后，第一步就卡在环境上。SSM 项目对环境的敏感度很高，JDK 版本、Maven 版本、Tomcat 版本、MySQL 版本四个只要有一个不匹配，就会出现各种莫名其妙的报错。这里把最常见的版本兼容组合列出来，跟着走能省下大量排错时间。

这里特别要提 MySQL 8.0 的坑：老项目里的 JDBC 驱动通常写的是com.mysql.jdbc.Driver，这个类名在 MySQL 8.0 里已经废弃，必须改成com.mysql.cj.jdbc.Driver。另外 8.0 默认启用 SSL 连接，如果连接串里没加useSSL=false，启动时会报SSL connection error或大量 warning 日志。这两个问题都是在线收银系统这类老 SSM 项目在 MySQL 8.0 上最常见的启动失败原因。

3.2 导入数据库脚本：一条命令把库表和数据装进 MySQL

源码包里一般会带一个.sql文件，例如db_online_pos.sql，里面包含建库、建表、插入初始数据（管理员账号、测试商品、测试订单）等语句。导入时不要用鼠标右键「运行 SQL 文件」这种操作，因为有时候编码不对会导致中文乱码，推荐用命令行导入，字符集明确指定为 utf8mb4：

mysql -u root -p --default-character-set=utf8mb4 < db_online_pos.sql

如果你用的是 Navicat，也可以新建数据库后右键「运行 SQL 文件」，但导入前先确认数据库字符集是 utf8mb4，否则商品名称里的中文会变成问号。

导入完成后，执行以下三条 SQL 验证数据是否完好：

-- 查看所有表是否创建成功 SHOW TABLES; -- 查看用户表中是否有初始管理员账号 SELECT * FROM `user`; -- 查看商品表中是否有测试商品 SELECT id, product_name, stock FROM product LIMIT 10;

这里重点检查user表的初始账号。很多源码的默认管理员是admin / 123456，但密码字段存的不是明文而是 MD5 值。如果你用明文登录不进去，不是代码错了，而是密码本来就被加密存储。破解办法是先到源码的UserServiceImpl里看它用的加密方式，如果是MD5，就把 SQL 里的初始密码改成MD5("123456")的密文值。不要为了省事直接改代码绕过加密，答辩老师一定会问密码安全性。

3.3 修改 SSM 配置文件：jdbc.properties 里必改的四个参数

源码导入 IDEA 后，第一次启动前必改的文件是jdbc.properties，通常在src/main/resources目录下。这个文件里配置了数据库连接信息，不改的话要么连不上库，要么连错库。

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/online_pos?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=你的数据库密码

参数说明：jdbc.driver如果你的 MySQL 是 5.7 就保持com.mysql.jdbc.Driver不变；如果是 MySQL 8.0，改成com.mysql.cj.jdbc.Driver并确保 pom.xml 里 MySQL 驱动的版本是8.0.x。jdbc.url中的useSSL=false是为了关闭 MySQL 8.0 的 SSL 报错；serverTimezone=Asia/Shanghai是为了解决时间差 8 小时的问题，不加这个参数，订单时间会比实际时间晚 8 个小时，收银系统里对账会乱。数据库名online_pos必须和你导入 SQL 脚本时建的库名完全一致，大小写也要一致，Linux 环境下 MySQL 的表名是区分大小写的，Windows 下不区分，但提交到服务器后行为会不一样。

3.4 启动顺序与验证：从 Tomcat 启动到前端页面能登录

SSM 在线收银系统是典型的单体 Web 应用，启动方式是在 IDEA 里配置 Tomcat 后点击运行。启动顺序上没有什么复杂的依赖关系，只要 MySQL 已经启动、jdbc.properties的连接信息正确，Tomcat 起来后项目会自动完成数据库连接。

项目启动成功的标志不是 Tomcat 端口起来，而是日志里出现Spring Context 初始化成功或类似的关键字，然后访问http://localhost:8080/项目名/login.jsp能看到登录页面。如果你在 IDEA 里部署时设置了application context为/online_pos，那访问路径就是http://localhost:8080/online_pos/login.jsp。

用默认管理员账号登录后，第一个要验证的功能是「新建订单」。手动选择几个商品、添加数量、点击结算，然后去数据库里查orders表和order_item表是否新增了记录，同时查看对应商品在product表里的库存是否减少了。这个流程如果在三张表里都能对得上，说明核心链路已经跑通了。

4. SSM 在线收银系统的必调参数与核心代码改造点

4.1 MyBatis 的 Mapper 文件里，最值得改的是库存扣减的 SQL

很多 SSM 在线收银系统的源码里，扣库存的 SQL 写得不严谨，常见写法是：

<update id="deductStock"> UPDATE product SET stock = stock - #{count} WHERE id = #{productId} </update>

这种写法在单用户测试时没问题，但并发场景下两个收银员同时卖同一件商品，可能出现库存扣成负数。把 SQL 改成带库存条件的写法后，并发安全才有保障：

<update id="deductStock"> UPDATE product SET stock = stock - #{count} WHERE id = #{productId} AND stock >= #{count} </update>

在OrderServiceImpl里，这条 update 的返回值rows如果为 0，则说明库存不足或商品不存在，直接抛出异常触发事务回滚。这里的核心逻辑是：用数据库的原子 UPDATE 代替「先查询再更新」，避免了并发下两个事务同时读到相同库存的经典超卖问题。

4.2 分页查询在 SSM 里的标准写法：PageHelper 的接入方式

在线收银系统的订单列表、商品列表都需要分页。常见源码里会直接引入 PageHelper 插件，但也有不少老项目是自己手写 LIMIT 分页的。手写分页本身没错，但 PageHelper 的接入成本极低，而且答辩时能多讲一个「插件原理」。

在 pom.xml 中加入依赖后，只需要在 MyBatis 配置文件中加一行插件配置：

<plugins> <plugin interceptor="com.github.pagehelper.PageInterceptor"> <property name="helperDialect" value="mysql"/> <property name="reasonable" value="true"/> </plugin> </plugins>

然后在 Service 层调用：

PageHelper.startPage(pageNum, pageSize); List<OrderVO> list = orderMapper.selectOrderList(condition); PageInfo<OrderVO> pageInfo = new PageInfo<>(list);

参数说明：PageHelper.startPage()只对接下来执行的第一条 SQL 生效，所以必须在查询语句之前调用。reasonable=true的作用是当页码超出总页数时自动归为最后一页，避免出现页面空白。这个功能在收银系统的订单列表里很重要，因为收银员可能快速翻页，翻过头了不应该报错。

4.3 前端收银台与后端接口的数据交互：JSON 格式与 Ajax 请求

在线收银系统的前端通常是用 JSP 写的，但收银台页面会大量使用 Ajax 与后端交互，比如选择商品后实时计算总价、点击结算时提交订单。这类代码的典型写法是：

$.ajax({ url: 'order/createOrder', type: 'POST', contentType: 'application/json', data: JSON.stringify({ userId: 1, items: [ {productId: 3, quantity: 2}, {productId: 7, quantity: 1} ] }), success: function (res) { if (res.code === 200) { alert('订单创建成功，单号：' + res.data.orderNo); location.href = 'order/detail?id=' + res.data.id; } else { alert(res.msg); } } });

后端接收时，Controller 里不能直接用OrderDTO接收，因为 SSM 默认的@RequestBody依赖 Jackson 的自动序列化，如果前端传的字段名和后端 DTO 不一致，会导致所有字段都是 null。经验是前端字段名严格对应后端 DTO 的驼峰属性名，也就是productId、quantity、userId保持一致。另一个常见坑是日期字段，如果 JSON 里传了时间字符串，后端 DTO 里的 Date 类型字段需要加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")，否则会解析失败。

5. SSM 在线收银系统避坑指南：从环境到业务的 5 条真实踩坑记录

5.1 现象：Tomcat 启动后页面 404，访问不到 login.jsp

原因：项目部署的application context和访问路径不一致。IDEA 里配置 Tomcat 时，Deployment标签页的Application context默认是/项目名，如果你访问时少写了这个前缀，就会 404。

解决：确认 IDEA 底部Server面板里显示的Deploy路径，比如/online_pos_war_exploded，然后访问http://localhost:8080/online_pos_war_exploded/login.jsp。嫌麻烦可以把 Application context 改成/，但这只适用于本机调试，部署到服务器时建议保留项目名前缀。

5.2 现象：使用 MySQL 8.0 启动项目，报 ClassNotFoundException: com.mysql.jdbc.Driver

原因：MySQL 8.0 把驱动类名改成了com.mysql.cj.jdbc.Driver，而老项目 pom.xml 里引的是 5.x 驱动，类名还是旧的那个。

解决：修改 pom.xml 中的 mysql-connector-java 版本为 8.0.x，并把jdbc.properties里的 driver 改成com.mysql.cj.jdbc.Driver。改完后 Maven 重新导入依赖，clean 再启动，报错即消失。

5.3 现象：页面中文正常，但订单里的中文变成了问号或者乱码

原因：数据库连接的characterEncoding=UTF-8参数缺失，或者 MySQL 库表本身字符集是 latin1。SSM 项目里最常见的乱码源头是jdbc.url没加编码参数，导致从 Java 到 MySQL 的传输过程用了默认字符集。

解决：先检查jdbc.url是否包含characterEncoding=utf8，然后确认导入 SQL 脚本时用了--default-character-set=utf8mb4，最后用ALTER TABLE orders CONVERT TO CHARACTER SET utf8mb4;修复已有表的字符集。三步都做完，重新插入一条测试订单验证中文商品名显示。

5.4 现象：下单成功，但库存没有减少

原因：Service 层方法没有加@Transactional注解，或者注解是@Transactional但 rollbackFor 没指定。Spring 的声明式事务默认只拦截 RuntimeException，而代码里抛出的是 Exception 类型时事务不会回滚。

解决：统一在 Service 实现类的方法上写@Transactional(rollbackFor = Exception.class)，并在spring-mvc.xml或spring-context.xml中配置<tx:annotation-driven transaction-manager="transactionManager"/>，确保注解被 Spring 容器识别。

5.5 现象：订单提交后总金额多了 0.01 元，对账对不上

原因：BigDecimal 的精度问题。源码里如果用了 double 或 float 计算金额，会出现 0.1 + 0.2 = 0.30000000000000004 这种精度丢失，导致金额有零点几分的误差。收银系统最忌讳金额对不上账。

解决：所有金额计算必须用 BigDecimal，并且用BigDecimal.valueOf()或new BigDecimal(String)来构造，不要用new BigDecimal(0.1)这种直接传 double 的构造方式。在OrderServiceImpl里统计小计时，把所有单价和数量计算统一封装成一个computeSubtotal()方法，避免散落多处。

6. 把在线收银系统玩出差异化：三个值得改造的进阶方向

在线收银系统源码跑通只是起点，想在毕业设计里拿高分，或者想把它写进简历项目，至少要改造一个能讲出设计思路的功能点。这里分享三个我见过的、在 SSM 架构下改动成本低但答辩效果好的方向。

第一个方向是引入库存预警。在product表增加warning_stock字段，收银台页面加载时查询库存低于预警值的商品，在页面顶部用高亮列表展示。这个功能实现起来就是一个多表关联查询加一个前端判断，但答辩时可以说「通过库存预警避免了超卖与缺货」，业务价值非常直观。

第二个方向是把支付方式从纯数字枚举改成支付流水表。新增payment_log表，记录订单号、支付方式、支付金额、操作员、支付时间。订单表里只保留pay_amount和pay_type，支付细节都放流水表。这样论文里可以说「实现了支付与订单的分离，便于后期接入第三方支付」，这是从课程设计向工程化项目靠拢的一个重要标志。

第三个方向是增加日结报表。写一个ReportController，按日期统计当日订单数、总销售额、退款金额、净营收，输出一张简单的统计页。这条功能几乎必被答辩老师问到「你系统里怎么知道今天赚了多少钱」，提前做了这个功能，答辩时会从容很多。实现方式是SELECT DATE(create_time), COUNT(*), SUM(pay_amount) FROM orders WHERE status=0 GROUP BY DATE(create_time)，在 Service 层聚合后返回前端。

从我个人经验来讲，在线收银这类 SSM 毕业设计项目，最大的价值不是你用了多新的技术栈，而是你能不能把一条「下单扣库存」的链路讲透。技术栈永远是 SSM，但你要能在事务、并发、冗余字段、权限控制这几个点上说出为什么这么设计，这套源码才算真正吃透了。至于那些版本兼容问题、MySQL 8.0 的驱动坑、BigDecimal 精度坑，踩过一次之后就会形成肌肉记忆，以后无论是做 Spring Boot 项目还是工作后的真实业务系统，这些经验都能直接迁移。希望这套源码能成为你 Java Web 路上第一个能完整跑通、讲清、改动的项目，也帮你在答辩或面试时少一点慌张、多一点底氣。

本文还有配套的精品资源，点击获取