Spring Boot零食售货机管理系统：数据库设计与权限控制实践-代码聚汇网

Spring Boot零食售货机管理系统：数据库设计与权限控制实践

Spring Boot零食售货机管理系统

|难度：普通|阅读约 36 分钟

最近正好帮一个学弟把这个springboot零食售货机管理系统的课设项目从零到一梳理完整，从需求分析到数据库设计，再到功能实现和文档撰写，整个过程踩了不少坑，也积累了一些值得分享的经验。如果你正在做类似的课程设计或者毕业设计，或者想快速搞懂一个springboot项目的完整脉络，这篇内容应该能帮你省下不少时间。

先交代一下背景：这个项目是典型的"基于springboot的零食售货机管理系统"，核心围绕商品管理和购买管理两条主线展开，配套源码、数据库脚本以及一篇完整的课程设计文档。项目技术栈是Spring Boot + MyBatis Plus + MySQL，前端用Vue + Element UI（也可以直接用Thymeleaf，后面会讲两种方案的取舍）。整体规模不大，但是麻雀虽小五脏俱全，非常适合作为课设、毕设的参考项目，也适合想入门springboot但不想只做增删改查的初学者。

1. 项目概述与核心功能拆分

1.1 这个系统到底是做什么的

零食售货机管理系统，本质上是把线下零售货机的"商品上架—用户选购—订单生成—库存扣减—销售统计"这条链路搬到线上，让运营人员能够远程管理货机内的商品，同时让用户能够通过网页完成购买流程。听起来简单，但真正落地时会发现，这里面涉及角色权限、商品上下架、订单状态流转、库存一致性、补货记录、销售报表等一系列问题。

这个项目的功能范围从标题就能看出，重点是商品管理和购买管理。我做的时候进一步拆成了三个角色维度：

管理员角色：负责用户管理、角色权限配置、全局数据统计、异常订单处理；
运营人员角色：负责商品信息的维护（新增、编辑、上下架）、库存的调整、补货记录的登记；
普通用户角色：浏览货机商品、加入购物车、提交订单、模拟支付、查看自己的历史订单。

这个角色划分和很多网上的教程项目不太一样，网上很多项目虽然页面很多，但角色权限基本都是摆设。我这个项目里从后端接口到前端页面，都做了基于Spring Security + JWT的权限控制，管理员和运营人员的可见菜单、可操作接口是真正有区分的。这部分在答辩的时候是非常加分的点，因为很多老师都会问"你的权限是怎么控制的"。

1.2 核心业务流程如何跑通

整个系统的核心业务链路，其实可以浓缩成一个场景：用户打开系统首页，看到货机上架的各品牌零食，带图片、价格、库存数量，选择几样加进购物车，下单后系统检查库存是否充足，计算总价，用户模拟支付成功后，系统扣减库存、生成订单，运营人员随时可以在后台看到订单情况并进行发货或补货操作。

在这个过程中，最关键的三个环节是：商品上下架的即时生效机制、并发下单时的库存防超卖处理、以及订单状态在不同操作下的流转逻辑。这三个问题在课程设计的简单场景下可以做得比较粗糙，但如果想在答辩时让老师眼前一亮，就应该在这里下功夫。后面我会专门拿出一节来讲并发扣减库存这块的几种实现方案。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 技术选型与设计决策的取舍逻辑

2.1 为什么主框架选择了Spring Boot而非SSH或SSM

现在做课设或者毕设，很多人会纠结用SSM还是Spring Boot。我的建议非常明确：除非老师特别指定必须用SSM，否则一律用Spring Boot。原因不仅仅是Spring Boot更火、资料更多，更重要的是，Spring Boot的自动配置机制和Starter生态，能够让你把精力集中在业务逻辑上，而不是去配置一堆XML文件。

