基于SpringBoot的宠物用品商城系统：从数据库设计到部署完整解析-代码聚汇网

基于SpringBoot的宠物用品商城系统：从数据库设计到部署完整解析

流浪小鱼·2026-09-02·阅读 95 GEO检测（免费）

SpringBoot宠物用品系统电商系统

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

去年底，我帮一个学弟把他的毕业设计从常见的“图书管理系统”换成了“基于SpringBoot的宠物用品系统”。选这个题目很现实：宠物市场本身热，系统又是一个完整的电商闭环——商品、购物车、订单、模拟支付、后台管理，能讲的故事足够多，工作量又不像真正的电商平台那么夸张。做完之后他顺利通过答辩，还把项目写进了简历。如果你也在做类似的题目，或者正准备拿一个“宠物用品商城”当练手项目，这篇文章会按我实际做的顺序，把需求梳理、技术选型、数据库设计、后端核心链路、部署演示全部捋一遍，重点放在那些教程里不会明说、但一定会踩的坑上。

1. 先想清楚：宠物用品系统到底要解决谁的什么问题

很多同学拿到题目第一件事就是打开IDEA建工程，我建议反过来，先想清楚系统给谁用、用哪些功能。宠物用品系统的本质是一个B2C商城，不是管理后台展示，也不是简单的CRUD堆砌。你后面所有表结构、接口设计、页面跳转，都取决于你希望用户在这套系统里完成什么操作。

1.1 用户角色与核心诉求拆解

系统里至少要区分两类角色，如下表：

角色	核心诉求	对应功能
普通用户	快速找到想要的宠物用品并完成购买	注册登录、分类浏览、搜索商品、商品详情、加入购物车、下单结算、模拟支付、查看订单、确认收货、发表评论
管理员	管理商品和订单，掌握经营情况	商品增删改查、上下架、库存管理、分类管理、订单发货与处理、用户管理、数据统计

这个划分决定了项目要分成两个“面”：前台商城和后台管理端。前台是用户看到并操作的部分，后台是管理员维护数据和处理订单的部分。做的时候可以共享一套后端接口，但页面和权限必须分清楚。

1.2 功能边界：先做MVP再考虑锦上添花

我的建议是，第一版只做核心闭环：用户登录、商品分类浏览、商品详情、购物车、提交订单、模拟支付、后台发货、确认收货。把这些流程跑通，整个系统的数据流就完整了，也就有了答辩时能讲清楚的主线。

第二版再考虑加亮点。比如订单超时未支付自动取消、热销商品排行榜、管理端数据大屏、商品评论和回复。至于优惠券、积分、秒杀、拼团、直播带货这些，除非时间非常充裕，否则不建议碰。原因很简单：这些功能每一个都会牵扯到复杂的并发、状态和边界问题，容易把项目拖垮。

我还见过有人一上来就想用flowable工作流引擎去管订单审核、用powerjob做定时任务调度，这个项目里完全没必要。订单就是状态机流转，不是审批流；定时任务用一个@Scheduled就能解决。技术选型上“克制”一点，反而是加分的。

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

2. 技术选型不是越新越好：SpringBoot项目如何定框架

宠物用品系统的技术栈，一句话总结：用你最有把握、资料最多的那套，而不是最新最炫的那套。下面是我实际采用且推荐给多数人的搭配。

2.1 后端技术栈的选择理由

后端核心是SpringBoot + Java，这个不用纠结。但具体版本要注意：

SpringBoot 2.7.x + JDK 8：最稳，网上教程、插件、云服务器环境几乎都兼容，很多老代码可以直接抄。
SpringBoot 3.x + JDK 17：新项目可以选，但大量教程里的 javax.* 已经变成 jakarta.*，面试官不一定在意，但你会多花不少时间填坑。

我的建议是，如果你只是为了完成课题或项目，选2.7.x + JDK 8。如果你想要简历上写“使用Spring Boot 3”这种新鲜度，那就要做好踩坑准备。项目中期绝对不要随便升/降版本，我见过太多人因为Java版本切换，把项目折腾到跑不起来。

