简介这份资源是面向高校计算机相关专业学生与Java初学者的一套SSM超市管理系统课程设计完整源码围绕商品、库存、销售、会员与统计报表等核心业务展开可用于课程设计参考、SSM框架入门练手或毕业设计前期原型搭建。压缩包共792个文件约1.78MB以452个html页面、48个java源文件与48个class文件为主体配合41个js、16个css、12个jsp及28个xml配置另有gif、png等图片素材和sql建库脚本前端视图与后端分层代码齐全。已有86人学习下载。系统采用Spring管理依赖与事务、Spring MVC处理请求、MyBatis完成数据库映射Controller与实体类划分清晰读者可据此理解三层架构的落地方式并参考商品录入、出入库、订单统计等模块的实现思路快速搭建可运行环境、对照修改功能或作为二次开发的基础工程。1. 从一份“能跑但不敢交”的课设说起每年到课设周总有人拿着一个能登录、能加商品的 SSM 项目来找我看问得最多的一句是“功能都跑通了为什么导师还是说结构不行”问题往往不在代码能不能跑而在于这套东西没有“方案感”——需求没边界、分层没交代、数据表像随手建的、验收时说不清哪块归谁负责。超市管理系统恰好是这类问题的集中爆发点商品、库存、订单、会员、员工权限五个域一交叉随便写就成一锅粥。这篇就把一套基于 Spring MVC MyBatis 的超市管理系统课设方案完整拆开从需求边界、系统架构、模块实现一路讲到怎么验收答辩。适合正在做 SSM 课设、需要交一份结构完整方案的学生也适合要快速搭一套进销存原型的从业者参考。前端不用花哨后端分层要经得起追问这是整篇的基调。2. 需求与选型先把边界划清再动手2.1 超市管理系统的真实需求边界很多人一上来就列功能清单列了三十条最后做了八条。我一般会先做一件事把需求按“角色 × 动作”切成三档——必须做、可以做、明确不做。超市管理系统的核心角色只有三个收银员、库管、管理员。收银员关心的是“扫码—结算—打印小票”这条链路能不能一次走通库管关心的是入库、出库、库存预警管理员关心的是商品资料、员工账号、销售统计。三档划分大致是这样档位功能范围课设处理方式必须做登录鉴权、商品 CRUD、分类管理、入库出库、库存查询、订单结算、销售流水完整实现答辩必演示可以做会员积分、库存预警阈值、按日销售报表、员工角色区分实现主流程细节留接口明确不做真实支付对接、多门店、条码硬件驱动、财务对账方案里写明“预留扩展点”把“明确不做”写进文档是课设里最容易被忽略却最加分的一步。导师问“为什么不做支付”你答“支付涉及第三方回调与对账超出单机课设边界已在订单模块预留支付状态字段”这就是方案思维。反过来什么都想做的项目最后往往连结算都跑不顺。需求边界定完再落到数据。超市系统的数据关系其实很清晰分类一对多商品商品一对多库存流水订单一对多订单明细员工与角色多对一。这里有个血泪经验——库存不要只存一个数字。只存stock字段出问题时你根本不知道是入库错了还是出库错了等于没有黑匣子。正确做法是库存表存当前量同时用一张流水表记录每一次增减当前量由流水汇总或事务内同步更新。这个设计在答辩时被问到“库存对不上怎么办”你直接翻流水就能答。2.2 为什么是 SSM 而不是别的组合课设选型有个现实约束既要体现分层思想又不能让环境配置吃掉一半时间。SSMSpring Spring MVC MyBatis在这个场景下是稳妥解。Spring 负责 IoC 和事务Spring MVC 负责请求分发与视图解析MyBatis 负责 SQL 映射。三层职责清楚答辩时每一层都能单独讲。对比一下常见替代方案纯 Servlet JDBC 能跑但事务和连接管理全靠手写代码里到处try-catch-finally讲不出架构Spring Boot 更现代但课设往往要求“体现 MVC 分层”Boot 的自动配置反而把分层藏起来了导师容易追问“你的 DispatcherServlet 在哪”。SSM 的 XML 配置虽然啰嗦但恰好把“请求怎么进来、怎么到 Service、怎么落库”这条链路摊开给你看这对课设是优势不是负担。技术栈具体落到版本层面通常的做法是JDK 8、Spring 5.x、MyBatis 3.5.x、MySQL 5.7/8.0、Tomcat 8.5/9、前端用 JSP Bootstrap 或纯 HTML Ajax。前端这块关键词里点了“前端”我的建议是不要上 Vue。课设周期短前后端分离会多出跨域、接口联调、打包部署三座山JSP 或 Thymeleaf 服务端渲染虽然老派但一个 Controller 返回视图名就能看到页面调试成本低得多。如果确实想体现前端能力用 Ajax 局部刷新表格即可既现代又不失控。2.3 分层架构与包结构约定架构上采用经典三层表现层Controller、业务层Service、持久层Mapper/DAO外加实体层Entity和工具层Util。包结构我一般这样定答辩时直接投屏讲com.supermarket ├── controller // 接收请求、参数校验、返回视图或 JSON ├── service // 业务逻辑、事务边界 │ └── impl ├── mapper // MyBatis 接口 ├── entity // 与表对应的实体 ├── dto // 传输对象如订单提交、报表查询 ├── common // 统一返回、常量、异常 └── util // 日期、金额、分页工具关键约定有三条Controller 不写业务判断只做参数接收和结果封装Service 方法上标Transactional事务边界就在这一层Mapper 只写 SQL不掺逻辑。这三条守住代码再简单也显得有章法。下面这段是典型的 Controller 写法注意它有多“薄”Controller RequestMapping(/product) public class ProductController { Autowired private ProductService productService; // 分页查询商品参数由前端传入业务全在 Service GetMapping(/list) public String list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer size, String keyword, Model model) { PageResultProduct result productService.pageQuery(page, size, keyword); model.addAttribute(page, result); model.addAttribute(keyword, keyword); return product/list; // 交给视图解析器拼成 /WEB-INF/jsp/product/list.jsp } // 新增商品成功后重定向避免表单重复提交 PostMapping(/add) public String add(Product product, RedirectAttributes ra) { productService.save(product); ra.addFlashAttribute(msg, 新增成功); return redirect:/product/list; } }这段代码的设计说明比代码本身重要RequestMapping把 URL 前缀统一后续所有商品相关接口都挂在/product下路由一眼可读PageResult是自定义分页对象把总条数、当前页、数据列表打包前端只认一个结构新增用redirect而不是直接返回视图是为了防止用户刷新页面重复提交——这是表单场景的经典坑答辩时能主动提出来是加分项。参数校验这里从简实际项目里会在 Service 入口做非空和唯一性判断课设阶段至少保证商品名不为空、价格非负。3. 核心模块实现五个域怎么落地3.1 数据库设计七张表撑起整个系统表设计是课设的骨架导师翻代码前往往先看 ER 图。这套系统我一般用七张核心表sys_user员工/管理员、category商品分类、product商品、stock_record库存流水、orders订单主表、order_item订单明细、member会员可选。字段设计上几个要点必须讲清楚CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 商品名称, category_id BIGINT NOT NULL COMMENT 所属分类, price DECIMAL(10,2) NOT NULL COMMENT 售价, cost DECIMAL(10,2) DEFAULT 0 COMMENT 进价用于毛利统计, stock INT NOT NULL DEFAULT 0 COMMENT 当前库存, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_category (category_id), INDEX idx_name (name) ) COMMENT 商品表;金额一律用DECIMAL不用FLOAT这是常识但每年都有人翻车浮点误差在结算时会出现 0.01 的差额答辩演示时被看到很尴尬。stock字段存当前量但每次变更必须同时写stock_record两者在同一个事务里要么都成功要么都回滚。索引加在category_id和name上前者支撑分类筛选后者支撑模糊查询——虽然LIKE %xx%用不上索引但前缀匹配和精确查询能用上课设阶段有这个意识就够了。订单表的设计要点是金额快照。order_item里必须存下单时的商品名和单价不能只存product_id然后关联查。原因很直接商品改价后历史订单金额就变了这是数据一致性的硬伤。同理orders表存total_amount和pay_amount结算逻辑在 Service 里算好再落库不在 SQL 里现算。3.2 商品与库存模块事务和并发是重点商品模块的 CRUD 本身不难难在库存扣减。收银结算时订单落库和库存扣减必须原子完成否则会出现“订单成功但库存没减”或者“库存减了订单没生成”。Service 层的写法是这样的Service public class OrderServiceImpl implements OrderService { Autowired private OrderMapper orderMapper; Autowired private ProductMapper productMapper; Autowired private StockRecordMapper stockRecordMapper; // 整个结算在一个事务内写订单、写明细、扣库存、记流水 Override Transactional(rollbackFor Exception.class) public Long checkout(OrderSubmitDTO dto) { BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : dto.getItems()) { Product p productMapper.selectById(item.getProductId()); if (p null || p.getStock() item.getQuantity()) { throw new BizException(商品[ item.getProductId() ]库存不足); } total total.add(p.getPrice().multiply( BigDecimal.valueOf(item.getQuantity()))); } // 1. 写订单主表 Orders order new Orders(); order.setTotalAmount(total); order.setPayAmount(total); order.setStatus(1); orderMapper.insert(order); // 2. 写明细 扣库存 记流水 for (OrderItemDTO item : dto.getItems()) { orderMapper.insertItem(order.getId(), item); int rows productMapper.deductStock(item.getProductId(), item.getQuantity()); if (rows 0) { throw new BizException(库存扣减失败可能已被其他收银台占用); } stockRecordMapper.insert(item.getProductId(), -item.getQuantity(), SALE); } return order.getId(); } }这里有两个设计点值得在答辩时讲。第一deductStock的 SQL 必须带条件UPDATE product SET stock stock - #{qty} WHERE id #{id} AND stock #{qty}返回影响行数为 0 就说明库存不够或被并发抢走直接抛异常回滚。这比“先查再改”安全后者在并发下会超卖。第二Transactional(rollbackFor Exception.class)显式指定回滚异常类型因为默认只回滚RuntimeException受检异常不会触发回滚这是很多人踩过的坑。课设单机演示并发概率低但代码里体现这个意识导师会认为你懂事务。库存流水表stock_record记录product_id、change_qty正入负出、typePURCHASE/SALE/ADJUST、operator、create_time。库管查库存对不上时按商品查流水逐条累加就能定位是哪一笔出的问题。这就是前面说的“黑匣子”。3.3 订单结算与前端交互一次走通的链路结算链路是演示的核心从收银台页面到小票输出要一气呵成。前端用 JSP 渲染商品列表收银员点选商品加入购物车前端用 JavaScript 维护一个临时数组点结算时把购物车 JSON 提交到后端// 收银台结算把购物车数组提交给后端 function checkout() { if (cart.length 0) { alert(购物车为空); return; } fetch(/order/checkout, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ items: cart, memberId: currentMemberId }) }).then(res res.json()) .then(data { if (data.code 200) { // 结算成功跳转小票页携带订单号 window.location.href /order/receipt?id data.data; } else { alert(data.msg); // 库存不足等业务异常在这里提示 } }); }前端这段的关键是统一返回结构。后端所有接口返回{code, msg, data}前端只判断code成功跳转、失败弹提示逻辑统一不散乱。cart数组里每项是{productId, quantity}价格由后端重新查库计算前端传的价格一律不信——这是安全底线虽然课设不涉及攻击但“前端价格不可信”是常识写进方案里显得专业。小票页用服务端渲染Controller 根据订单号查主表和明细塞进 Model 返回 JSP。打印功能用浏览器window.print()即可不必对接硬件。整个链路演示顺序建议是登录 → 商品列表 → 加入购物车 → 结算 → 小票 → 回库存页看数量减少 → 查流水看到 SALE 记录。这条线走完订单和库存两个模块就都证明了。3.4 权限与登录拦截器比框架更轻课设不需要上 Spring Security一个 HandlerInterceptor 足够。登录成功后把用户信息放 Session拦截器统一校验public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws Exception { HttpSession session req.getSession(); if (session.getAttribute(loginUser) null) { resp.sendRedirect(req.getContextPath() /login); return false; } return true; } }在spring-mvc.xml里注册拦截器mvc:exclude-mapping排除/login、/static/**等路径。角色区分更简单Session 里存role字段库管访问商品管理、收银员访问收银台在拦截器里按 URL 前缀判断即可。这套做法轻量、可讲清楚比引入安全框架更适合课设体量。密码存储至少做 MD5 加盐明文存密码在答辩时是硬伤改起来也就几行代码。4. 避坑与排查课设里最容易翻车的五件事4.1 中文乱码从请求到响应全链路排查现象是页面提交的中文变成问号或乱码。原因通常有三处Tomcat 的 URI 编码、请求体编码、响应编码。解决顺序是先在web.xml加CharacterEncodingFilter设UTF-8并forceEncodingtrue再确认数据库连接串带useUnicodetruecharacterEncodingutf8最后检查 JSP 页头% page contentTypetext/html;charsetUTF-8 %。三处都对齐乱码基本绝迹。GET 请求的中文参数在旧版 Tomcat 还需改server.xml的URIEncoding新版默认 UTF-8 可跳过。4.2 事务不生效注解加错地方现象是结算抛异常后订单没回滚。原因多半是Transactional加在了 Controller 上或者 Service 内部方法自调用同类方法直接调绕过了代理。解决是把注解放到 Service 实现类的 public 方法上自调用场景改为注入自身代理或拆到另一个 Service。另外确认spring-tx依赖和事务管理器配置齐全XML 里tx:annotation-driven不能漏。4.3 MyBatis 映射对不上字段名与驼峰现象是查询结果里某些字段为 null。原因是数据库下划线命名create_time与实体驼峰createTime不匹配。解决是在mybatis-config.xml开mapUnderscoreToCamelCasetrue或者 SQL 里写别名。前者一劳永逸建议默认开启。另一个高频问题是 Mapper 接口没被扫描到检查MapperScan或 XML 里的MapperScannerConfigurer包路径是否覆盖。4.4 静态资源 404DispatcherServlet 拦截了现象是 CSS、JS 加载不出来页面裸奔。原因是DispatcherServlet映射/后把静态资源请求也接走了。解决是在spring-mvc.xml加mvc:resources mapping/static/** location/static//和mvc:default-servlet-handler/。路径要和前端引用一致${pageContext.request.contextPath}/static/...这种写法最稳避免部署到非根路径时失效。4.5 库存对不上漏写流水或事务不同步现象是商品表库存和流水汇总不一致。原因通常是某次库存变更只改了product.stock没写stock_record或者两者不在同一事务。解决是把库存变更收敛到一个 Service 方法里方法内同时更新主表和插流水统一加事务再写一个对账 SQL 定期比对product.stock与流水汇总差异不为零就报警。课设阶段至少保证所有变更走同一个入口别在 Controller 里直接调 Mapper 改库存。5. 验收与答辩把方案讲成一条线验收不是把功能点一遍而是让评审顺着你的逻辑走。我一般建议按“一条主线 两个亮点 一个取舍”来组织演示。主线就是收银结算登录收银员账号 → 商品列表选货 → 结算 → 小票 → 库存减少 → 流水可查。这条线五分钟走完覆盖了鉴权、查询、事务、库存、前端交互五个考点。两个亮点选“事务保证订单与库存一致”和“库存流水可追溯”各讲一分钟配代码片段或表数据。一个取舍讲“为什么不做真实支付/多门店”体现边界意识。答辩提问高频集中在三处提前准备答案常见提问回答要点事务是怎么保证的指向 Service 的Transactional说明扣库存 SQL 带stock qty条件防超卖库存对不上怎么查打开stock_record按商品累加与product.stock比对定位差异笔分层各层职责Controller 只收参返视图Service 管业务和事务Mapper 只管 SQL演示前有个习惯我每次都强制走一遍清空数据库重跑一次全流程。因为开发过程中手工改过数据、插过测试记录演示时库存数、订单号可能对不上现场翻车多半栽在这。清库重跑能暴露初始化脚本缺字段、外键顺序错等问题比临场救火强得多。另外把 Tomcat 日志级别调到 INFO 以上演示时如果报错控制台能直接看到堆栈不至于干瞪眼。从那以后我每次交方案前都会拿一份干净环境从登录走到小票再对着数据表核一遍流水确认这条链路不依赖任何手工数据。课设拼的不是功能多是这条线经得起追问。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/5 7:28:30 · 阅读 1.2k SSM超市管理系统课设方案：从需求边界到答辩验收的完整拆解
简介这份资源是面向高校计算机相关专业学生与Java初学者的一套SSM超市管理系统课程设计完整源码围绕商品、库存、销售、会员与统计报表等核心业务展开可用于课程设计参考、SSM框架入门练手或毕业设计前期原型搭建。压缩包共792个文件约1.78MB以452个html页面、48个java源文件与48个class文件为主体配合41个js、16个css、12个jsp及28个xml配置另有gif、png等图片素材和sql建库脚本前端视图与后端分层代码齐全。已有86人学习下载。系统采用Spring管理依赖与事务、Spring MVC处理请求、MyBatis完成数据库映射Controller与实体类划分清晰读者可据此理解三层架构的落地方式并参考商品录入、出入库、订单统计等模块的实现思路快速搭建可运行环境、对照修改功能或作为二次开发的基础工程。1. 从一份“能跑但不敢交”的课设说起每年到课设周总有人拿着一个能登录、能加商品的 SSM 项目来找我看问得最多的一句是“功能都跑通了为什么导师还是说结构不行”问题往往不在代码能不能跑而在于这套东西没有“方案感”——需求没边界、分层没交代、数据表像随手建的、验收时说不清哪块归谁负责。超市管理系统恰好是这类问题的集中爆发点商品、库存、订单、会员、员工权限五个域一交叉随便写就成一锅粥。这篇就把一套基于 Spring MVC MyBatis 的超市管理系统课设方案完整拆开从需求边界、系统架构、模块实现一路讲到怎么验收答辩。适合正在做 SSM 课设、需要交一份结构完整方案的学生也适合要快速搭一套进销存原型的从业者参考。前端不用花哨后端分层要经得起追问这是整篇的基调。2. 需求与选型先把边界划清再动手2.1 超市管理系统的真实需求边界很多人一上来就列功能清单列了三十条最后做了八条。我一般会先做一件事把需求按“角色 × 动作”切成三档——必须做、可以做、明确不做。超市管理系统的核心角色只有三个收银员、库管、管理员。收银员关心的是“扫码—结算—打印小票”这条链路能不能一次走通库管关心的是入库、出库、库存预警管理员关心的是商品资料、员工账号、销售统计。三档划分大致是这样档位功能范围课设处理方式必须做登录鉴权、商品 CRUD、分类管理、入库出库、库存查询、订单结算、销售流水完整实现答辩必演示可以做会员积分、库存预警阈值、按日销售报表、员工角色区分实现主流程细节留接口明确不做真实支付对接、多门店、条码硬件驱动、财务对账方案里写明“预留扩展点”把“明确不做”写进文档是课设里最容易被忽略却最加分的一步。导师问“为什么不做支付”你答“支付涉及第三方回调与对账超出单机课设边界已在订单模块预留支付状态字段”这就是方案思维。反过来什么都想做的项目最后往往连结算都跑不顺。需求边界定完再落到数据。超市系统的数据关系其实很清晰分类一对多商品商品一对多库存流水订单一对多订单明细员工与角色多对一。这里有个血泪经验——库存不要只存一个数字。只存stock字段出问题时你根本不知道是入库错了还是出库错了等于没有黑匣子。正确做法是库存表存当前量同时用一张流水表记录每一次增减当前量由流水汇总或事务内同步更新。这个设计在答辩时被问到“库存对不上怎么办”你直接翻流水就能答。2.2 为什么是 SSM 而不是别的组合课设选型有个现实约束既要体现分层思想又不能让环境配置吃掉一半时间。SSMSpring Spring MVC MyBatis在这个场景下是稳妥解。Spring 负责 IoC 和事务Spring MVC 负责请求分发与视图解析MyBatis 负责 SQL 映射。三层职责清楚答辩时每一层都能单独讲。对比一下常见替代方案纯 Servlet JDBC 能跑但事务和连接管理全靠手写代码里到处try-catch-finally讲不出架构Spring Boot 更现代但课设往往要求“体现 MVC 分层”Boot 的自动配置反而把分层藏起来了导师容易追问“你的 DispatcherServlet 在哪”。SSM 的 XML 配置虽然啰嗦但恰好把“请求怎么进来、怎么到 Service、怎么落库”这条链路摊开给你看这对课设是优势不是负担。技术栈具体落到版本层面通常的做法是JDK 8、Spring 5.x、MyBatis 3.5.x、MySQL 5.7/8.0、Tomcat 8.5/9、前端用 JSP Bootstrap 或纯 HTML Ajax。前端这块关键词里点了“前端”我的建议是不要上 Vue。课设周期短前后端分离会多出跨域、接口联调、打包部署三座山JSP 或 Thymeleaf 服务端渲染虽然老派但一个 Controller 返回视图名就能看到页面调试成本低得多。如果确实想体现前端能力用 Ajax 局部刷新表格即可既现代又不失控。2.3 分层架构与包结构约定架构上采用经典三层表现层Controller、业务层Service、持久层Mapper/DAO外加实体层Entity和工具层Util。包结构我一般这样定答辩时直接投屏讲com.supermarket ├── controller // 接收请求、参数校验、返回视图或 JSON ├── service // 业务逻辑、事务边界 │ └── impl ├── mapper // MyBatis 接口 ├── entity // 与表对应的实体 ├── dto // 传输对象如订单提交、报表查询 ├── common // 统一返回、常量、异常 └── util // 日期、金额、分页工具关键约定有三条Controller 不写业务判断只做参数接收和结果封装Service 方法上标Transactional事务边界就在这一层Mapper 只写 SQL不掺逻辑。这三条守住代码再简单也显得有章法。下面这段是典型的 Controller 写法注意它有多“薄”Controller RequestMapping(/product) public class ProductController { Autowired private ProductService productService; // 分页查询商品参数由前端传入业务全在 Service GetMapping(/list) public String list(RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 10) Integer size, String keyword, Model model) { PageResultProduct result productService.pageQuery(page, size, keyword); model.addAttribute(page, result); model.addAttribute(keyword, keyword); return product/list; // 交给视图解析器拼成 /WEB-INF/jsp/product/list.jsp } // 新增商品成功后重定向避免表单重复提交 PostMapping(/add) public String add(Product product, RedirectAttributes ra) { productService.save(product); ra.addFlashAttribute(msg, 新增成功); return redirect:/product/list; } }这段代码的设计说明比代码本身重要RequestMapping把 URL 前缀统一后续所有商品相关接口都挂在/product下路由一眼可读PageResult是自定义分页对象把总条数、当前页、数据列表打包前端只认一个结构新增用redirect而不是直接返回视图是为了防止用户刷新页面重复提交——这是表单场景的经典坑答辩时能主动提出来是加分项。参数校验这里从简实际项目里会在 Service 入口做非空和唯一性判断课设阶段至少保证商品名不为空、价格非负。3. 核心模块实现五个域怎么落地3.1 数据库设计七张表撑起整个系统表设计是课设的骨架导师翻代码前往往先看 ER 图。这套系统我一般用七张核心表sys_user员工/管理员、category商品分类、product商品、stock_record库存流水、orders订单主表、order_item订单明细、member会员可选。字段设计上几个要点必须讲清楚CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 商品名称, category_id BIGINT NOT NULL COMMENT 所属分类, price DECIMAL(10,2) NOT NULL COMMENT 售价, cost DECIMAL(10,2) DEFAULT 0 COMMENT 进价用于毛利统计, stock INT NOT NULL DEFAULT 0 COMMENT 当前库存, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_category (category_id), INDEX idx_name (name) ) COMMENT 商品表;金额一律用DECIMAL不用FLOAT这是常识但每年都有人翻车浮点误差在结算时会出现 0.01 的差额答辩演示时被看到很尴尬。stock字段存当前量但每次变更必须同时写stock_record两者在同一个事务里要么都成功要么都回滚。索引加在category_id和name上前者支撑分类筛选后者支撑模糊查询——虽然LIKE %xx%用不上索引但前缀匹配和精确查询能用上课设阶段有这个意识就够了。订单表的设计要点是金额快照。order_item里必须存下单时的商品名和单价不能只存product_id然后关联查。原因很直接商品改价后历史订单金额就变了这是数据一致性的硬伤。同理orders表存total_amount和pay_amount结算逻辑在 Service 里算好再落库不在 SQL 里现算。3.2 商品与库存模块事务和并发是重点商品模块的 CRUD 本身不难难在库存扣减。收银结算时订单落库和库存扣减必须原子完成否则会出现“订单成功但库存没减”或者“库存减了订单没生成”。Service 层的写法是这样的Service public class OrderServiceImpl implements OrderService { Autowired private OrderMapper orderMapper; Autowired private ProductMapper productMapper; Autowired private StockRecordMapper stockRecordMapper; // 整个结算在一个事务内写订单、写明细、扣库存、记流水 Override Transactional(rollbackFor Exception.class) public Long checkout(OrderSubmitDTO dto) { BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : dto.getItems()) { Product p productMapper.selectById(item.getProductId()); if (p null || p.getStock() item.getQuantity()) { throw new BizException(商品[ item.getProductId() ]库存不足); } total total.add(p.getPrice().multiply( BigDecimal.valueOf(item.getQuantity()))); } // 1. 写订单主表 Orders order new Orders(); order.setTotalAmount(total); order.setPayAmount(total); order.setStatus(1); orderMapper.insert(order); // 2. 写明细 扣库存 记流水 for (OrderItemDTO item : dto.getItems()) { orderMapper.insertItem(order.getId(), item); int rows productMapper.deductStock(item.getProductId(), item.getQuantity()); if (rows 0) { throw new BizException(库存扣减失败可能已被其他收银台占用); } stockRecordMapper.insert(item.getProductId(), -item.getQuantity(), SALE); } return order.getId(); } }这里有两个设计点值得在答辩时讲。第一deductStock的 SQL 必须带条件UPDATE product SET stock stock - #{qty} WHERE id #{id} AND stock #{qty}返回影响行数为 0 就说明库存不够或被并发抢走直接抛异常回滚。这比“先查再改”安全后者在并发下会超卖。第二Transactional(rollbackFor Exception.class)显式指定回滚异常类型因为默认只回滚RuntimeException受检异常不会触发回滚这是很多人踩过的坑。课设单机演示并发概率低但代码里体现这个意识导师会认为你懂事务。库存流水表stock_record记录product_id、change_qty正入负出、typePURCHASE/SALE/ADJUST、operator、create_time。库管查库存对不上时按商品查流水逐条累加就能定位是哪一笔出的问题。这就是前面说的“黑匣子”。3.3 订单结算与前端交互一次走通的链路结算链路是演示的核心从收银台页面到小票输出要一气呵成。前端用 JSP 渲染商品列表收银员点选商品加入购物车前端用 JavaScript 维护一个临时数组点结算时把购物车 JSON 提交到后端// 收银台结算把购物车数组提交给后端 function checkout() { if (cart.length 0) { alert(购物车为空); return; } fetch(/order/checkout, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ items: cart, memberId: currentMemberId }) }).then(res res.json()) .then(data { if (data.code 200) { // 结算成功跳转小票页携带订单号 window.location.href /order/receipt?id data.data; } else { alert(data.msg); // 库存不足等业务异常在这里提示 } }); }前端这段的关键是统一返回结构。后端所有接口返回{code, msg, data}前端只判断code成功跳转、失败弹提示逻辑统一不散乱。cart数组里每项是{productId, quantity}价格由后端重新查库计算前端传的价格一律不信——这是安全底线虽然课设不涉及攻击但“前端价格不可信”是常识写进方案里显得专业。小票页用服务端渲染Controller 根据订单号查主表和明细塞进 Model 返回 JSP。打印功能用浏览器window.print()即可不必对接硬件。整个链路演示顺序建议是登录 → 商品列表 → 加入购物车 → 结算 → 小票 → 回库存页看数量减少 → 查流水看到 SALE 记录。这条线走完订单和库存两个模块就都证明了。3.4 权限与登录拦截器比框架更轻课设不需要上 Spring Security一个 HandlerInterceptor 足够。登录成功后把用户信息放 Session拦截器统一校验public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws Exception { HttpSession session req.getSession(); if (session.getAttribute(loginUser) null) { resp.sendRedirect(req.getContextPath() /login); return false; } return true; } }在spring-mvc.xml里注册拦截器mvc:exclude-mapping排除/login、/static/**等路径。角色区分更简单Session 里存role字段库管访问商品管理、收银员访问收银台在拦截器里按 URL 前缀判断即可。这套做法轻量、可讲清楚比引入安全框架更适合课设体量。密码存储至少做 MD5 加盐明文存密码在答辩时是硬伤改起来也就几行代码。4. 避坑与排查课设里最容易翻车的五件事4.1 中文乱码从请求到响应全链路排查现象是页面提交的中文变成问号或乱码。原因通常有三处Tomcat 的 URI 编码、请求体编码、响应编码。解决顺序是先在web.xml加CharacterEncodingFilter设UTF-8并forceEncodingtrue再确认数据库连接串带useUnicodetruecharacterEncodingutf8最后检查 JSP 页头% page contentTypetext/html;charsetUTF-8 %。三处都对齐乱码基本绝迹。GET 请求的中文参数在旧版 Tomcat 还需改server.xml的URIEncoding新版默认 UTF-8 可跳过。4.2 事务不生效注解加错地方现象是结算抛异常后订单没回滚。原因多半是Transactional加在了 Controller 上或者 Service 内部方法自调用同类方法直接调绕过了代理。解决是把注解放到 Service 实现类的 public 方法上自调用场景改为注入自身代理或拆到另一个 Service。另外确认spring-tx依赖和事务管理器配置齐全XML 里tx:annotation-driven不能漏。4.3 MyBatis 映射对不上字段名与驼峰现象是查询结果里某些字段为 null。原因是数据库下划线命名create_time与实体驼峰createTime不匹配。解决是在mybatis-config.xml开mapUnderscoreToCamelCasetrue或者 SQL 里写别名。前者一劳永逸建议默认开启。另一个高频问题是 Mapper 接口没被扫描到检查MapperScan或 XML 里的MapperScannerConfigurer包路径是否覆盖。4.4 静态资源 404DispatcherServlet 拦截了现象是 CSS、JS 加载不出来页面裸奔。原因是DispatcherServlet映射/后把静态资源请求也接走了。解决是在spring-mvc.xml加mvc:resources mapping/static/** location/static//和mvc:default-servlet-handler/。路径要和前端引用一致${pageContext.request.contextPath}/static/...这种写法最稳避免部署到非根路径时失效。4.5 库存对不上漏写流水或事务不同步现象是商品表库存和流水汇总不一致。原因通常是某次库存变更只改了product.stock没写stock_record或者两者不在同一事务。解决是把库存变更收敛到一个 Service 方法里方法内同时更新主表和插流水统一加事务再写一个对账 SQL 定期比对product.stock与流水汇总差异不为零就报警。课设阶段至少保证所有变更走同一个入口别在 Controller 里直接调 Mapper 改库存。5. 验收与答辩把方案讲成一条线验收不是把功能点一遍而是让评审顺着你的逻辑走。我一般建议按“一条主线 两个亮点 一个取舍”来组织演示。主线就是收银结算登录收银员账号 → 商品列表选货 → 结算 → 小票 → 库存减少 → 流水可查。这条线五分钟走完覆盖了鉴权、查询、事务、库存、前端交互五个考点。两个亮点选“事务保证订单与库存一致”和“库存流水可追溯”各讲一分钟配代码片段或表数据。一个取舍讲“为什么不做真实支付/多门店”体现边界意识。答辩提问高频集中在三处提前准备答案常见提问回答要点事务是怎么保证的指向 Service 的Transactional说明扣库存 SQL 带stock qty条件防超卖库存对不上怎么查打开stock_record按商品累加与product.stock比对定位差异笔分层各层职责Controller 只收参返视图Service 管业务和事务Mapper 只管 SQL演示前有个习惯我每次都强制走一遍清空数据库重跑一次全流程。因为开发过程中手工改过数据、插过测试记录演示时库存数、订单号可能对不上现场翻车多半栽在这。清库重跑能暴露初始化脚本缺字段、外键顺序错等问题比临场救火强得多。另外把 Tomcat 日志级别调到 INFO 以上演示时如果报错控制台能直接看到堆栈不至于干瞪眼。从那以后我每次交方案前都会拿一份干净环境从登录走到小票再对着数据表核一遍流水确认这条链路不依赖任何手工数据。课设拼的不是功能多是这条线经得起追问。希望帮到你。本文还有配套的精品资源点击获取