企业官网建设流程全解析

很多同学看到"SpringBoot宠物商城"这种毕业设计题目，第一反应就是"不就是个CRUD吗"。话是没错，但如果真把论文答辩现场当成一个CRUD展示会，评委老师大概率会追问到你怀疑人生。我见过太多人把系统做成了"商品表增删改查+订单表增删改查"的演示拼盘，项目能跑，但一问"你的订单状态怎么流转""库存扣减怎么保证不超卖""为什么用Redis而不是直接查数据库"，就哑火了。

这篇东西，我按"你是一个有一定Java基础、但没正儿八经做过完整Web项目的大四学生"的水平来写。全程不讲废话，核心就一件事：让你照着这个思路，把一个基于SpringBoot的宠物用品电商平台从建模、编码到上线答辩，完整做下来，并且禁得起追问。

1. 为什么选SpringBoot做宠物电商，而不是SSH或者SSM

先聊选型。很多学校的Java Web课程还停留在SSH（Struts2+Spring+Hibernate）或者SSM（Spring+SpringMVC+MyBatis）的阶段，毕业设计题目又写着SpringBoot，这时候你要搞清楚一件事：SpringBoot不是取代Spring的新框架，它是把Spring那套繁琐的XML配置和部署流程做了自动装配和简化。

1.1 宠物商城这种业务量与SpringBoot的契合点

宠物用品电商，典型的业务特征是什么？

• 商品数量几百到几千个，不是海量数据
• 用户量前期很少，日活几十到几百都正常
• 并发量很低，秒杀活动那是大厂的事
• 但业务链路完整：浏览商品、加购物车、下订单、支付、发货、收货、售后

这种规模的项目，用微服务架构属于自找麻烦，用SSM手写一堆XML配置也属于低效劳动。SpringBoot恰好卡在中间：它保留了Spring的IOC和AOP能力，又用自动配置省掉了大量模板化配置，内置Tomcat让部署变成一个jar包搞定。对毕业生来说，这意味着你可以把时间花在业务逻辑上，而不是花在"为什么Tomcat又起不来"这种环境问题上。

1.2 我推荐的组件组合

这里直接给我的推荐组合，都是能写进论文、也能解释清楚为什么这么选的东西：

注意：SpringBoot 3.x 最低要求JDK17，而绝大多数学校的毕业设计环境还在JDK8。如果你不想在环境上折腾，老老实实用SpringBoot 2.7.x + JDK8，这组合稳如老狗。

2. 先建模再写码：从数据表设计看懂整个商城业务

很多人一上来就建项目写代码，写到订单模块发现"订单和订单项什么关系没想清楚"，回头再改表结构，非常痛苦。做电商系统，第一步永远是画清楚数据模型，把表设计出来，业务逻辑就清晰了一半。

2.1 宠物商城最少需要哪些表

我按业务域给你拆成五组，总共7张基础表：

用户域

• tb_user：用户表。字段包含id、username、password（BCrypt加密存储）、nickname、avatar、phone、status（是否被封禁）、create_time。这里注意，密码绝对不允许明文存储，答辩老师看到明文密码基本会直接扣分。

商品域

• tb_category：商品分类表。宠物用品分类很典型：猫粮狗粮、零食罐头、玩具、洗护用品、笼具、医疗保健等。用parent_id字段做父子级分类，支持两级就够用了。
• tb_product：商品表。核心字段有product_name、category_id、sub_title（副标题）、main_image、detail（富文本详情）、price、stock、sales（销量）、status（上架/下架）、create_time。
• tb_product_image：商品图片表。一个商品多张图，用product_id关联，按sorted字段排序。

交易域

• tb_cart：购物车表。字段：user_id、product_id、quantity、checked（是否选中）。很多教程喜欢用Redis存购物车，但如果你为了省事把购物车塞进Redis然后session一过期就丢，那反而成了减分项。推荐存MySQL，理解简单、逻辑清晰、答辩好解释。
• tb_order：订单表。这是整个系统的核心。字段：order_no（订单号）、user_id、total_amount、pay_amount、pay_type（微信/支付宝/余额）、status（订单状态）、receiver_name、receiver_phone、receiver_address、pay_time、delivery_time、finish_time、create_time。
• tb_order_item：订单项表。字段：order_id、product_id、product_name（快照）、product_image（快照）、price（快照）、quantity、total_price。**为什么存快照？**因为商品价格和名称会变，你订单生成后不能因为商家改价就跟着变。这个是面试和答辩时的高频追问点。