持久层我用的是MyBatis-Plus。它是MyBatis的增强工具，单表CRUD和分页可以直接用内置方法，省掉大量XML。代码生成器也可以安排上，实体、Mapper、Service一套生成，极大节省时间。这里有一个细节：SpringBoot 2.x要引入 mybatis-plus-boot-starter，SpringBoot 3.x要引入 mybatis-plus-spring-boot3-starter，版本不对启动直接报错。

鉴权方案用了JWT。为什么不用Session？因为当前后端分离越来越常见，Session需要处理跨域Cookie、保持会话状态，而JWT是无状态的，后端只需要校验签名，用户信息放在令牌里，简单直接。毕设和课程设计用JWT完全够。

Redis不是必需的。如果项目要加分，可以用Redis缓存商品热点数据、做购物车、存登录黑名单token，但不要为了用而用。一个课程设计如果引入了Redis、消息队列、分布式锁，却讲不清楚为什么要用，反而容易被追问到哑口无言。

2.2 前端方案与前后端如何衔接

前端我推荐Vue 3 + Element Plus + Axios。这套组合在前后端分离项目里非常成熟，Element Plus自带表格、表单、弹窗、分页组件，做后台管理界面效率很高。

如果你前端基础一般，也可以选择SpringBoot + Thymeleaf + Bootstrap，服务端渲染，不用写跨域，不用处理Token，页面直接套模板。但电商项目交互比较多，购物车加减、列表筛选、订单状态的切换用Vue写起来会更顺手，所以我还是建议尝试前后端分离。

前后端分离之后，关键是要约定好接口规范。我习惯用一个统一返回体：

java复制public class Result<T> {
    private Integer code;
    private String message;
    private T data;
}

code为0表示成功，非0表示业务异常。分页接口再包一层PageResult，包含total、list、current、size。这样前端只需要在Axios拦截器里统一处理code，不用每个接口单独写错误判断。

2.3 环境准备与工程骨架搭建

基础工具我列一份清单：

JDK 8（或17，取决于SpringBoot版本）
Maven 3.8+
MySQL 8.x
IDEA 2023+
如果是前后端分离，还需要Node.js 16+

新建Spring Boot工程时，依赖一般选这几个：spring-boot-starter-web、mysql-connector-j、lombok、spring-boot-starter-validation，再手动加上MyBatis-Plus依赖。

application.yml是项目启动的门面，这里贴一份核心配置：

yaml复制server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/pet_shop?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
    map-underscore-to-camel-case: true
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

注意几个点：serverTimezone=Asia/Shanghai是MySQL 8必须加的，否则时间差8小时；jackson.time-zone=GMT+8解决接口返回时间差8小时；logic-delete-field配置了逻辑删除字段，商品删除走逻辑删除而不是物理删除，数据不会真丢。

如果你有心情，还可以用在线banner生成器给自己的项目加一个启动标语，纯娱乐，不影响功能。但证明你折腾过SpringBoot的这些小生态，聊起来也算个话题。

3. 数据库设计：宠物用品系统的核心表结构与字段取舍

数据库设计是整个系统最值得花时间的地方。表设计不合理，后面写接口会处处别扭。我的方法是：从用户操作反推表。

3.1 从业务操作反推表设计

用户要注册登录，所以有用户表；要浏览商品，所以有分类表和商品表；要加购，所以有购物车表；要下单，所以有订单主表和订单明细表；要填收货地址，所以有地址表；要评论，所以有评论表。核心就是这8张表。

商品表是关键表，字段设计要兼顾展示和库存管理：