这个项目里我使用的是Spring Boot 2.7.x版本，没有选择Spring Boot 3.x。原因有两点：第一，2.7.x是2.x系列的最后一个稳定版本，资料丰富，遇到任何问题基本都能搜到解决方案；第二，3.x基于Jakarta命名空间，很多老版本的第三方依赖需要额外适配，对课设来说完全没有必要冒这个风险。我用的是JDK 8，配合Spring Boot 2.7.x，这是目前最稳的组合，没有之一。

2.2 ORM框架选了MyBatis Plus而非原生MyBatis

ORM框架的选择上，我倾向于MyBatis Plus。原生MyBatis写分页查询、批量插入、条件构造器这些代码会比较繁琐，而MyBatis Plus内置了通用Mapper、分页插件、Lambda条件构造器，能让代码量减少50%以上。而且它和Spring Boot的整合非常顺滑，引入mybatis-plus-boot-starter依赖后，基本零配置就能跑起来。

在代码组织上，我采用了标准的Controller - Service - Mapper三层结构，实体类放在entity包，DTO放在dto包，VO放在vo包。这不仅仅是规范的问题，更重要的是为后续维护和文档撰写打基础。课程设计文档里必然要画系统架构图和功能结构图，如果你的代码分层清晰，画图的时候会非常省事。

2.3 前端方案的选择：Vue分离还是服务端渲染

这个项目我实现了两套前端方案，源头是需求的不同。如果你只是要一个"能跑、能演示、能答辩"的系统，那直接用Thymeleaf做服务端渲染就够了，后端返回页面，简单直接，部署方便。但如果你想在课设答辩时额外加分，展示前后端分离的能力，那我建议使用Vue + Element UI，通过Axios调用后端RESTful API。

考虑不同实现成本，我把最终版本的源码采用Vue分离方案，因为Spring Boot天生适合做前后端分离的后端服务，这也是目前企业开发的主流模式。但需要提醒一句：前后端分离意味着你需要额外处理跨域问题（CORS）、需要处理Token的传递和拦截，项目复杂度会上升一个台阶。这个复杂度对课设来说是可控的，但要做好心理准备。

3. 数据库设计：零食售货机业务的地基

3.1 核心数据表结构与字段设计逻辑

数据库设计可以说是这个项目的灵魂。很多课设项目功能做得天花乱坠，但数据库只有三张表，所有字段都是字符串类型，这种设计答辩时老师随便问几个问题就露馅了。我做这个项目时一共设计了6张核心表，外加2张关联表。

user（用户表）：id、username、password（BCrypt加密）、nickname、role（admin/operator/user）、status、create_time。这里role字段直接存字符串，简单易懂，没有引入独立的权限表。课设级别这个设计够用，如果老师追问权限扩展，你可以说后续可以拆成user_role、role_permission表。
category（商品分类表）：id、name、sort、status。零食种类其实不少，薯片、饮料、巧克力、饼干、糖果，分类表让商品列表页可以按分类筛选。
product（商品表）：id、name、category_id、price、stock、image、status（上架/下架）、sales（销量）、create_time、update_time。这里最关键的字段是price，我在设计时使用DECIMAL(10,2)而非DOUBLE或FLOAT。原因是浮点数在存储和计算时会有精度误差，比如0.1+0.2可能等于0.30000000000000004，这在金额计算上是不能接受的。这也是数据库设计中最基本的规范，但很多课设项目都会在这个细节上翻车。
orders（订单表）：id、order_no（订单编号）、user_id、total_amount、status（待支付/已支付/已取消/已完成）、pay_time、create_time。订单编号我用yyyyMMddHHmmss + 四位随机数生成，不直接使用数据库自增id作为订单号，因为订单号在业务上需要具备唯一性和一定的可读性。
order_item（订单详情表）：id、order_id、product_id、product_name、product_image、price（成交单价）、quantity（数量）、subtotal（小计金额）。这里我把product_name和product_image冗余存储，而不是通过product_id实时关联查询商品表。原因是订单属于历史快照数据，商品信息后续可能修改甚至删除，但历史订单里应该保留下单那一刻的商品信息，否则订单记录会随着商品修改而面目全非。
restock_record（补货记录表）：id、product_id、quantity、operator_id、restock_time、remark。补货记录是零食售货机这个场景的特色表，售货机里的零食会售罄，运营需要补货，记录补货次数和数量是运营管理的基本需求。
cart（购物车表）：id、user_id、product_id、quantity、checked、create_time、update_time。购物车我用了单表存储，每个用户对应多条购物车记录，没有做Cookie或Redis方案。课设场景下，这个方案最直观，也最方便在答辩时讲解。
address（收货地址表）：id、user_id、consignee、phone、province、city、district、detail、is_default。用户下单时需要选择收货地址，这个表属于下单流程的支撑表。