我把tb_order_item单独拎出来的原因：一个订单包含多种商品，订单和商品是多对多关系，必须通过订单项这张中间表来解耦。没建这张表，整个订单模块就是畸形的。

2.2 订单状态机：答辩必问的经典环节

订单状态是整个电商系统的灵魂。我建议用一组int常量来表示状态：

0 - 待付款 1 - 已付款/待发货 2 - 已发货/待收货 3 - 已收货/待评价 4 - 已评价/已完成 5 - 已取消（超时未支付或用户取消）

状态机的核心在于不是所有状态都能任意跳转。比如订单从"待付款"只能流转到"已付款"或"已取消"，不能直接变成"已发货"。你可以把这些判断写在Service层，或者用状态机设计模式封装。

我之前带过一个学弟，他把订单状态设计成String存"待付款"“已完成”这种中文，结果前端判断状态乱成一团。用int存状态码，用常量类或枚举定义可读性，前端拿到再做映射，这才是规范做法。

2.3 一个细节：订单号生成规则

订单号不要用数据库自增id，因为会暴露销量（别人下单几次一减就知道）。我用的方案是：

// 时间戳 + 用户ID后四位 + 随机数 public static String generateOrderNo(Long userId) { String time = new SimpleDateFormat("yyyyMMddHHmmss").format(new Date()); String uid = String.format("%04d", userId % 10000); int random = (int)((Math.random() * 9 + 1) * 1000); return time + uid + random; }

生成结果类似2025061514303200012345，28位，够用而且不容易重复。当然你也可以引入雪花算法，但在这个项目里用雪花算法有点大炮打蚊子。

3. 后端核心模块的实现思路：商品、购物车、订单

项目结构我推荐用标准的Controller-Service-Mapper三层架构，加上config、common、dto、vo几个辅助包。Controller层只做参数接收和结果返回，Service层写业务逻辑，Mapper层用MyBatis-Plus直接操作数据库。

3.1 商品模块：为什么建议用分类下钻+关键字搜索

商品模块看起来就是一堆查询接口，但有两个地方值得花心思：

第一个是商品列表的分页搜索。我的查询逻辑是：前台传分类id、关键字、排序方式、页码、每页条数，Mapper层用MyBatis-Plus的QueryWrapper动态拼接条件。核心代码给你看一段：