sql复制CREATE TABLE `product` (
  `id` bigint(20) NOT NULL COMMENT '商品ID',
  `category_id` bigint(20) NOT NULL COMMENT '分类ID',
  `name` varchar(120) NOT NULL COMMENT '商品名称',
  `subtitle` varchar(200) DEFAULT NULL COMMENT '副标题',
  `main_image` varchar(500) DEFAULT NULL COMMENT '主图地址',
  `price` decimal(10,2) NOT NULL COMMENT '售价',
  `stock` int(11) NOT NULL DEFAULT '0' COMMENT '库存',
  `sales` int(11) NOT NULL DEFAULT '0' COMMENT '销量',
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1上架 0下架',
  `detail` text COMMENT '详情图文',
  `deleted` tinyint(1) NOT NULL DEFAULT '0' COMMENT '逻辑删除',
  `create_time` datetime NOT NULL,
  `update_time` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有一个很容易被忽略的点：价格字段必须用 decimal(10,2)，不能用 float 或 double。浮点数在Java和MySQL里精度都不可控，电商金额一旦出现0.1+0.2=0.30000000000000004这种问题，是会被一眼看出基本功不扎实的。小数用Decimal，这个习惯越早养成越好。

订单相关表是另一个重点。订单主表记录一笔订单的整体信息，包括订单号、用户、金额、收货信息、状态；订单明细表记录这笔订单里有哪些商品，每个商品多少钱、多少个。两张表是典型的一对多关系。

3.2 订单状态流转与状态字段约定

订单状态字段用一个小整数表示，简单且便于扩展：

状态值	含义	触发行为
0	待付款	用户提交订单后
1	待发货	模拟支付成功后
2	待收货	管理员点击发货后
3	已完成	用户确认收货后
4	已取消	用户取消或超时未支付
5	退款中/已退款	售后流程

整个系统的核心业务流程就是跟着这张状态表走的。要注意的是：什么时候释放库存。正常情况下，用户下单后库存就扣减了，订单取消或退款时才释放库存。如果下单不扣库存，会出现超卖；如果取消不释放库存，会出现库存越来越少但订单没成交的假象。

3.3 订单明细为什么要冗余商品快照

初次做商城的人最容易遗漏的一个点：订单明细里除了product_id，还要冗余存一份商品名称、商品主图、单价。原因是，商品表里的信息是可变的，管理员随时可能改价、下架甚至删除商品，但订单是历史数据，必须冻结下单那一刻的信息。如果不做冗余，三个月后打开旧订单，商品名可能显示成“已删除商品”，价格也可能是改过的，这是很严重的体验问题。

冗余字段虽然违反了严格意义上的“第三范式”，但在电商系统里这是正确取舍。数据库设计要服务于业务，不是背理论。

3.4 索引与逻辑删除

需要重点加的索引：

商品表：category_id（分类筛选）、name（搜索，数据量大后可以换全文索引）
购物车表：(user_id, product_id) 联合唯一索引，防止同一商品重复加购
订单表：order_no 唯一索引，user_id 普通索引
订单明细表：order_id 普通索引

逻辑删除用MyBatis-Plus配置好之后，所有查询都会自动带上 deleted = 0 条件，不需要自己写。但要注意：唯一索引字段在逻辑删除下可能出问题，比如用户表删除后用户名为空，新用户又注册了同一个用户名，会撞唯一索引。解决办法通常是给username字段加上删除标记拼接，或者干脆不允许物理删除用户。这个点不一定用得上，但答辩时提一句，会显得你真的考虑过。

4. 后端业务实现：从登录到下单的完整链路

单表CRUD没什么好讲的，真正体现系统价值的是登录鉴权、购物车、下单和库存扣减这一整条链路。

4.1 JWT登录鉴权与用户上下文

用户登录流程：按用户名查出用户，校验密码，密码用BCrypt或加盐MD5存储，校验通过后生成JWT令牌返回前端。前端每次请求在Header里带 Authorization: Bearer <token>。

JWT工具类核心逻辑：

java复制public class JwtUtil {
    private static final String SECRET = "pet-shop-secret-key";

    public static String createToken(Long userId, String username) {
        return Jwts.builder()
                .setSubject(String.valueOf(userId))
                .claim("username", username)
                .setExpiration(new Date(System.currentTimeMillis() + 1000L * 60 * 60 * 24))
                .signWith(SignatureAlgorithm.HS256, SECRET)
                .compact();
    }
}

有了token之后，需要一个拦截器在每个请求里解析token、拿到当前用户。我用HandlerInterceptor实现，注册到WebMvcConfigurer里，排除登录、注册、商品列表、商品详情等公开接口。

java复制public class LoginInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");
        // 校验token，失败则返回401，成功则把userId放入ThreadLocal
        return true;
    }
}