3.2 逻辑删除与唯一索引的设计细节

在一张表的数据设计中，我给所有核心表都加了deleted字段，采用MyBatis Plus的逻辑删除功能。逻辑删除的核心价值在于：用户误删商品时，可以快速恢复；同时API层面上所有列表查询自动过滤掉已删除数据。这一点在答辩时也是一个可以拿出来讲的设计亮点——物理删除和逻辑删除的取舍。

商品表上还设置了一个uk_category_name的唯一索引，保证同一个分类下不能有重复的商品名。课设项目里可能不太会有人真的去测试这个约束，但从数据库设计的规范角度来说，这种防重设计是必须的。你可以在文档的数据表设计章节里，把每个字段的注释都写清楚，说明每个索引存在的理由，这会让文档质量立刻提升一个档次。

3.3 数据库初始化脚本的编写经验

数据库脚本我放在项目的sql目录下，包含full_database.sql，一次性创建数据库、所有表结构以及一份初始化的测试数据。这里有一个很实用的经验：初始数据一定要有，尤其是商品表和用户表，否则系统跑起来空空如也，演示效果非常差。

我在初始化脚本里预置了三个角色的用户账号：

管理员：admin / admin123
运营人员：operator / operator123
普通用户：user / user123

另外预置了8个分类、20个商品数据，覆盖薯片、饮料、巧克力、饼干等常见零食，每件商品都配了图片URL（用线上占位图或本地上传的静态图片均可）。这样部署完系统，登录后看到的是一个有内容、有温度的系统，而不是一张张空表。

4. 核心功能模块的实现与关键逻辑解析

4.1 商品管理模块：从列表到上下架

商品管理模块是整个系统的基础模块，也是五个管理功能里最复杂的。它包含：分页查询商品列表（带分类筛选、关键字搜索、上下架状态筛选）、新增商品、编辑商品、逻辑删除商品、上下架商品、商品图片上传。

分页查询我使用的是MyBatis Plus的分页插件，配合LambdaQueryWrapper构造查询条件。核心代码逻辑大概是这样：

java复制public PageResult<ProductVO> pageProducts(ProductPageQuery query) {
    Page<Product> page = new Page<>(query.getPageNum(), query.getPageSize());
    LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>();
    wrapper.like(StringUtils.hasText(query.getKeyword()), Product::getName, query.getKeyword())
            .eq(query.getCategoryId() != null, Product::getCategoryId, query.getCategoryId())
            .eq(query.getStatus() != null, Product::getStatus, query.getStatus())
            .orderByDesc(Product::getCreateTime);
    Page<Product> result = productMapper.selectPage(page, wrapper);
    return convertToPageResult(result);
}

这里用的是Lambda方法引用而不是字符串字段名，好处是编译期类型安全，字段改名了不用怕查询条件静默失效。这个习惯在真实项目中非常重要，建议从课设开始就养成。

图片上传功能使用的是Spring Boot原生的文件上传能力，在application.yml里配置了本地上传路径，上传后返回可访问的静态资源URL。上传的文件我做了大小限制（单个文件不能超过2MB），并做了类型白名单过滤，只允许jpg、png、gif、webp这几种格式。扩展名伪装这类安全细节，课设阶段可能不会遇到，但值得提前知道。