@Override public IPage<ProductVO> queryProductList(Long categoryId, String keyword, String sort, Integer pageNum, Integer pageSize) { Page<Product> page = new Page<>(pageNum, pageSize); QueryWrapper<Product> wrapper = new QueryWrapper<>(); // 分类筛选：支持一级分类下查所有二级分类的商品 if (categoryId != null) { wrapper.eq("category_id", categoryId); } // 关键字模糊搜索 if (StringUtils.isNotBlank(keyword)) { wrapper.like("product_name", keyword).or().like("sub_title", keyword); } // 排序：可选价格升序/降序，销量，默认按创建时间 if ("price_asc".equals(sort)) { wrapper.orderByAsc("price"); } else if ("price_desc".equals(sort)) { wrapper.orderByDesc("price"); } else if ("sales".equals(sort)) { wrapper.orderByDesc("sales"); } else { wrapper.orderByDesc("create_time"); } IPage<Product> productPage = productMapper.selectPage(page, wrapper); // 转换为VO对象，避免直接把数据库字段暴露给前端 return convertToVO(productPage); }

第二个是商品详情做了缓存。商品浏览次数多、更新频率低，非常适合放Redis。用户打开商品详情页，先查缓存，命中直接返回；没命中查数据库然后写入缓存，设置过期时间。

public ProductVO getProductDetail(Long id) { // 1. 查缓存 String key = "product:detail:" + id; String json = redisTemplate.opsForValue().get(key); if (StringUtils.isNotBlank(json)) { return JSON.parseObject(json, ProductVO.class); } // 2. 缓存未命中，查数据库 Product product = productMapper.selectById(id); // 3. 写入缓存，设置30分钟过期，过期后自动更新 redisTemplate.opsForValue().set(key, JSON.toJSONString(product), 30, TimeUnit.MINUTES); return convertToVO(product); }

这里有个小坑：如果你的项目用了MyBatis-Plus，实体类默认开启了@JsonIgnore的字段序列化时会出问题，建议用独立的VO类去承接返回给前端的字段，不要把数据库实体直接返回。

3.2 购物车模块：从增删改查到下单的衔接

购物车我做过两种方案，一种纯MySQL，一种Redis，我推荐MySQL。

表设计上面给过了，核心业务也就四个操作：添加商品、修改数量（含勾选状态）、删除、查询列表。

下单时从购物车选中商品生成订单的逻辑，是整个链路里最容易出Bug的地方。核心逻辑：

@Transactional @Override public OrderVO createOrder(OrderCreateDTO dto) { // 1. 查询选中的购物车条目 List<Cart> cartList = cartMapper.selectList( new QueryWrapper<Cart>().in("id", dto.getCartIds()).eq("user_id", dto.getUserId()) ); if (cartList.isEmpty()) { throw new BizException("购物车为空，无法下单"); } // 2. 计算总金额、校验商品状态和库存 BigDecimal totalAmount = BigDecimal.ZERO; List<OrderItem> orderItems = new ArrayList<>(); for (Cart cart : cartList) { Product product = productMapper.selectById(cart.getProductId()); if (product == null || product.getStatus() != 1) { throw new BizException("商品已下架：" + cart.getProductId()); } if (product.getStock() < cart.getQuantity()) { throw new BizException("商品库存不足：" + product.getProductName()); } // 价格快照 OrderItem item = new OrderItem(); item.setProductId(product.getId()); item.setProductName(product.getProductName()); item.setProductImage(product.getMainImage()); item.setPrice(product.getPrice()); item.setQuantity(cart.getQuantity()); item.setTotalPrice(product.getPrice().multiply(new BigDecimal(cart.getQuantity()))); orderItems.add(item); totalAmount = totalAmount.add(item.getTotalPrice()); } // 3. 创建订单头和订单项 Order order = new Order(); order.setOrderNo(generateOrderNo(dto.getUserId())); order.setUserId(dto.getUserId()); order.setTotalAmount(totalAmount); order.setPayAmount(totalAmount); order.setStatus(0); order.setReceiverName(dto.getReceiverName()); order.setReceiverPhone(dto.getReceiverPhone()); order.setReceiverAddress(dto.getReceiverAddress()); orderMapper.insert(order); // 4. 批量插入订单项 for (OrderItem item : orderItems) { item.setOrderId(order.getId()); orderItemMapper.insert(item); } // 5. 扣减库存 for (Cart cart : cartList) { productMapper.decreaseStock(cart.getProductId(), cart.getQuantity()); } // 6. 删除已下单的购物车记录 cartMapper.deleteBatchIds(dto.getCartIds()); return convertToOrderVO(order); }

注意几个关键点：

1. 方法必须加@Transactional，因为创建订单头、创建订单项、扣库存、删购物车这几步是一个原子操作，任何一步失败都要回滚，否则会出现"订单建了库存没扣"或者"钱扣了订单没生成"这种恶性Bug。
2. 扣库存用UPDATE product SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}这样的SQL原子操作，而不是先查出来再减——前者在并发下不会超卖，后者一定会超卖。
3. 确认付款时，判断total_amount和pay_amount要用BigDecimal.compareTo()，不能直接调equals()，因为BigDecimal(1.0)和BigDecimal(1.00)在equals语义中是不相等的。

3.3 订单模块：超时关闭、发货、收货状态流转

订单模块里，我觉得最值得写的是超时未支付自动关闭这个逻辑。做法很简单：SpringBoot自带的@Scheduled定时任务，每分钟扫描一次超过30分钟未支付的订单，把状态改成已取消。

@Component public class OrderTimeoutTask { @Autowired private OrderMapper orderMapper; @Scheduled(cron = "0 */1 * * * ?") public void closeTimeoutOrders() { // 查询所有超过30分钟仍未支付的订单 Date deadline = new Date(System.currentTimeMillis() - 30 * 60 * 1000); List<Order> timeoutOrders = orderMapper.selectList( new QueryWrapper<Order>() .eq("status", 0) .lt("create_time", deadline) ); for (Order order : timeoutOrders) { // 关闭订单，回补库存 order.setStatus(5); orderMapper.updateById(order); // 回补库存：把订单项中的商品数量加回去 List<OrderItem> items = orderItemMapper.selectList( new QueryWrapper<OrderItem>().eq("order_id", order.getId()) ); for (OrderItem item : items) { productMapper.increaseStock(item.getProductId(), item.getQuantity()); } } } }

这里有个关键问题：定时任务要加锁吗？单机部署时不需要，但你如果写进论文里，老师问"如果部署多台服务器，定时任务会不会重复执行"，你需要能答出来——分布式环境下要引入分布式锁（比如Redis的SETNX），但本项目中单机部署，@Scheduled够用。

发货和收货就简单了：发货就是后台管理员改订单状态为2，填物流单号；收货就是用户在个人中心点击确认收货，状态改为3。这里加一个update_time或者操作时间记录更规范。

4. SpringBoot集成里的几个大坑：版本、自动配置、事务失效

写代码期间一定会踩得最狠的，就是SpringBoot本身的一些坑。我整理最有代表性的三个，每一个答辩老师都可能问到。

4.1 SpringBoot版本和依赖版本的"版本地狱"

先说版本问题。在Maven的pom.xml里，spring-boot-starter-parent作为父工程管理所有依赖版本。但如果你还引入了MyBatis-Plus、Redis、JWT这些第三方库，它们的版本spring-boot-starter-parent管不了，得自己指定。

以MyBatis-Plus为例，最典型的版本坑：

<!-- SpringBoot 2.7.x 推荐用 mybatis-plus 3.5.x --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency>

如果你用的是SpringBoot 3.x，那MyBatis-Plus必须上3.5.4以上的版本才能兼容，而且还需要引入mybatis-plus-jsqlparser这种可选的额外依赖，很多同学折腾一晚上就是死在版本匹配上。我给你的建议就是那句话：如果不是学校强制要求，SpringBoot 2.7.x + JDK8 + MyBatis-Plus 3.5.x，全项目所有依赖都锁死这套组合。

4.2 自定义自动配置：SpringBoot的启动原理

答辩老师很喜欢问"SpringBoot为什么能自动配置"。这个得分两部分答：条件注解和SPI机制。

简单说，SpringBoot在启动时会去加载META-INF/spring.factories（2.7及以前）或者META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（3.x以后）文件里注册的所有自动配置类。每个配置类上都有@ConditionalOnClass、@ConditionalOnProperty、@ConditionalOnMissingBean这些条件注解，只有条件满足才生效。

比如你引入了spring-boot-starter-data-redis，RedisAutoConfiguration类上的@ConditionalOnClass(RedisOperations.class)才成立，SpringBoot才会自动帮你创建一个RedisTemplate和StringRedisTemplate的Bean。你没引入Redis依赖，这个类直接跳过。

如果你想写一个自定义自动配置来展示一下自己对SpringBoot的理解，可以这么做：

@Configuration @ConditionalOnClass(ProductService.class) @EnableConfigurationProperties(MyProperties.class) public class MyAutoConfiguration { @Bean @ConditionalOnMissingBean public ProductCacheManager productCacheManager(MyProperties properties) { return new ProductCacheManager(properties.getCachePrefix()); } }

然后在resources/META-INF/spring.factories里注册这个配置类：

org.springframework.boot.autoconfigure.EnableAutoConfiguration=com.example.config.MyAutoConfiguration

这段代码往论文里一放，"深度理解SpringBoot自动配置机制"这个方向就直接立住了。

4.3 @Transactional失效的几种场景

这是所有SpringBoot项目里最高频的Bug，没有之一。我总结我踩过和带人踩过的场景：

场景一：方法内部自调用。同一个类里methodA()调methodB()，@Transactional标在methodB()上，事务不生效。因为Spring的事务是基于AOP代理的，自调用不走代理对象，直接调原始方法。

// 错误示范：@Transactional在methodB上，但A调B是自调用 public void methodA() { this.methodB(); // 事务不生效 } @Transactional public void methodB() { // ... }

解决办法：把methodB放到另一个Service里，或者注入自身代理对象。

场景二：异常被吞掉了。@Transactional默认只在RuntimeException和Error时回滚，如果你在方法里try-catch把异常吃掉了，事务永远不知道出错了，自然不会回滚。

@Transactional public void create() { try { orderMapper.insert(order); int i = 1 / 0; // 被catch住了，事务不回滚 } catch (Exception e) { log.error("除数不能为0", e); } }

解决办法：要么别catch，要么catch后需要throw new RuntimeException(e)，或者在@Transactional(rollbackFor = Exception.class)指定回滚所有异常。

这两个场景一定要写进论文的"常见问题与解决方案"章节，因为这是实际开发中一定会遇到的东西，评委老师一听就知道你做过项目，不是你编的。

5. 前端与后端联调的技术细节：Session还是JWT

现在的毕业设计基本都要求前后端分离，前端用Vue或者简单地用Thymeleaf模板引擎。我之前带的学生大部分用的Vue3+Vite+Element Plus，后端提供RESTful API。这里涉及一个关键技术点：用户认证怎么做。

5.1 JWT认证方案的落地

我建议用Spring Security + JWT。JWT请求流程是这样的：

1. 用户登录，后端校验用户名密码，生成JWT token（里面带上用户id）
2. 前端把token存在localStorage或pinia里，每次发请求都放到Authorization请求头
3. 后端写一个认证过滤器，拦截请求校验token有效性，校验通过就把用户信息放入SecurityContextHolder

核心代码我贴一下JWT的工具类：

@Component public class JwtUtils { @Value("${jwt.secret}") private String secret; @Value("${jwt.expire}") private Long expire; // 过期时间，单位秒 public String generateToken(Long userId) { Date now = new Date(); Date expireDate = new Date(now.getTime() + expire * 1000); return Jwts.builder() .setSubject(String.valueOf(userId)) // 存用户id .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Long getUserIdFromToken(String token) { Claims claims = Jwts.parser() .setSigningKey(secret) .parseClaimsJws(token) .getBody(); return Long.valueOf(claims.getSubject()); } public boolean validateToken(String token) { try { Jwts.parser().setSigningKey(secret).parseClaimsJws(token); return true; } catch (Exception e) { return false; } } }

注意：生成token密钥secret不要硬编码到代码里，放application.yml里，用@Value读取。答辩时候如果有人问"配置泄露怎么办"，你能答出来"通过环境变量或者配置中心管理"，就是加分项。

前端axios拦截器配置如下（这是很多同学容易漏的一部分）：

// request拦截器：每次请求带上token axios.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = token; } return config; }); // response拦截器：token过期时跳到登录页 axios.interceptors.response.use( response => response, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token'); router.push('/login'); } return Promise.reject(error); } );

这里有一个小坑，如果你用Spring Security，不要自己写校验逻辑——真要自己写，推荐直接用JWT工具类包一层HandlerInterceptor来实现，逻辑简单直接，比引入整套Security更好解释、更少踩坑。但论文里写Spring Security全称会让题目看起来更"高级"一些，你可以说"参考Spring Security的认证思想，结合JWT实现无状态认证方案"——这样的话术，老师挑不出毛病又觉得你有思考。

5.2 后台管理端：权限用"一个注解"搞定

前台C端用户用JWT做的，后台管理端怎么办？我用的方案极其简单：写一个@RequireAdmin注解，标在需要管理权限的Controller方法上。拦截器统一检查当前登录用户的isAdmin字段，不是管理员直接返回403。

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireAdmin { }

@Component public class AdminInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (handler instanceof HandlerMethod) { HandlerMethod handlerMethod = (HandlerMethod) handler; RequireAdmin requireAdmin = handlerMethod.getMethodAnnotation(RequireAdmin.class); if (requireAdmin != null) { // 从token中解析用户信息，判断是否管理员 Long userId = getUserIdFromRequest(request); User user = userService.getById(userId); if (user == null || !"ROLE_ADMIN".equals(user.getRole())) { response.setStatus(403); return false; } } } return true; } }

写这个比用Spring Security的@PreAuthorize简单明了得多，答辩问起来你也能讲清楚权限控制的核心思想。

6. 让项目从"能跑"到"答辩优秀"的四个加分方向

最后这部分写给那些希望项目不只是"及格"，而是想在答辩时拿到优秀的人。这里我提供四个难度递增、但都基于SpringBoot生态的优化方向，每个方向用一段话说明价值，你自己选能hold住的来做。

6.1 用Redis缓存热销商品和商品详情

商品模块的热点数据用Redis缓存，把查询速度从几百毫秒降到几毫秒。你可以这么设计：

• 缓存key：product:detail:{id}
• 缓存策略：读的时候先查Redis，没命中再查MySQL，回填缓存并设置30分钟过期
• 数据一致性：后台管理员修改商品信息后，删除对应缓存key即可

如果你的搜索逻辑比较复杂，可以引入Elasticsearch做商品的全文检索。关键词搜"猫粮"，能同时匹配标题和副标题，还能按销量排序。这个方向有点重，但如果你平时的课程项目里用过ES，这绝对是答辩全场最亮眼的部分。

6.2 订单超时关闭的定时任务

上面我已经贴了完整代码，这里主要说它能帮你证明什么：

• 你会用SpringBoot的@Scheduled注解
• 你理解cron表达式的含义（比如0 */1 * * * ?代表每分钟触发一次）
• 你考虑了任务的可重入性和幂等性（超时关闭改成5的订单不会重复处理）
• 你还能答上"分布式环境下的定时任务幂等控制"这个深度问题

6.3 引入消息队列实现订单创建的异步解耦

如果你有多余精力，把SpringBoot整合ActiveMQ或RabbitMQ这个方向做一下。下单成功后发一条MQ消息，异步更新商品销量、发送短信通知。这样你的论文会多出来一个章节叫"基于消息队列的异步化设计"，在同期同学都在写纯CRUD的项目里，直接拉开差距。

但我要给你一个忠告：MQ一定不要为了用而用。你需要在论文里写清楚应用场景：下单的高峰期如果同步更新销量和发送通知，响应时间会变长；引入消息队列后，下单操作只做核心业务（建订单、扣库存），其他非核心操作用消息异步完成。这个逻辑链条完整，答辩才站得住。

6.4 库存扣减的防超卖处理

上面下单的代码里，我已经提到用原子SQL实现库存扣减。如果你想让这个点从"提到"变成"亮点"，可以加一个细节：

-- 乐观锁扣库存 UPDATE tb_product SET stock = stock - #{quantity}, version = version + 1 WHERE id = #{id} AND stock >= #{quantity}

配合数据库的乐观锁版本号字段，你在答辩时可以说："我用乐观锁+CAS机制解决了高并发下库存超卖问题，并且在压测中验证了库存数据的一致性。"这一句话，让评委知道你不是只会写增删改查，而是思考过并发场景。

把项目做完，别停留在"会跑"

最后以一个过来人的身份说几句。我知道毕业设计期间事情多，论文还有别的课要应付，时间宝贵。但我每次带学生都强调一个观点：毕设和你在课设里的"做完"标准不一样，课设是"能跑"，毕设是"能讲清楚为什么这么设计"。

这个项目本身不难，难的是你在做项目的时候有没有打磨细节、记录坑点、验证结论。你如果按照我上面的思路，把数据模型和订单流转搞清楚，把事务和缓存的细节都实现到位，把每个方案都能说出"为什么这么设计"，到时候评委老师问什么你都不慌。

我自己平时做项目还有一个习惯，就是每完成一个模块就写一段开发日志，记录当时遇到的问题和解决办法。这些东西最后整理一下，就是论文里的"系统实现与测试"章节，也是你答辩时的底气。希望这篇文章能帮你理清思路，把毕业设计做成一个真正拿得出手的作品。