为什么用ThreadLocal保存当前用户？因为拦截器到Service、Controller之间不是同一个方法调用栈，直接传参很麻烦，用ThreadLocal可以在一次请求线程的任何地方取到当前用户，请求结束再remove掉，避免线程池复用导致的数据串号。这个点是Java后端面试高频题，项目里实际用上了，才算真正理解。

4.2 商品列表与分类筛选接口实现

商品列表是前台访问量最大的接口。用MyBatis-Plus分页加条件构造器：

java复制Page<Product> page = new Page<>(current, size);
LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(StringUtils.isNotBlank(categoryId), Product::getCategoryId, categoryId)
       .like(StringUtils.isNotBlank(keyword), Product::getName, keyword)
       .eq(Product::getStatus, 1)
       .orderByDesc(Product::getSales);

productMapper.selectPage(page, wrapper);

这里有一个细节：列表接口不要把detail这种大文本字段查出来，只查主图、名称、价格、销量就够。详情页单独提供一个接口查询完整信息。做过分页查询的人都知道，底层应该是SELECT *还是查指定字段，对行数多的表性能影响非常明显。

4.3 购物车逻辑与价格计算

购物车表设计成 user_id + product_id + quantity + checked 四件套。加购逻辑很直接：先查这个用户是否已经加过这个商品，加过就把数量加一，没加过就插入一条。数量要限制，不能超过商品库存，也不能无限加。

这里必须强调一个原则：购物车里显示的价格和结算总价，一定要后端根据商品表实时计算，不能信任前端传来的price，更不能在前端把价格相加后传回来。前端价格只用于展示，任何涉及金额的最终判断都必须以数据库实时价格为准。这个坑很多新手会踩，审核订单时金额对不上，查半天发现是前端传了修改过的价格。

4.4 下单扣库存与事务一致性

下单接口是整个系统最核心的业务，顺序如下：

校验登录用户和收货地址
根据购物车勾选项或立即购买的商品列表，查询商品的实时价格和库存
校验库存是否充足
生成订单主表，订单号用“时间戳+随机数”或雪花ID
批量生成订单明细
扣减库存、增加销量
清空对应购物车项

这些操作必须在一个事务里完成，用@Transactional(rollbackFor = Exception.class)：

java复制@Transactional(rollbackFor = Exception.class)
public Order createOrder(Long userId, List<CartItem> cartItems, Address address) {
    // 1. 查询商品并校验库存
    // 2. 计算总金额
    // 3. 插入订单和明细
    // 4. 扣库存
    // 5. 清空购物车
    return order;
}

防超卖的关键在扣库存这一步，不能用“先查库存，再update库存”这种两步走，因为并发场景下两个请求可能同时查到同一个库存数。正确做法是SQL里直接带上库存条件：

sql复制UPDATE product SET stock = stock - #{count}, sales = sales + #{count}
WHERE id = #{productId} AND stock >= #{count}

UPDATE返回的影响行数为1，说明扣减成功；为0，说明库存不足，直接抛业务异常回滚。这种做法没有引入Redis分布式锁，但足够应对课程设计和大部分小流量场景，而且容易被面试官认可。

4.5 模拟支付与订单状态推进

真实对接微信或支付宝需要企业资质、证书、回调接口，课程设计完全没必要。可以做一个模拟支付接口：根据订单号把订单状态从“待付款”改成“待发货”，同时记录支付时间。后期如果想扩展，可以把支付逻辑抽成一个PayService接口，将来替换成真实支付实现。