上下架状态我用status字段（0下架，1上架）来表示，上下架操作本质就是修改这个字段。这里有个细节值得注意：下架商品时，需要同时处理掉购物车中该商品的已选中状态，否则用户购物车里会有一个下架商品，下单时就会产生数据不一致。我在下架接口里加了同步逻辑，批量更新购物车表中对应商品的checked字段为false。

4.2 购买管理模块：购物车与下单流程

购买流程是这个系统中业务流程最完整、也最能体现"事务一致性"的模块。用户的完整操作路径是：浏览商品 → 加入购物车 → 查看购物车 → 选中商品 → 提交订单 → 模拟支付 → 支付完成查看订单。

购物车部分有以下几个接口：

加入购物车（传入商品id和数量，校验商品状态与库存）
修改购物车商品数量（同步校验库存）
选中/取消选中商品
删除购物车记录
清空购物车
获取当前用户的购物车列表

加入购物车时，我同时处理了"购物车中已存在该商品"的情况，此时不做新增而是累加数量。这一块如果不用合并逻辑，用户重复点击加入购物车就会产生两条相同商品记录，体验很差。

下单接口是这个系统中最核心的部分。我来贴一下关键逻辑，并解释每一步为什么要这样写：

java复制@Transactional(rollbackFor = Exception.class)
public OrderVO createOrder(OrderCreateDTO dto) {
    // 1. 查询购物车中选中的商品列表
    List<CartItem> checkedItems = cartMapper.selectCheckedItems(dto.getUserId());
    if (CollectionUtils.isEmpty(checkedItems)) {
        throw new BizException("请先选择要结算的商品");
    }

    // 2. 遍历校验商品状态和库存，同时计算总金额
    BigDecimal totalAmount = BigDecimal.ZERO;
    List<OrderItem> orderItems = new ArrayList<>();
    for (CartItem cartItem : checkedItems) {
        Product product = productMapper.selectById(cartItem.getProductId());
        if (product == null || product.getStatus() != 1) {
            throw new BizException("商品【" + cartItem.getProductName() + "】已下架");
        }
        if (product.getStock() < cartItem.getQuantity()) {
            throw new BizException("商品【" + cartItem.getProductName() + "】库存不足");
        }
        totalAmount = totalAmount.add(product.getPrice()
                .multiply(BigDecimal.valueOf(cartItem.getQuantity())));
        // 构建订单明细快照
        OrderItem orderItem = new OrderItem();
        orderItem.setProductId(product.getId());
        orderItem.setProductName(product.getName());
        orderItem.setProductImage(product.getImage());
        orderItem.setPrice(product.getPrice());
        orderItem.setQuantity(cartItem.getQuantity());
        orderItem.setSubtotal(product.getPrice()
                .multiply(BigDecimal.valueOf(cartItem.getQuantity())));
        orderItems.add(orderItem);
    }

    // 3. 生成订单头和订单明细
    Orders order = new Orders();
    order.setOrderNo(generateOrderNo());
    order.setUserId(dto.getUserId());
    order.setTotalAmount(totalAmount);
    order.setStatus(OrderStatus.PENDING_PAYMENT.getCode());
    orderMapper.insert(order);
    for (OrderItem orderItem : orderItems) {
        orderItem.setOrderId(order.getId());
        orderItemMapper.insert(orderItem);
    }

    // 4. 清空购物车中已结算的商品
    cartMapper.deleteCheckedItems(dto.getUserId());

    return orderVO;
}

第2步的校验看起来是理所当然的，但如果不写，就会产生"超卖"问题。比如库存只剩3件，用户A和用户B同时下单，都通过了库存校验，都执行了后续的扣库存操作，最终库存变成-1，订单却都成功了。怎么解决？第2步的普通校验并不能防止这个问题，因为两个人的校验可能同时发生。真正的防超卖要靠扣库存时的原子性操作。

我这里在下单事务里把扣库存操作设计为带条件的更新SQL：

java复制@Update("UPDATE product SET stock = stock - #{quantity}, sales = sales + #{quantity} " +
        "WHERE id = #{productId} AND stock >= #{quantity}")
int deductStock(@Param("productId") Long productId, @Param("quantity") Integer quantity);

