企业官网建设流程全解析

每年一到毕设季节，就会有一大批做 Java 的同学对着“基于 SpringBoot 的生鲜团购平台”这种题目发呆。这个题目算是电商类毕设里的长青树，市面上能搜到的项目资源确实不少，但真正能完整跑通、能在答辩时把每个模块讲明白的，远没有想象中那么多。这篇博文我打算从选型思路、数据库设计、后端核心实现、前端搭建、请求链路、调试踩坑到论文写作，把基于 SpringBoot 的每日生鲜团购平台完整拆一遍，同时把我在帮人调试这类项目时反复遇到的问题一并交代清楚。不管你是想直接拿整套代码复现，还是打算自己从头写、拿别人的工程做二次改造，都建议耐心看完，很多坑提前知道能省下几天时间。

1. 生鲜团购这个题目为什么适合做毕设

1.1 业务闭环完整，复杂度恰到好处

先说说这个题目本身。生鲜团购平台从用户视角看，就是打开小程序或者网页，浏览当日推荐的水果蔬菜，看到某个商品正在开团，于是参一团凑个人数，等成团之后平台统一发货或自提。这个链条里包含了商品展示、购物车、下单、支付、团购状态流转、个人中心，以及后端管理员的商品上架、活动配置、订单处理，业务链路完整得像个迷你版电商平台。

对毕设来说，“完整”比“花哨”重要得多。一个只有增删改查的管理系统太单薄，答辩时没有可讲的东西；一个要做秒杀、千人千面推荐、分布式事务的系统又不现实。生鲜团购恰好卡在一个舒服的位置：既有足够的业务规则让你展示数据库设计能力和并发处理思路，又不会复杂到一个人做不完。

1.2 技术栈选型的理由和替代方案

题目里已经限定了 SpringBoot，这没什么好纠结的。真正需要想清楚的是配套技术怎么选，我的建议是这么一套组合：

为什么特意强调 SpringBoot 而不是继续用 SSM？因为 SpringBoot 的自动配置特性让你只需要关注业务代码，你别看只是少写了几个 XML 配置文件，对赶毕设时间线的同学来说，能省出整整一个周末。至于 MyBatis-Plus，它内置了 BaseMapper 的通用查询方法，像selectById、selectPage这种基础方法不用手写 SQL，代码量肉眼可见地减少。我见过有同学坚持用原生 MyBatis 为的是显得“底层”，结果一个商品列表的 XML 映射就写了六十多行，完全没有必要。

1.3 “每日生鲜”和“团购”该怎么结合

题目里的“每日”两个字，是可以做成系统亮点的。生鲜本身就是短保质期商品，今天没卖掉的面包明天就不新鲜了，所以业务上天然适合“每日上新 + 限时开团”的玩法。具体落到系统里，可以做成：每天早上管理员通过后台创建当日的团购活动，设置参团人数门槛、团购价、起止时间；用户端首页按时间展示“今日团购”；超过时间的活动自动下架。这一套逻辑既能用定时任务体现技术能力，又能让论文的需求分析章节有真实业务背景可写，一举两得。

2. 数据库设计是整套系统的地基

搞电商类系统的第一步永远是设计表，表结构没想清楚，后面写多少代码都要返工。生鲜团购平台的核心数据关系可以概括为：用户产生购物车和订单，订单挂在某个团单下；团单归属于某个团购活动；活动又指向某个商品；商品属于某个分类。下面按模块拆开讲。

2.1 用户、地址、购物车

用户表不用太复杂，但要注意表名字段用英文，别搞中文拼音。常用字段：id、username、password（存 BCrypt 加密后的密文）、phone、avatar、role（区分普通用户和管理员）、create_time。密码加密这件事千万别省，明文存密码在毕设里虽然不会真的被攻击，但论文里写“采用 BCrypt 加密存储用户密码”会显得你考虑过安全问题。

地址表和购物车表比较直白：

• address：id、user_id、receiver_name、receiver_phone、province、city、district、detail、is_default。默认地址用 0/1 标志，is_default=1的地址同时在其他地址设置默认时置为 0，这个逻辑在addressService里写一个事务方法处理更稳妥。
• cart：id、user_id、product_id、quantity。购物车表加个selected字段用来标记是否勾选，这也是多数商城前端的常见做法。