管理员发货接口把订单置为“待收货”，用户确认收货后置为“已完成”。取消订单逻辑要谨慎：只有在“待付款”状态下才能取消，并且要恢复库存。这些都是状态机的边界，每个状态转换都要想清楚允许哪些入口。

4.6 管理后台的数据统计

如果想让项目有亮点，加一个管理端数据统计页。用聚合查询统计每日订单量、销售额、热销商品Top10，前端用ECharts展示折线图和柱状图。例如每日销售额：

sql复制SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS day, SUM(pay_amount) AS amount
FROM `order`
WHERE pay_time IS NOT NULL
GROUP BY day
ORDER BY day

这类SQL数据量小的时候性能没问题，但思路要能讲清楚：为什么用DATE_FORMAT分组，为什么聚合查询要避免全表扫描。答辩时拿出一个统计图表，比生硬地介绍十个增删改查接口要有说服力得多。

5. 项目跑起来之后的真实踩坑清单

做完这个宠物用品系统，前前后后踩了不少坑，我想挑几个典型的记录下来，都是能复现的。

5.1 SpringBoot版本太高导致javax变jakarta

现象：项目用的SpringBoot 3.x，照着网上教程写过滤器，import javax.servlet.http.HttpServletRequest直接编译报错。

原因：SpringBoot 3.0把Java EE迁移到了Jakarta EE，原来所有的javax.*都变成了jakarta.*，同时要求最低JDK 17。很多老教程、老代码默认是2.x时代，硬套会踩坑。

解决：要么把SpringBoot降到2.7.x + JDK8，要么把代码里的javax.servlet改成jakarta.servlet。

这个坑和“源发行版17需要目标发行版17”的警告本质上是同一类问题：JDK版本和SpringBoot版本必须匹配。建议开始时就定下来，不要中途切换。

5.2 雪花ID传到前端精度丢失

现象：MyBatis-Plus默认主键策略是雪花算法，生成的ID是Long类型，长度19位。前端JavaScript的Number类型最大安全整数只有2^53，导致列表页能打开，详情页永远404。控制台看接口，发现ID的末尾几位变成了0。

原因：HTTP传输时ID是数字，JSON序列化后前端解析精度丢失。

解决：在实体类ID字段上加注解：

java复制@JsonSerialize(using = ToStringSerializer.class)
private Long id;

把Long类型序列化成字符串，前端拿到字符串就不丢精度了。这也是面试常问的“后端Long到前端精度丢失怎么解决”，项目里实际踩过，讲起来会更有底气。

5.3 前端联调跨域和Cookie问题

现象：前端页面跑在8081端口，后端接口在8080端口，浏览器直接拦截Ajax请求。

解决：后端配置CORS跨域：

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

注意：如果allowCredentials(true)，就不能用allowedOrigins("*")，要换成allowedOriginPatterns("*")，否则部分浏览器会直接报错。

5.4 事务失效的经典场景

下单接口明明加了@Transactional，库存还是扣重了。排查后发现问题不在SQL，而在事务根本没生效。我遇到的具体场景是：Controller调用同一个类里的另一个方法，这个方法上加了@Transactional，但Spring AOP是通过代理对象调用方法的，类内部this调用不会经过代理，事务自然失效。

解决：把需要事务的方法拆到另一个Service里，或者注入自身代理。另外还需要注意，默认情况下@Transactional只对RuntimeException回滚，如果代码里catch住异常没有抛出，事务同样不会回滚。在catch块里要记得抛出RuntimeException，或者在注解上设置rollbackFor = Exception.class。

5.5 时间差8小时问题

现象：数据库Insert的时间比北京时间少8小时，或者接口返回时间少了8小时。

原因：MySQL 8默认时区是UTC，JDBC连接参数里没指定时区，导致时间转换错位。