这条SQL通过stock >= #{quantity}条件，保证了扣减操作本身是原子的——如果库存不足，updates影响行数为0，通过判断影响行数来抛异常回滚整个事务。这就是"乐观锁思想在库存扣减中的落地"，是课程设计里可以重点讲的技术亮点。

4.3 订单状态机与模拟支付

订单状态我定义了一个枚举：待支付（0）→ 已支付（1）→ 已完成（2），同时有已取消（-1）状态。状态流转的触发点包括：

创建订单 → 状态为待支付；
用户点击"模拟支付" → 状态变为已支付，同时记录支付时间；
用户点击"取消订单"（限待支付状态） → 状态变为已取消，同时回滚库存；
运营人员在后台点击"完成订单" → 状态变为已完成。

这里有一个系统设计上的小陷阱：如果用户下单后不支付，又去重新下单，库存会一直被占用。针对课设场景我做了简化处理——只在取消订单时回滚库存，没有再引入定时任务去处理超时未支付订单。但我在文档里专门写了一段"待完善的扩展点"，提到可以用Spring的@Scheduled定时扫描超过15分钟未支付的订单并自动取消。这个思路在答辩时说出来的效果很好，说明你考虑到了现实场景中会遇到的问题。

4.4 运营辅助功能：补货记录与销售统计

补货记录这个功能是零食售货机场景的标志性功能。运营人员操作补货时，选择一个商品，输入补货数量，后端做两件事：将补货记录插入restock_record表，同时增加product表中的stock和对应更新。这个逻辑很简单，但它体现了"业务操作要留痕"的设计思想。

销售统计部分我实现了一个简单的数据面板：总销售额、总订单量、总商品数、累计销量、按分类的销量占比（用柱状图展示）、近7天销售额折线图。图表组件我用的ECharts，后端只需要提供统计数据查询接口，前端负责渲染。答辩时数据可视化永远是最吸引老师眼球的部分，建议这个功能一定要有。

5. 开发过程中踩过的坑与高效的避坑方案

5.1 MySQL 8.0时区问题导致的连接失败

这是一个非常经典的坑。本地装的是MySQL 8.0，JDBC连接串里如果没配置时区参数，启动项目时会报The server time zone value 'ÖÐ¹ú±ê×¼Ê±¼ä' is unrecognized错误，中文环境下的乱码时区名让人摸不着头脑。解决办法是在JDBC连接串中显式指定时区：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/snack_vending?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

这个配置顺手把编码问题也解决了，否则插入中文数据时会变成问号。

5.2 MyBatis Plus逻辑删除与唯一索引的冲突

前面提到商品表设计了name + deleted的业务唯一性想法。但这里有个很隐蔽的问题：如果对商品名建立唯一索引，逻辑删除后再次插入同名商品时，因为Index中唯一索引包含了deleted字段，当deleted为0时出现两条记录，唯一索引就会冲突。生产环境的通用解法是：把deleted字段改为deleted_time，用删除时间做唯一约束部分。课设场景下我的处理方式是放弃了数据库层唯一约束，改为在Service层做校验。这个取舍可以写进文档的"遇到的问题与解决方案"章节，会让文档更有真实感。

5.3 金额字段使用Long还是BigDecimal

这个坑在网络项目中存在很多错误示范。很多教程喜欢用double类型存价格，但浮点数运算会有精度丢失，造成金额计算错误。我在这个项目的所有金额字段均使用BigDecimal，并且所有计算都通过BigDecimal的add和multiply方法进行，避免直接使用double运算。这是做任何涉及金额的系统时最基本的一条红线，必须在第一版就定下来。

5.4 跨域问题与前后端联调

使用Vue分离方案后，前端devServer端口在8080，后端在8089，两者不同源，浏览器会拦截前端发出的Ajax请求，报跨域异常。解决方案我用了两种，最终保留的是后端全局CORS配置：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

注意allowedOriginPatterns("*")和allowCredentials(true)必须配套使用，如果只写allowedOrigins("*")会报错。这个细节我调试了很久，算是比较典型的兼容性问题。