2.2 商品和分类的特殊字段设计

生鲜商品的表设计跟普通图书、数码产品不一样，因为多了“新鲜度”这个概念。我在对比了多个同类毕设项目的表结构之后，建议至少包含这些字段：

这里我特别想强调的是group_price不要直接放在商品表里，更好的设计是放在“团购活动表”中，因为同一个商品今天可能团购价 25.9，明天可能改成 29.9，商品的基准价和活动价分开，历史订单才能追溯。如果你把活动价覆盖在商品表里，就会出现老订单价格对不上活动记录的问题。

2.3 团购活动表和团单表的分离

很多人一开始会把团购设计成一张表，既存活动信息又存参团记录，结果越写越乱。正确的做法是拆两张表：

• group_activity（团购活动表）：id、product_id、group_price、required_people（成团需要的人数）、start_time、end_time、status（0-未开始 1-进行中 2-已结束）。这里保存的是“规则”。
• group_record（团单表）：id、activity_id、leader_id（开团人用户 id）、current_people（当前参团人数）、status（0-拼团中 1-已成团 2-团失败）、create_time、expire_time。这里保存的是“一次具体拼团实例”。

用生活化的方式理解：活动表好比是超市促销海报，写着“猪肉 25.9 元，5 人成团，活动到今晚 10 点”；团单表则是某个具体顾客发起的那个团，张三开了一团拉了两个朋友进来，人数到 5 就成团。两张表通过activity_id关联，逻辑非常清晰，论文画 E-R 图也方便。

为什么要单独记录expire_time而不是直接判断end_time？因为一个团不能在活动结束时就立刻失败，用户参团之后应该给一段“缓冲时间”，比如活动 22:00 结束，已存在的团到 23:00 才判定失败退款，这样用户体验更贴近真实场景。

2.4 订单模块的核心设计

订单相关是另一个需要重点拆解的地方。电商里成熟的做法是“订单主表 + 订单明细表”，主表记一笔订单的总体信息，明细表记这个订单买了哪些商品、各多少份、单价多少。明细表的存在让一个订单买多个商品成为可能，也让你的数据库设计显得专业。

orders表字段：id、order_no（唯一订单号）、user_id、group_record_id（关联团单，允许为空表示非团购订单）、total_amount、pay_amount、status、receiver_name、receiver_phone、receiver_address、pay_time、delivery_time、finish_time、cancel_time、create_time。

订单状态我推荐用字符串而不是数字，WAIT_PAY、PAID、GROUP_SUCCESS、DELIVERED、FINISHED、CANCELLED。虽然字符串存储占用略大，但可读性完胜，调试的时候不用对着状态码表查字典，答辩时也能直接讲清楚订单状态机的流转。

订单号千万别用数据库自增 id 直接展示，会暴露系统当天订单量，一般用时间戳加随机数：yyyyMMddHHmmss+ 6 位随机字符串，生成之后检查唯一性再入库。这一点写进论文也能体现你考虑过业务实际。

2.5 索引、逻辑删除和字符集

表设计完别忘了索引。单表数据量在毕设阶段不会很大，但索引能体现出你的设计意识。建议给orders表的user_id、group_record_id、order_no建索引，给product表的category_id建索引，给group_record表的activity_id、status建索引。有一个注意点：order_no建唯一索引，防止并发下生成重复订单号。

逻辑删除也是一个值得做的设计，用 MyBatis-Plus 的@TableLogic注解在实体类上标注，配合配置logic-delete-value: 1、logic-not-delete-value: 0，删除操作自动变成UPDATE，避免历史数据被物理清掉。这个功能在毕设里最大的好处是：你在论文测试章节可以写“对商品进行逻辑下线，历史订单查询不受影响”，听起来就很完整。

最后是字符集。建库语句统一用utf8mb4，因为utf8在 MySQL 里存不了 emoji 字符，虽然生鲜平台用 emoji 的场景不多，但万一商品详情里有人贴了个图标字符，查询时直接报错就麻烦了。注意把表的排序规则也设置一致，一般是utf8mb4_general_ci。

3. 后端核心模块实现思路

3.1 统一返回结果和全局异常处理

