知道吗，很多人第一眼看到“基于Spring Boot的商场多功能折扣系统”这个毕设题目时，心里想的是：这不就一个打折功能嘛，商品表、订单表建一建，结算的时候打个折，完事了。但真动手之后，库存、订单状态、优惠叠加、并发扣减这些环节会一个个跳出来教做人。我做Java方向的项目辅导也有好些年头了，经手过的Spring Boot毕设没有一百也有八十，这个题目是我个人认为最适合用来撑起一场完整答辩的选题之一——业务足够接地气，技术栈覆盖广，而且很难做出“一眼假”的空壳项目。这篇就把整个项目从业务到技术，从源码到论文，从远程调试到答辩准备彻底拆一遍，正在为选题发愁或者已经拿到这套源码的同学都能用得上。
1. 先吃透业务：商场折扣系统到底在解决什么问题
很多同学拿到题目就开始建表写代码，这是典型的顺序错误。毕设答辩时老师问的第一句话往往是“你这个系统解决的是什么问题”，如果连业务都讲不清楚，代码写得再漂亮也白搭。所以第一步不是写代码，是把这个商场的折扣业务捋明白。
1.1 “多功能”这三个字的真实含义
“多功能折扣”不是一个噱头，它对应的是商场运营中的几类常见促销手段。我在需求分析阶段通常会把它们拆成四类，和系统里的模块一一对应。
第一类是会员折扣。用户注册后会有会员等级，比如普通会员95折、银卡会员9折、金卡会员85折，结账时按等级自动打折。这属于最基础的折扣，和用户表、会员等级表挂钩。
第二类是满减活动。满100减10、满300减50，这是商场最常见的促销方式。它需要配置阈值和减免金额，还要考虑活动的时间范围、适用商品范围。
第三类是优惠券。包括满减券、折扣券、无门槛券等，用户在领券中心领取后，结算时符合条件的自动匹配。这里涉及券的库存、每人限领张数、有效期等细节。
第四类是限时促销。比如“今日特价”、“秒杀专区”，活动时间内某个商品直接改价或者打特定折扣，活动结束后恢复原价。
“多功能”这三个字，落到实处就是这四类规则可以同时存在、互相组合。这意味着系统里必须有一个能统一处理各种折扣规则的模块，而不是在每个页面里硬编码几个if else。这也是这个题目在技术上最值得展开讲的地方。
1.2 从一次完整购买流程看系统全貌
用一条用户购买链路串起整个系统，你会看得更清楚。
用户在商城前台注册登录，浏览商品分类和商品详情，把商品加入购物车。进入结算页后，系统要做的事情远比想象中多：读取用户的会员等级计算会员折扣，遍历用户手头可用的优惠券判断是否满足使用门槛，检查当前商品是否在限时促销活动中，然后按照系统设定好的顺序叠加这些优惠，算出最终应付金额。生成订单后，还要扣减对应商品的库存，标记优惠券为已使用状态，生成订单明细和优惠明细供后续查询。
后台管理端则是另一条线：管理员维护商品分类、商品上下架、库存管理，配置各种折扣规则和优惠券活动，查看订单列表和销售统计。前后台加在一起，才能构成一个完整的“商场多功能折扣系统”。
把流程图理顺之后你会发现，这个系统天然包含商品管理、会员管理、折扣管理、订单管理、数据统计五个大模块，每个模块都能在论文中占一个章节，工作量是实实在在的，而且相互之间逻辑闭环。
1.3 为什么这门生意特别适合做毕设
我这些年见过太多选题翻车的案例：有人选了“基于SSH的图书管理系统”，技术老旧，答辩时被追问框架原理直接卡壳；有人选了“基于微服务的秒杀系统”，光环境搭建就折腾了一个月，到最后单体页面都没做完。这个折扣系统的好处在于难度梯度设计得刚刚好。
从业务角度看，它贴近真实场景，需求分析有东西可写，不像是编出来的；从技术角度看，Spring Boot + MyBatis Plus + MySQL这套组合能覆盖CRUD、复杂查询、事务、并发、权限等核心知识点，又不会难到做不完；从工作量看，前后台十多个页面加十几张表，配合完整的论文和PPT，一份标准毕设的体量正好。
最关键的是，答辩时有“亮点”可讲。满减叠加逻辑怎么设计、库存扣减怎么防超卖、优惠券并发领取怎么控制，随便一个问题都能展开聊五分钟，这就是好题目的价值。
2. Spring Boot项目骨架：技术栈选择与版本雷区
题目既然指定了Spring Boot，技术选型就没有太多悬念。但“选对了框架”和“用对了版本”是两回事，很多同学的项目跑不起来，十有八九是栽在版本和依赖的兼容问题上。
2.1 为什么非Spring Boot不可
先给还没想明白的同学解释一下。Spring Boot最核心的价值是自动配置，它默认帮你完成了大量以往Spring MVC项目中需要手工处理的配置工作，比如数据源、事务管理器、JSON转换、静态资源映射等。内嵌的Tomcat容器让你不用再单独部署WAR包到外部Tomcat，一个java -jar命令就能启动整个项目。
对于毕设场景来说，Spring Boot还意味着社区教程密度极高。遇到问题随便一搜就是解决方案，这对时间宝贵的大四学生来说是实打实的优势。另一方面，Spring Boot已经是Java后端岗位的入门标配，写在简历上不会被面试官质疑，毕业设计和就业需求能完美对接。
2.2 版本选型：Spring Boot 2.7还是3.x
这里要重点说说版本问题，因为“springboot版本太高”这个词条在搜索里出现频率一直很高。我见过不少同学直接在官网拉最新版Spring Boot 3.x，结果导入源码后一连串报错，根本原因是Spring Boot 3.0起，不允许@Autowired直接注入同一个类型存在的多个实例时报错，更关键的是包名从javax迁移到了jakarta。
| 对比项 | Spring Boot 2.7.x | Spring Boot 3.x |
|---|---|---|
| JDK版本要求 | JDK 8及以上 | JDK 17及以上 |
| 命名空间 | javax.servlet、javax.validation | jakarta.servlet、jakarta.validation |
| MyBatis Plus兼容性 | 3.5.x全兼容 | 需mysql-connector-j等单独适配 |
| 学习资源数量 | 大量，基本不会踩坑 | 相对较少，报错不好搜 |
我的建议很明确：除非你的电脑确认装了JDK 17以上，且愿意处理各种第三方库的适配问题，否则毕设老老实实选Spring Boot 2.7.x。它足够稳定，MyBatis Plus、PageHelper、Redis等常用组件的兼容性文档都非常成熟。拿到源码后第一步就检查pom.xml里的spring-boot-starter-parent版本号，确认是2.x再继续跑。
2.3 目录结构、统一返回与异常处理
一个好的项目结构应该让人一眼看出分层思想。标准做法是:
com.example.discount ├── controller // 接口层，接收参数、返回结果 ├── service // 业务逻辑层，处理核心规则 │ └── impl ├── mapper // MyBatis Plus的数据访问接口 ├── entity // 数据库表对应的实体类 ├── dto // 入参对象，承载页面提交的数据 ├── vo // 出参对象，返回给前端展示的数据 ├── config // 配置类：跨域、拦截器、MyBatis Plus分页插件 ├── common // 通用类：统一返回结果、异常、常量 └── utils // 工具类这里有两个细节容易被忽略，但答辩时很加分。
第一个是统一返回结果类。所有Controller接口都返回R.success(data)或R.error(msg)这种格式，前端拿到固定结构的JSON再做处理。它的好处是接口风格一致，前端不用为每个接口单独判断返回格式。
第二个是全局异常处理。用一个@RestControllerAdvice注解的类统一拦截业务异常和系统异常，避免代码里到处写try catch。这样既保证了异常信息不泄露给用户，又能在日志中完整记录错误堆栈。
2.4 数据库设计：先讲清楚七张核心表
数据库设计是论文里篇幅最大、答辩最容易被追问的部分。折扣系统的核心表我在前文已经提过，这里再系统整理一遍。
| 表名 | 作用 | 关键字段 |
|---|---|---|
| user | 前台用户/会员 | id, username, password, phone, member_level, points |
| product | 商品 | id, name, description, price, stock, category_id, status |
| discount_rule | 折扣规则 | id, rule_type, rule_name, threshold_amount, discount_amount, discount_rate, start_time, end_time, stackable, priority |
| coupon | 优惠券模板 | id, coupon_name, type, face_value, min_threshold, total_count, received_count, start_time, end_time |
| user_coupon | 用户已领优惠券 | id, user_id, coupon_id, status, receive_time, use_time |
| orders | 订单主表 | id, user_id, total_amount, discount_amount, pay_amount, status, create_time |
| order_item | 订单商品明细 | id, order_id, product_id, product_name, price, quantity, subtotal |
另外还需要一张order_discount_detail表，记录每个订单用了哪几条折扣规则、每项优惠了多少钱。这张表很多毕设不会建，但它是整个折扣系统“可解释性”的关键。用户查看订单详情时，每一分钱的优惠都能追溯来源，答辩时把这层设计讲出来，含金量直接提升一个档次。
3. 折扣引擎：优惠规则的数据模型与计算顺序
如果说商品、订单是系统的骨架，那折扣引擎就是系统的灵魂。这块也是答辩老师最喜欢深挖的部分：你满减和会员折扣怎么叠加？冲突怎么处理？精度怎么保证？
3.1 规则承载：一张discount_rule表怎么设计
第一种思路是一张表装所有规则。用rule_type字段区分满减、折扣、会员折扣，再用threshold_amount存满减门槛、discount_rate存折扣率、stackable标识是否可叠加。这种设计的优势是新增规则类型时不用改表结构，只是不同类型规则用到的字段不一样，会有空字段存在。
第二种思路是每种规则单独建表，比如full_reduction_rule、percent_discount_rule、member_discount_config。查询逻辑清晰，但代码量增加不少。
我实际带项目时更推荐第一种。原因很简单：毕设的规则类型固定就那几类，一张表维护方便，而且写论文的时候“规则抽象设计”更容易讲清楚。表设计如下：
CREATE TABLE discount_rule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, rule_type VARCHAR(50) NOT NULL COMMENT 'FULL_REDUCTION/PERCENT_DISCOUNT/MEMBER_DISCOUNT', rule_name VARCHAR(100) NOT NULL, threshold_amount DECIMAL(10,2) DEFAULT NULL COMMENT '满减门槛', discount_amount DECIMAL(10,2) DEFAULT NULL COMMENT '减免金额', discount_rate DECIMAL(4,2) DEFAULT NULL COMMENT '折扣率，0.85表示85折', member_level INT DEFAULT NULL COMMENT '适用的会员等级', start_time DATETIME DEFAULT NULL, end_time DATETIME DEFAULT NULL, stackable TINYINT DEFAULT 1 COMMENT '是否可与其他规则叠加', priority INT DEFAULT 0 COMMENT '优先级，值越大越先计算', status TINYINT DEFAULT 1 );3.2 优惠叠加：互斥、优先级的残酷现实
折扣系统里最头疼的不是单条规则怎么写，而是多条规则同时命中时怎么算。这里必须定清楚两条原则。
原则一：明确哪些规则可叠加，哪些互斥。一个合理的业务设定是：会员折扣与满减可叠加；优惠券与会员折扣可叠加；限时促销价不与其他任何规则叠加（因为已经是特价了）。这个设定在discount_rule表里用stackable字段控制。
原则二：确定计算顺序。我常用的规则顺序是：先算限时促销价，再算会员折扣，最后匹配满减和优惠券。顺序不同，最终价格完全不同。举例说明：一件商品200元，用户是9折会员，手上有满100减20的优惠券。按“先会员折扣再满减”的顺序，价格是200×0.9-20=160元；按“先满减再会员折扣”的顺序，价格是（200-20）×0.9=162元。两种结果都能自圆其说，但系统里必须只能有一种口径，而且要在订单详情里展示清算过程。
3.3 计算器代码：策略模式与BigDecimal
实际编码时，规则计算用策略模式最合适。先定义一个统一接口：
public interface DiscountRule { String getRuleType(); boolean isApplicable(OrderContext context); BigDecimal compute(OrderContext context); }满减规则和折扣规则分别实现这个接口：
public class FullReductionRule implements DiscountRule { @Override public String getRuleType() { return "FULL_REDUCTION"; } @Override public boolean isApplicable(OrderContext context) { return context.getCurrentAmount().compareTo(new BigDecimal("100")) >= 0; } @Override public BigDecimal compute(OrderContext context) { return new BigDecimal("20"); // 满100减20 } }public class PercentDiscountRule implements DiscountRule { @Override public String getRuleType() { return "PERCENT_DISCOUNT"; } @Override public boolean isApplicable(OrderContext context) { return context.getMemberLevel() >= 1; } @Override public BigDecimal compute(OrderContext context) { BigDecimal current = context.getCurrentAmount(); BigDecimal discount = current.multiply(new BigDecimal("0.10")); return discount.setScale(2, RoundingMode.HALF_UP); } }核心计算器把所有命中的规则按优先级排序后依次执行：
public class DiscountCalculator { private final List<DiscountRule> rules; public OrderContext calculate(OrderContext context) { List<DiscountRule> matched = rules.stream() .filter(rule -> rule.isApplicable(context)) .sorted(Comparator.comparingInt(rule -> rule.getPriority())) .collect(Collectors.toList()); for (DiscountRule rule : matched) { BigDecimal discount = rule.compute(context); context.addDiscount(discount); } BigDecimal finalAmount = context.getOriginalAmount() .subtract(context.getTotalDiscount()); context.setFinalAmount(finalAmount); return context; } }代码里必须使用BigDecimal进行金额计算，不能用double或float。原因很简单：二进制浮点数无法精确表示小数，0.1+0.2这样的运算都会产生误差，金额一旦出现精度问题，订单数据就会变得不可信。这一点答辩时一定要主动讲出来，属于可预期的加分项。
3.4 给答辩准备的“折扣口径”话术
答辩时老师很可能会问：“你这个系统里满减和折扣同时存在时，用户实际支付金额怎么算？”
标准话术可以这样组织：系统将所有可用规则通过策略模式统一管理，每一条规则对应一个实现类。计算时先过滤出用户当前命中的所有规则，再根据业务设定好的优先级和叠加开关依次计算。每一步计算的优惠金额都记录到订单优惠明细表中，用户可以查看每一分钱的来源。这样的设计既保证了计算结果的唯一性，也让整个优惠过程透明可追溯。
这套话术同时包含了技术方案、业务规则和数据落点，是一个完整且有深度的回答。
4. 商品、订单、库存联动：并发安全与数据一致性
商品浏览、下单、库存扣减这三件事看起来是独立的，但实际系统里它们是强耦合的。这个部分是整个后端最考验工程能力的地方，也是“高并发”这个词唯一能在毕设里落地的场景。
4.1 库存扣减：下单锁库存还是支付扣库存
先明确一个基本问题：用户点击“提交订单”后，库存要不要立刻扣掉？两种方案各有优劣。
方案一是下单减库存。用户提交订单时立即扣减库存，订单取消或超时未支付时再回补。它的优点是能保证有库存的商品一定能下单成功；缺点是用户可能下单后不支付，导致一部分库存被占用却卖不出去，需要定时任务释放超时订单。
方案二是支付减库存。用户下单时不扣库存，支付成功后真正扣减。它的优势是没有超时释放的麻烦；缺点是并发高时可能出现用户下单成功但支付时库存已经没了的情况，体验较差。
商城场景里我建议用方案一，也就是“下单锁库存、超时回补”。理由是这个逻辑更容易在答辩时讲清楚，而且实现方案一需要引入定时任务，这也是一个可以写进论文的技术点。
4.2 订单明细与优惠明细的分离设计
前面提到订单表设计时，我把order_item和order_discount_detail拆成了两张表，这里解释一下为什么。
order_item记录每个商品的快照信息，包括商品名称、购买单价、数量、小计。商品名称和价格必须存快照，不能通过订单表去关联查询商品表，因为商品可能改了名、调了价，甚至下了架，否则历史订单数据就全乱了。
order_discount_detail记录这个订单每一笔优惠的明细，关联到具体的规则ID或优惠券ID，保存优惠类型和金额。用户查询订单详情时，页面能展示“商品小计200元，会员折扣-20元，满减-10元，实付170元”这种完整信息。
这个设计对答辩的意义在于：当老师问“你的订单表里total_amount、discount_amount、pay_amount这些字段怎么保证一致”时，你可以借机展示你理解了订单数据流转的完整链路。
4.3 乐观锁方案与超卖问题
高并发秒杀场景下，库存扣减最怕的是超卖——100件商品卖出了120件。如果扣库存的SQL写成这样：
UPDATE inventory SET stock = stock - 1 WHERE product_id = ?在并发请求同时到达时，会出现多个线程同时读到stock=100，然后都执行减1，最终库存只减少了1次，却生成了多笔订单。
正确做法是加乐观锁控制。在表里增加version字段，扣库存时带上版本号条件：
UPDATE inventory SET stock = stock - #{quantity}, version = version + 1 WHERE product_id = #{productId} AND stock >= #{quantity} AND version = #{version}如果更新影响行数为0，说明库存不足或版本已变化，此时抛出业务异常，让用户重新选择商品或放弃购买。对应Java代码：
int rows = inventoryMapper.reduceStock(productId, quantity, version); if (rows == 0) { throw new BizException("库存不足或商品状态已变化，请刷新后重试"); }这里stock >= #{quantity}是防止库存为负的关键条件，在极端并发下即使丢失更新，也过不了这个约束。答辩时可以说：这个方案在单体应用的并发场景下已经足够，如果业务量再大，可以引入Redis分布式锁或消息队列排队，但那些超出了毕设的合理范围。
5. 全套交付物：源码、文档、答辩一套怎么配齐
题目里写的是“全套源码+文档”，所以这一节把除了代码之外需要准备的东西一次说全。很多同学以为毕设交一个能跑的系统和一篇论文就完事了，实际上开题报告、外文翻译、中期检查、答辩PPT每一步都有坑。
5.1 源码部分如何组织才像“丰富项目”
所谓“丰富项目”，不能只是一个能增删改查的壳。我建议在完整功能之外，额外添加这几样东西提升项目成色。
一是完善的公共模块。统一的返回结果类R、全局异常处理器、参数校验、跨域配置、分页插件配置，这些统写清楚，代码质量一眼就能看出来。
二是登录与权限控制。前台用户用JWT做登录认证，后台管理员用拦截器校验登录状态。JWT无状态、不依赖Session，这本身就是一个独立的技术点，论文和答辩都能展开。
三是数据统计页面。后台提供“今日订单数”“销售额趋势”“折扣让利金额”这类统计图表，用MyBatis Plus的聚合查询实现。这个功能工作量不大，但能让项目从“管理系统”进阶为“运营系统”，在演示环节非常出彩。
四是详细的项目README。写清楚技术栈版本、数据库初始化脚本、启动步骤、默认账号密码。这既是给评委看的，也是给你自己的，提前写好能省下大量时间。
5.2 论文写作的七个核心章节与图表清单
毕设论文的通用结构是固定的，但每章的写作重心要根据折扣系统的特点来安排。我建议按以下框架写：
| 章节 | 核心内容 | 必备图表 |
|---|---|---|
| 绪论 | 研究背景、国内外现状、研究内容 | 技术路线图 |
| 需求分析 | 功能需求、非功能需求、用例分析 | 用例图、用例说明表 |
| 系统设计 | 架构设计、功能模块设计、数据库设计 | 系统架构图、功能结构图、ER图、表结构说明 |
| 系统实现 | 前后台功能实现、折扣引擎实现、并发处理 | 核心代码片段、运行截图 |
| 系统测试 | 测试环境、测试用例、测试结果分析 | 测试用例表、测试结果表 |
这里特别强调，ER图和用例图是论文查重之外最容易被评委细看的部分。不需要画得多漂亮，但实体之间的关系一定要对，比如user和orders是一对多、orders和order_item是一对多、user和user_coupon是一个用户可持有多张券。
5.3 答辩高频问题与演示脚本
答辩时间通常只有10到15分钟，演示环节必须提前彩排。我的建议是准备一个“一条龙”演示脚本：先展示前台商城首页和商品分类，选择一件商品加购；然后到结算页，切换不同会员账号演示价格变化；再打开后台配置一个满减活动，回到前台刷新结算页看效果；最后打开订单列表和数据统计页收尾。整个演示流程控制在8分钟以内，每个步骤之间用一句业务说明衔接。
答辩高频问题我也整理了一份，提前准备绝对不吃亏：
- 为什么选择Spring Boot而不是SSM？
- 折扣计算的具体流程是什么？规则冲突怎么解决？
- 金额计算为什么用BigDecimal？
- 库存扣减如何防止超卖？
- 数据库表为什么这么设计？有哪些字段是冗余的？
- 系统最大的瓶颈在哪？如果要优化怎么做？
这些问题在本文前面几节都已经给出了回答思路，建议用自己的话重新组织一遍写成答辩稿，不要死记硬背。
6. 远程调试、讲解和定制：怎么把这些服务用到位
标题里提到了远程调试、讲解和定制这三项配套服务，很多同学不知道它们各自的用途和使用时机，我就直接说实操层面的经验。
6.1 远程调试的三种姿势与环境检查清单
我接触过的“远程调试”主要有三种形态。第一种是远程桌面会议式，用远程控制软件让对方直接操作你的电脑，或者你操作对方电脑帮忙排查问题，适用于环境配置报错、项目跑不起来的场景。第二种是代码仓库式，把源码推到Gitee或GitHub，对方拉取后在本地跑，配合视频通话逐模块讲解，这种方式最接近真实开发协作。第三种是IDE远程调试，通过Java的远程调试端口（JDWP协议）连接运行中的进程，主要用于追踪线上或本地无法复现的逻辑问题，对毕设来说用得不多。
不管用哪种方式，开始之前先把下面这份环境清单检查一遍，能省掉80%的调试时间：
- JDK版本：确认是8还是17，和pom里的配置对上
- MySQL版本：5.7还是8.0，驱动是否匹配，
useSSL=false这类参数是否配置 - Redis是否安装并启动，或确定项目不依赖Redis
- 数据库初始化脚本是否执行成功，字符集是不是utf8mb4
- 端口是否被占用：Spring Boot默认8080
- 前端Node版本（如果是前后端分离项目）
6.2 定制功能：改什么、怎么改、改完怎么测
“定制”在毕设场景里通常是两类需求。一类是界面定制，比如把系统名称换成自己学校、把默认Logo换成自己的、颜色主题调整。这类改动只需要搜索替换前端资源里的项目名称和图片，风险极低，自己动手就行。
另一类是功能定制，比如“我想加一个积分兑换功能”“我想把满减改成第二件半价”“我想加一个拼团模块”。这类定制绝对不能上来就改代码，要先画出改动涉及的表结构和业务流程，评估影响范围。我的经验公式是：先理清新功能依赖哪些已有数据，再明确新增字段的表，接着写清业务规则，最后才动手写代码。改完以后必须把主流程重新跑一遍，尤其是订单结算和折扣计算相关代码，牵一发动全身，光测试新功能而不回归旧功能是必踩的坑。
6.3 拿到源码后的一周消化计划
最后这条是给所有想用这套源码又担心答辩被识破的同学的。拿到任何一套现成源码后，我都会建议用一周时间把它真正“消化”成自己的东西。具体节奏如下。
第一天：搭建环境，把项目跑起来。遇到报错自己先排查，实在解决不了再问。
第二天：走一遍完整业务流程，同时用调试器逐行打断点，搞清楚一次下单请求从Controller到Service到Mapper的完整调用链。
第三天：对着数据库ER图和表结构，把每张表的作用、关键字段的用途过一遍，顺手给系统加上一两个自己风格的类和注释。
第四天：改一个最小的功能点。比如把“满100减10”改成“满100减15”，必须找到规则配置页面完成修改并验证生效。
第五天：看论文和答辩PPT，对照系统实际操作理解每个章节在讲什么。
第六天：自己对着系统模拟答辩，用手机录音，反复听哪里卡壳。
第七天：检查论文格式、查重、整理演示环境和备用账号。
这套流程走完，“源码不是自己写的”这个顾虑基本可以放下，因为你已经能讲清楚每一行核心代码的作用了。我见过太多同学拿到现成项目后直接开抄论文、开录演示，结果答辩时被问一句“你数据库为什么这样设计”就彻底卡住。项目是工具，不是答案，真正消化成自己的才是毕设的意义所在。
最后再分享一点实际带学生的体会：远程调试时最耗费时间的往往不是代码逻辑问题，而是环境问题——MySQL起不来、Redis没装、字符集乱码、端口被占用，这些问题排在代码之前先排查，能解决一大半的折腾。定制需求也一样，改之前多问几个“为什么”，把业务规则确认清楚再动手，效率远高于闷头改代码。希望这篇文章能帮做这个题目的同学少走些弯路，把精力放在真正值得打磨的设计和答辩准备上。