5.5 数据库连接池连接数耗尽问题

第一次压测时出现了Connection is not available, request timed out after 30000ms的报错。原因是HikariCP默认连接池大小是10，而我启动了一堆异步任务和定时任务，同时在调试其他功能，把连接池打满了。解决方法是调大连接池并在application.yml中设置合理的超时时间：

yaml复制spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000

这个调整解释起来也很有价值：说明你清楚数据库连接池的工作机制，而不是遇到报错只知道重启。连接池参数在课设阶段不需要调得多精细，但要知道每个参数的含义。

6. 部署发布与课程设计文档的编写思路

6.1 打包与部署的完整流程

项目打包之前，重点检查几个地方：

确认application.yml里的数据库连接信息是最终环境信息；
如果是前后端分离项目，前端要执行npm run build把产物放在Nginx静态目录；
后端打包：mvn clean package -DskipTests，生成target/snack-vending.jar。

部署时我用的是最稳妥的"单机部署"方式：云服务器装一个MySQL，放入数据库脚本，然后直接java -jar snack-vending.jar启动后端。如果是演示给老师看，完全不一定要上云服务器，本地用IDEA启动后端，用VSCode启动前端，或者直接打包前端产物放在后端static目录下，一个端口跑通全站，也是一个可行性很高的方案。

6.2 课程设计文档的核心章节与写作建议

对标这个项目的"万字文档"，我整理了一份文档大纲，供参考：

引言：项目背景（自动售货机行业现状）、开发目的与意义、国内外研究现状；
需求分析：可行性分析（经济、技术、操作）、功能需求（用户、商品、订单、统计）、非功能需求（性能、安全、易用性）；
系统设计：总体架构图、功能模块图、数据库ER图、数据字典；
系统实现：每个核心功能的实现思路、关键代码、运行截图；
系统测试：测试环境、测试用例表、测试结果分析；
总结与展望：项目成果总结、不足之处与后续优化方向。

文档的页数要求，我用的是四号字、1.5倍行距，加核心代码和截图之后，整体在30页左右。这里有一个小建议：文档里的截图一定要真实，不要从网上复制，因为答辩时老师会让你现场演示，如果演示结果和文档截图对不上，会很尴尬。

6.3 答辩时的高频问题预判

根据我参加过的多次答辩经验，老师最喜欢问的问题集中在以下几个方面：

你的系统有哪些角色？权限是怎么控制的？
数据库表之间是什么关系？为什么订单明细要冗余商品名称？
下单时如何保证库存不超卖？
密码是怎么存储的？安全性如何保证？
如果系统上线，你觉得哪些地方还需要改进？

这些问题你只要在本项目中真的搞明白了上述设计逻辑，都能回答上来。特别是"为什么订单明细要存商品快照"这个问题，从"历史数据不可变"角度回答，非常加分。

我在整体项目中的实操心得

做课设项目最忌眼高手低。市面上很多项目源码看起来功能满满，实际跑起来各种报错，原因往往是环境版本不一致。如果你要复用这个项目，建议严格按照下面三步走：

第一步，搭环境：JDK 8、Maven 3.6+、MySQL 8.0、Node.js 14+（如果是Vue方案），先别急着跑代码，确保环境版本都匹配；
第二步，改配置：把application.yml里的数据库用户名密码改成你自己的，执行sql目录下的数据库脚本；
第三步，按模块验收：先跑通登录，再跑通商品管理，再跑购买流程，最后看统计报表，每一块都打通了，再去看细节。

我在实际使用中发现，这个系统最值得"再加一把火"的地方，是接入微信支付或者支付宝沙箱支付。虽然课设里模拟支付已经够用，但如果你把模拟支付换成真实支付通道（接入沙箱环境），项目实战感会瞬间提升一个层次。另外把订单超时自动取消的定时任务加上，也算是一个里程碑式的完善。这些扩展，在你前期设计时预留好订单状态的扩展空间后，实现起来都比较顺畅。