后端项目不管怎么写，第一件事一定是定好统一返回结构。我常用的结构是：

{ "code": 200, "message": "success", "data": { "records": [], "total": 0 } }

对应的 Java 类是一个泛型Result<T>：code、message、data，外加success()、error()等静态方法。这样所有 Controller 的返回值都长一个样，前端 axios 拦截器里根据code判断业务是否成功，逻辑统一。

全局异常处理用@RestControllerAdvice加@ExceptionHandler，把业务异常、参数异常分别映射到不同的code。为什么要做统一异常处理？因为不做的后果是：某个服务层不小心抛了个空指针，前端拿到的是 500 状态码加一大段堆栈信息，又丑又不安全。做了全局兜底之后，接口永远返回固定 JSON 结构，用户看到的永远是“系统繁忙，请稍后重试”，真实感立刻上一个层次。

3.2 认证拦截器和当前用户获取

登录状态我用 Sa-Token 来做，它比 Spring Security 简单太多，又比手写 JWT 工具类更省事。引入依赖后核心操作只有三行：

StpUtil.login(userId); // 登录 StpUtil.getLoginIdAsLong(); // 获取当前登录用户 id StpUtil.checkLogin(); // 校验是否登录

再配合 Sa-Token 提供的拦截器，只需要在配置类里声明排除登录校验的路径，比如/api/user/login、/api/user/register、/api/product/**（商品列表游客也能看）、/api/group_activity/list。其他接口一律要求登录。

有一个经验性的建议：不要在 Controller 里写死从 request 拿参数，而是自定义一个@CurrentUser注解配合 HandlerMethodArgumentResolver 解析当前登录用户，直接在 Controller 方法参数里注入LoginUser对象。第一次写这个代码会麻烦一点，但后面每个接口都爽，代码整体也显得规范。

3.3 商品列表、搜索和缓存

商品模块的接口要做的事：分页查商品列表，支持按分类筛选、按关键字模糊查询、按销量或时间排序。MyBatis-Plus 的Page<Product>配合 LambdaQueryWrapper 写起来非常快：

LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(StringUtils.isNotBlank(categoryId), Product::getCategoryId, categoryId) .like(StringUtils.isNotBlank(keyword), Product::getName, keyword) .eq(Product::getShelfStatus, 1) .orderByDesc(Product::getSales);

不过这里有个容易被忽略的点：既然引入了 Redis，就可以把首页轮播图和今日推荐商品缓存起来。redis 的 key 可以设计成product:hot，value 存储商品列表的 JSON 字符串，设置 30 分钟过期。每次查询时先查缓存，缓存没命中再查数据库并回填。这个缓存策略在答辩时很能加分，因为你不仅用了 Redis，还讲清楚了缓存更新策略是“定时过期 + 惰性加载”，而不是生硬地说“我用了 Redis”。

3.4 下单、锁库存和模拟支付

下单是整个系统的核心事务之一。流程大概是：前端传商品 id、数量、地址 id、是否团购；后端先校验商品上下架状态和库存，然后计算价格生成订单，最后扣减库存。关键代码用@Transactional包裹：

@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { Product product = productService.getById(dto.getProductId()); if (product == null || product.getShelfStatus() != 1) { throw new BizException("商品不存在或已下架"); } int updated = productMapper.reduceStock(dto.getProductId(), dto.getQuantity()); if (updated == 0) { throw new BizException("库存不足"); } // 生成订单号、计算金额、保存订单及明细 // 返回订单 id 和待支付金额，后续前端调模拟支付接口 }

reduceStock的 SQL 是关键，它的写法直接决定会不会超卖：

UPDATE product SET stock = stock - #{quantity}, sales = sales + #{quantity} WHERE id = #{productId} AND stock >= #{quantity}

用stock >= quantity作为更新条件，通过受影响行数判断是否扣减成功。这比先查库存再用 Java 判断安全得多，因为两条并发请求同时读到库存 10，都以为够卖，如果不加条件更新就会各扣各的导致库存变负数。虽然毕设系统并发量不大，但这种“乐观锁”写法成本低、效果好，值得写上。

至于支付，不要真的接支付宝或微信支付。原因很简单：个人开发者没有商户资质，而且答辩老师关注的是你的业务流程，不是你真的付了多少钱。做一个“模拟支付”接口，前端弹窗展示支付二维码图片或者一个“确认支付”按钮，后端把订单状态从WAIT_PAY改为PAID，必要时再生成一条支付流水记录，完全够用。

3.5 团购开团、参团和成团判定

拼团模块是生鲜团购平台区别于普通商城的地方，也是答辩时最可能被深挖的点。开团和参团其实是同一套逻辑，只是在人的维度上做区分：如果当前用户是第一个参加某次活动的人，就创建一个group_record，他就是leader_id=自己；如果他参加的是一个已存在的团，就在那个团的人数上加 1。

这里最危险的并发场景是：同一个团只剩最后一个名额，但 A、B 两个用户同时参团。如果都用“查一下当前人数小于需求人数再更新”，就可能出现两个人都通过校验，最终人数变成需求人数加一。

解决方案有两个，我推荐用数据库行级锁处理，更稳妥：

GroupRecord record = groupRecordMapper.selectByIdForUpdate(groupId); if (record.getCurrentPeople() >= record.getRequiredPeople()) { throw new BizException("来晚了，该团已满员"); } record.setCurrentPeople(record.getCurrentPeople() + 1); groupRecordMapper.updateById(record);

selectByIdForUpdate会在数据库层面锁住这一行，第二个事务必须等第一个事务提交之后才能读，这样就保证了同一时刻只有一个请求能更新人数。注意@Transactional必须包住这段逻辑，否则锁不会生效。另外要提醒一点：FOR UPDATE只对 InnoDB 生效，如果建表时用了 MyISAM 引擎，这个方案完全无效，所以建库阶段就统一用 InnoDB。

成团判定可以在人数更新之后立刻完成：如果current_people等于required_people，就把团单状态改为“已成团”，同时把该团下所有订单状态从PAID改成GROUP_SUCCESS，表示这些订单可以进入发货流程了。这一步如果量大可以异步化，毕设阶段同步执行完全没问题。

3.6 定时任务处理过期未成团的团

团购活动最怕有人开了一个团，直到活动结束都没凑满人，订单一直挂在“已支付”状态。处理方式是定时任务扫描：每天整点跑一次，找出所有status='进行中'且expire_time < now的团单，把状态改为“团失败”，再把关联订单状态改为“已取消”，模拟退款。

SpringBoot 里一个@Scheduled注解就能实现：

@Scheduled(cron = "0 0/30 * * * ?") public void handleExpiredGroups() { List<GroupRecord> expiredList = groupRecordMapper.selectList( new LambdaQueryWrapper<GroupRecord>() .eq(GroupRecord::getStatus, 0) .lt(GroupRecord::getExpireTime, new Date())); for (GroupRecord record : expiredList) { // 团单置为失败，关联订单自动取消 } }

记得在主启动类上加上@EnableScheduling，这个细节忘掉的话定时任务会一直不执行，排查半天才发现只是少了个注解。

3.7 管理后台接口和权限控制

管理员的接口和用户端要分开设计。管理端的功能有哪些？商品管理（增删改查、上下架）、分类管理、团购活动管理（新建活动、立即开始、提前结束）、订单管理（查订单、发货、查看退款申请）、用户管理（禁用用户、重置密码）。

权限控制用角色字段区分即可，管理员接口在拦截器里统一判断loginUser.role == 1。有一种情况要注意：用户端和管理端如果共用一个UserController，很容易出现用户能调管理员接口的漏洞，所以我建议接口路径按模块分清楚：/api/user/**是用户端接口，/api/admin/**是后台接口，再单独给/api/admin/**加一个管理员拦截器。别觉得重复，这就是安全设计。

4. 前端工程化搭建与页面交互

4.1 前端框架选择和项目结构

后端做得再漂亮，前端页面丑一样会被老师挑毛病。生鲜类系统相比图书管理系统有个天然优势，就是商品图片颜色鲜艳，页面做好了视觉效果很讨喜，所以前端不能太敷衍。我的建议是用 Vue 2 + Element UI + Vue Router + Vuex + Axios 的组合，如果用 Vue 3 就配 Element Plus，看你自己熟悉哪个。Vite 或 Webpack 都可以，不必纠结。

项目基本结构：

src/ api/ // 和每个接口对应的请求方法 assets/ // 静态图片资源 components/ // 商品卡片、团购倒计时、分页等组件 router/ // 路由配置 store/ // 登录状态、购物车状态 views/ home/ // 首页、商品详情、分类页 order/ // 购物车、订单确认、订单列表 user/ // 个人中心、地址管理、我的团购 admin/ // 后台管理页面 utils/request.js // axios 实例封装

4.2 用户端核心页面拆解

首页是用户端最复杂的页面。推荐结构：顶部搜索栏 + 分类导航 + 轮播图 + “今日团购”专区 + 普通商品瀑布流。轮播图数据可以由后端接口返回，图片用本地静态资源，这样不用依赖外链图床，毕设演示时不会因为网络问题挂掉。

商品详情页要体现两个操作入口，一个是“单独购买”，一个是“立即参团”，并且要展示团购的优惠力度，比如“原价 32.9 元，团购价 25.9 元，剩余 2 人成团”。团购人数进度条建议做成接口实时返回，而不是写死在页面上，否则两个用户同时看一个团的时候数据对不上。

购物车页面的核心逻辑是勾选状态管理和金额计算。我的建议是把购物车数据保存在 Vuex 里，所有增减数量、勾选操作都通过 mutation 触发，最后结算页一次性读取。

4.3 管理端页面搭建

管理端不需要做得多华丽，重点是信息完整、操作顺手。几个关键页面：

1. Dashboard 统计面板：显示今日订单数、今日销售额、待发货订单数、当前进行中的团购数，用一个折线图展示最近七天的订单趋势。
2. 商品管理表格：支持搜索、分类筛选，每个商品行有“上架/下架”按钮，编辑弹窗可以修改包括生产日期、保质期在内的所有字段。
3. 团购活动管理：新建活动时选择商品、填团购价、参团人数、起止时间；活动列表展示当前状态，支持人工结束活动。
4. 订单管理：订单状态筛选，发货按钮修改订单为配送中。

4.4 axios 拦截器和跨域处理

axios 封装是前后端联调的命门。在request.js里做两件事：请求拦截器带上 token，响应拦截器根据code统一处理报错和登录跳转。

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = token; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { Message.error(res.message); if (res.code === 401) { router.push('/login'); } return Promise.reject(new Error(res.message)); } return res; }, error => { Message.error('网络异常，请稍后重试'); return Promise.reject(error); } );

跨域问题有两种解法。简单粗暴的：在后端写一个CorsConfig配置类允许所有跨域请求；规范一点的：前端用 Vite 的proxy或 Vue CLI 的devServer.proxy把/api代理到 8080 端口。建议用前端代理方案，因为最终部署到服务器时前后端可以放在同一个域下面，不需要跨域，开发的时候也能避开浏览器限制。

5. 一次“参团购买”的完整请求链路

这一节把整套系统的运行过程串起来讲，你会发现前面设计的每一个模块在真实请求里是怎么协作的。

5.1 从首页点击到订单创建

假设用户小王打开首页，看到“今日团购”区域有一个番茄团购活动，点击进去。前端路由跳转到活动详情页，页面加载时发出两个请求：查活动详情和查当前活动下所有进行中的团单列表。后端返回后，页面上显示一个团单列表，包含开团人头像、当前人数和目标人数。

小王选了其中一个团，点击“立即参团”。前端调POST /api/group/join，请求体传活动 id、团单 id、购买数量。

后端接口处理顺序：

1. 拦截器校验登录状态，解析当前用户。
2. 查询活动，校验是否处于进行中，当前时间是否在start_time和end_time之间。
3. 查团单，用FOR UPDATE锁行，校验current_people是否小于required_people。
4. 校验商品库存。
5. 进入事务：创建订单和订单明细，状态为PAID（模拟支付，一步到位），扣减库存。
6. 更新团单current_people + 1。
7. 判断是否成团：人数满了则更新团单状态为GROUP_SUCCESS，同时把团单下所有订单状态更新为GROUP_SUCCESS。
8. 返回订单 id 给前端。

5.2 链路中每个模块的职责划分

从上面这个流程能看到，一次参团请求的完整链条覆盖了：认证模块（拦截器校验）、缓存模块（活动数据可能走 Redis）、业务模块（订单服务和团购服务）、事务控制（@Transactional）、并发控制（行锁）。答辩时如果老师问“你的系统遇到了什么问题”，这就是现成的素材：你设计了一个完整的生鲜团购业务场景，并且通过数据库锁解决了并发参团的超员风险。

5.3 管理员发货和用户确认收货

订单状态到GROUP_SUCCESS之后，管理员在后台看到待发货列表，点击发货，订单状态变成DELIVERED。用户端“我的订单”里能看到物流状态（毕设里写个虚拟的“已配送”文案即可）。用户确认收货后订单变成FINISHED，此时一个完整的业务周期结束。

这里有一个可选的加分项：订单完成后允许用户对商品进行评价，评价表对应一个商品，用户只能评价自己已完成的订单里的商品。这个功能不大，但能展示你在订单状态机上做了完善的限制逻辑，建议时间充裕就加上。

6. 实操踩坑记录与排错过程

6.1 Maven 依赖版本冲突

先讲一个最常见的坑。用 MyBatis-Plus 3.5.x 时，有人直接复制网上教程的依赖版本，结果和 SpringBoot 2.7 配合使用时出现了Invalid bound statement错误，所有 Mapper 方法都报找不到。这种问题通常不是代码写错了，而是 MyBatis-Plus 版本太新或者和 SpringBoot 版本不对付。

解决思路：检查启动类是否加了@MapperScan，检查mapper-locations配置是否指向 XML 目录。如果两者都没问题，就换掉 MyBatis-Plus 版本，改为mybatis-plus-boot-starter3.5.3 搭配 SpringBoot 2.7.x，这个组合我实测过是稳的。

6.2 数据库时区差八个小时

生鲜平台大量依赖活动起止时间，如果数据库连接串没配置时区，出现的问题非常隐蔽：代码里new Date()拿到的是北京时间，但 MySQL 的 TIMESTAMP 存储后查询出来差了 8 小时，导致“今日团购”到点不结束、购买时间记录错乱。

解决方法是 JDBC 连接串统一加上参数：

jdbc:mysql://localhost:3306/fresh_group?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

同时可以在数据库连接参数里设置useSSL=false，避免本地连接时出现 SSL 警告刷屏。这类问题排查起来特别折磨人，因为它不报错，只是数据看起来不对，所以从一开始建库时就统一时区能省很多事。

6.3 前后端分离后的图片 404

前端页面做完了，商品图片却显示不出来。这大概率是后端没有配置静态资源映射。SpringBoot 默认只映射classpath:/static/目录，如果你把图片上传到了项目外的自定义目录，比如D:/upload/，就必须在配置类里手动加映射：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:D:/upload/"); } }

访问路径http://localhost:8080/upload/xxx.jpg就会对应到磁盘目录下的图片。这个配置在本地开发时很不起眼，一到部署阶段就成拦路虎，提前写好可以避免交付前夜手忙脚乱。

6.4 初始化测试数据不足

还有一个比代码问题更隐蔽的项目问题：演示效果不好。很多现成代码仓库里数据库只有三五条测试数据，首页空荡荡的，团购活动列表也是空的，演示截图拍出来完全不像一个“每日生鲜平台”。

我的经验是：初始化数据一定要舍得花时间造。分类至少要 6 个以上（蔬菜、水果、肉禽蛋奶、水产、粮油调味、熟食面点），每个分类下配 8-12 个商品，商品图片统一找无版权素材，库存字段设置成真实的数字，生产日期设置成“近三天”，保质期符合商品属性。团购活动要保证每天都有 3-5 个在开团，每个团的当前人数最好错落分布，有的快满员、有的刚开团。这样演示的时候截图好看，答辩 PPT 也有素材。

6.5 下载的现成代码怎么自查

如果你拿到的是别人整理好的完整项目，别急着部署后就交差。我建议按这个顺序自查一遍：

• 修改数据库连接配置，改成自己的本地账号密码。
• 清除数据库所有业务数据，重新执行初始化 SQL，保证数据是自己可控的。
• 全局搜索默认密码、默认密钥，全部替换掉。
• 启动后端，用 Postman 或 Apifox 逐个测试核心接口，确认每个接口都通。
• 启动前端，按“注册—浏览商品—加购物车—下单—参团—支付—后台发货”这条路走一遍。

这套流程看起来很基础，但确实解决过很多人的答辩翻车问题。遇到过一位同学拿到的项目里用户表存的是明文密码，结果自己都不知道，答辩时老师问了一句“你的用户密码安全怎么保障”，当场愣住。提前自查一遍就能避免这种局面。

7. 说明文档和论文怎么写才能过审

7.1 论文的通用结构和每章重点

毕设论文的核心是让答辩老师快速相信两件事：你真的理解了这个系统，并且系统真的是你做的。结构上一般这样安排：

• 绪论：写生鲜电商行业背景和社区团购发展趋势，但别写得太虚太多，聚焦在一页以内。
• 相关技术介绍：把 SpringBoot、MyBatis-Plus、Redis、Vue 分别介绍，注意每项技术写清楚“我为什么用它”，而不是复制一段概念。
• 需求分析：写系统角色、功能需求、业务流程。这里一定要画出用例图，并配合文字描述，比如“用户可以发起拼团、邀请好友拼团、查看拼团进度”。
• 系统设计：架构图、功能模块划分、数据库设计（附表结构说明），这是整个论文的骨架。
• 系统实现：贴关键功能的前端页面截图和核心后端代码，注意代码不要整段贴，挑有代表性的接口，比如拼团接口、下单事务接口。
• 系统测试：列出测试环境、功能测试用例表格和测试结果，附上重要页面截图。
• 总结与展望：写自己的收获和不足，并说后续可以加什么功能。

7.2 图和表比文字更能拿分

答辩老师看论文的速度通常很快，文字写得多不如图画得清楚。把用例图、系统架构图、订单状态机图、数据库 E-R 图这几张图画好，论文的专业度立刻提升。推荐用 Draw.io 或者 ProcessOn 画，导出 PNG 插入文档。

画数据库 E-R 图时，传统画法可能会把所有字段都画上去，但论文篇幅有限，我建议每个实体只画关键字段和主外键关系，其他字段用表格说明补充。这样图不会变成一团乱麻，老师也能一眼看懂表与表之间的关联。

7.3 测试章节怎么避免流水账

很多人的测试表就是一行行“输入正确数据，得到预期结果，测试通过”，这种表格填得再满也是流水账。真正有效的测试表要包含边界情况和异常场景，比如：

有异常场景、有设计依据，测试章节才真正有意义，答辩也更有底气。

7.4 答辩环节的心理预期

提前准备几个必问问题的答案：为什么用 Redis、为什么用 SpringBoot 而不是 SSM、MyBatis-Plus 和 MyBatis 的区别、团购超员怎么解决、数据一致性和事务怎么保证。这些问题在正文里其实都覆盖到了，关键在于你能不能用口语化、简洁的方式讲出来，而不是照着论文念。错位竞争的一点是：如果你在系统里加了某个“非必修”的功能，比如评价功能、定时任务，答辩时主动提出来讲，效果多半不错，因为它证明你做了超出基础要求的独立思考。

最后再分享一点实操体会

给准备接手这套系统的同学一个非常具体建议：别让项目停留在“能跑”就行。找一天时间，把自己当成普通用户，完整走一遍“从注册到参团再到后台发货”的全流程，注意每个页面的跳转逻辑、按钮文案、空状态展示。很多项目功能全做了，但用户体验细节一塌糊涂，比如商品库存为零时按钮还能点、团购人数满了页面不更新数据，这类问题一定会被老师截图提问。提前把这些体验细节打磨好，答辩时你会明显比同组同学更从容。

万一中途遇到调试不出来的问题，最好的排查路径不是到处复制网上的报错信息，而是顺着请求一条条看：前端控制台的网络请求有没有发出去、接口返回了什么、后端日志最后一条是什么、数据库里的状态字段变成什么。只要把这条链路走通，绝大多数问题都能自己定位。做毕设这件事，最后收获的不只是一份代码和一篇论文，还有这种排查问题的思路，它才是以后工作里更值钱的东西。