解决：数据源URL加serverTimezone=Asia/Shanghai，Jackson配置time-zone: GMT+8，实体类时间字段用LocalDateTime而不是Date。这三个位置都统一，前后端时间就一致了。

5.6 静态资源与商品图片上传

商品图片如果直接传到项目的target目录或resources目录，重启后文件就没了，临时文件丢失。正确做法是配置本地磁盘路径，再把路径映射成URL访问。

yaml复制upload:
  path: /data/pet-shop/img/

WebMvcConfigurer里加资源映射：

java复制@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
    registry.addResourceHandler("/upload/**")
            .addResourceLocations("file:" + uploadPath);
}

这样图片统一走/upload/xxx.jpg访问，重启不丢，也方便备份。如果以后部署到云服务器，还可以把图片目录挂载到对象存储。

6. 打包部署与演示环节的经验补充

项目代码写完只是第一步，能打包部署，能顺畅演示，才算真正完成。

6.1 Maven打包与jar运行

后端打包：

bash复制mvn clean package -DskipTests

打完包后，在target目录生成jar文件，服务器上运行：

bash复制nohup java -jar pet-shop-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod > app.log 2>&1 &

如果是前后端分离，前端单独打包：npm run build生成dist目录，用Nginx托管。Nginx再配置反向代理，把/api前缀转发到后端8080端口。不熟悉Nginx的话，也可以把前端dist文件放进后端src/main/resources/static目录，和jar一起打进去，这样只部署一个jar就能访问整个系统，适合课程设计演示。但这种方式不适合真实项目，稍微聊到“前后端分离部署”时容易被追问，所以答辩时最好说清楚自己采用的部署方式以及为什么。

6.2 用Docker部署的简短方案

如果想让项目更工程化，可以用Docker部署。后端Dockerfile很简单：

dockerfile复制FROM openjdk:8-jdk-alpine
COPY pet-shop-0.0.1-SNAPSHOT.jar /app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]

再配合docker-compose，把MySQL和app一起启动。这里最关键的坑是：容器内的Java应用连接数据库时，localhost不能用了，要改成docker-compose里MySQL服务的名称，比如jdbc:mysql://mysql:3306/pet_shop。如果是在Docker Desktop里打包运行，还要注意镜像平台和内存分配，不然构建或启动时容易出现OOM。

6.3 答辩或演示时的演示路径

演示之前一定要准备好演示数据，我建议至少6个分类、每个分类5到8个商品、一个测试用户账号，并且把库存设置成不尴尬的数字。

演示路径按用户真实操作走：注册登录 → 首页浏览 → 搜索商品 → 进入详情 → 加入购物车 → 结算下单 → 模拟支付 → 后台发货 → 确认收货 → 后台查看统计数据。

演示前要检查几个容易翻车的地方：登录token是否过期、商品图片能不能正常加载、库存是不是0、订单状态是不是停在“待付款”。另外建议提前预演一遍，确认页面没有因为网络问题导致白屏。

讲解重点放在四个方面：数据库为什么这么设计、订单状态机怎么流转、下单扣库存如何防超卖、JWT鉴权如何实现。这四点比单纯演示功能点更容易给评委留下“这个人真做了项目”的印象。

这个项目做完，我自己最大的一个体会是：系统规模不大，但电商的核心链路——从商品展示到下单支付、库存扣减——每一步都会引出非常具体的技术问题，比如事务边界到底该划在哪里，并发扣库存到底怎么防超卖。这些知识点单独背八股文很容易，但只有自己把订单流程跑通、把库存扣减写对，才会真正理解SpringBoot自动装配、AOP事务代理这些概念在项目里是怎么落地的。后面我帮另一个朋友做类似课题时，又在这个基础上加了管理端数据大屏和商品评论，工作量可控，效果却明显更好。如果你也准备做宠物用品这类电商系统，建议在核心流程跑通后，选一个方向做深一点，比如防超卖优化、订单超时自动取消、日志审计。对一个课程设计或毕设来说，一个亮点比十个平铺直叙的功能更值钱。