基于Spring Boot的工厂精密设备销售管理系统设计与实现

1. 选题价值拆解：为什么"销售管理系统"是Java毕设的常青树

每年到了毕设选题季，我都能收到大量类似"老师，Java毕设做什么题目好"的私信。这个"基于springboot的工厂精密设备销售管理系统的设计与实现"题目，第一眼看上去平凡无奇，但仔细拆解你会发现，它其实踩中了毕业设计选题最稳妥的几个关键点：技术栈主流、业务场景真实、功能边界清晰、数据模型不复杂但足够完整。换句话说，这是一道"标准到不能再标准"的菜，但认真做好，端上桌是能拿高分的那种。

先说技术栈。Spring Boot + MySQL的组合，放眼整个Java就业市场，依旧是中小型企业内部系统最主流的搭配。用这个组合做毕设，意味着你在简历上写"熟悉Spring Boot、MyBatis、MySQL"的时候，不是空口白话，而是有一个完整的、可演示的项目作为支撑。面试官问"Maven怎么用"、"事务怎么加"、"索引怎么设计"的时候，你能直接对应到自己项目里的某个具体场景，这种"项目驱动"的掌握程度，远比背八股文扎实。

再说业务场景。"工厂精密设备销售"这个定语很有讲究。它不是普通的电商系统，卖的是高价值、强专业性的工业设备。这就决定了它的销售流程不可能像淘宝那样"下单即付款"，而是需要报价审批、渠道管理、售前方案、合同评审、发货验收、售后跟踪等一系列更重的环节。这些业务环节一多，你的系统功能模块自然就丰富了，论文的"需求分析"和"功能设计"章节也就不愁没东西写了。

最后说适合的人群。如果你符合以下任何一条，这个题目都值得认真考虑：

• 基础中等偏上，想通过毕设把Spring Boot + MyBatis + MySQL的完整开发流程走一遍；
• 准备找Java后端方向的工作，需要一个拿得出手的业务项目写在简历里；
• 时间不算特别充裕，需要找一个"框架成熟、资料多、有完整参考项目"的题目，确保能顺利落地并参加答辩。

2. 系统整体设计思路：先把业务的骨架画清楚

2.1 功能模块划分：从销售流程反推系统边界

我带的很多学生拿到题目第一反应是"先建表和写代码"，这是大忌。做管理系统，第一步永远是梳理业务流程。工厂精密设备的销售流程，我建议先画一条主线：

客户咨询 → 销售员创建报价单 → 部门主管审批 → 客户确认 → 生成销售合同 → 财务审核 → 仓库发货 → 客户签收 → 售后跟踪

围绕这条主线，系统功能模块可以拆成六大块：

每多一个模块，论文里就能多写一节"功能设计"，答辩时也能多一个"你这里怎么设计的"的展示点。一般毕设做到5到6个业务模块，加上用户管理、菜单权限、数据统计这些基础模块，体量已经完全够了。

2.2 技术选型：为什么是Spring Boot而不是SSH或Spring Cloud

很多学生会纠结："老师，我要不要用Spring Cloud？这样显得高级。"我的建议是：毕设阶段，不要为了技术而技术。Spring Cloud微服务化涉及到服务注册、配置中心、网关、分布式事务等一系列问题，如果要真正落地并讲清楚，工作量至少翻三倍。而毕设的核心评价指标是"能跑、能讲、能答"，单体应用完全够用，关键是把单体的代码质量写扎实。

推荐的技术组合：

• 后端：Spring Boot 2.7.x + MyBatis Plus 3.5.x（或MyBatis 3.5.x）+ Spring Security（或Sa-Token做权限）
• 前端：Vue 3 + Element Plus 或 Thymeleaf + Bootstrap，二选一，取决于你的前端基础
• 数据库：MySQL 8.0，保证SQL标准支持更完整
• 构建工具：Maven 3.8+
• 开发环境：JDK 1.8 或 JDK 11，IDEA

这里重点说一下Spring Boot和MyBatis的版本搭配。Spring Boot 2.7是2.x系列的最后一个版本，稳定性和兼容性都经过了充分验证。不要一上来就用Spring Boot 3.x，因为3.x要求JDK 17及以上，很多学校机房或答辩演示的电脑环境不一定支持，而且MyBatis、Shiro等生态组件的版本兼容需要额外处理。作为一个目标为"顺利毕业"的项目，选型的第一原则永远是稳定性。

2.3 数据库设计：一张"设备销售"的关键表该怎么建模

数据库设计是面试官最爱深挖的部分，也是论文里必画ER图、必写数据表的地方。精密设备销售系统的核心表我建议按这样拆：

产品表（product）

• id、product_code（设备编码）、product_name、model（型号）、spec（规格参数）、manufacturer（生产厂家）、unit_price（标准售价）、stock_quantity（库存数量）、status（上下架状态）

客户表（customer）

• id、customer_code、name、industry（所属行业）、contact_person、contact_phone、address、credit_level（信用等级，1-5级）、created_time

报价单表（quotation）

• id、quotation_no（单号，如QD+日期+流水号）、customer_id、salesman_id（销售员）、total_amount（总金额）、status（草稿/待审批/已批准/已拒绝/已转合同）、create_time、approve_time

报价明细表（quotation_item）

• id、quotation_id、product_id、quantity（数量）、unit_price（成交单价）、discount（折扣率）、subtotal（小计金额）

合同表（sales_contract）

• id、contract_no、quotation_id、customer_id、total_amount、payment_type（付款方式）、delivery_date（交货日期）、sign_date、status（待审核/已审核/执行中/已完成/已终止）

发货单表（delivery_order）

• id、delivery_no、contract_id、delivery_date、logistics_company、tracking_no、status（待发货/已发货/已签收）、receiver_name、receiver_phone、receiver_address

回款记录表（payment_record）

• id、contract_id、pay_amount、pay_date、pay_method（银行转账/承兑汇票等）、received_by（经手人）、remark

这里有几个值得在答辩时讲的细节：

第一，为什么报价单和报价明细要拆成两张表？因为一张报价单包含多个设备，如果设计成一张表，要么用逗号拼接设备（违背第一范式，后续统计和修改都很难），要么一条记录存一个设备但会大量冗余报价单信息（单号、客户、销售员反复重复）。拆成主表和子表，用外键关联，既满足规范化要求，也方便做"按设备统计销量"这类分析。

第二，为什么单据编号要单独设计而不用自增主键？自增主键long id只作为物理主键用于关联，但业务上对外展示的编号（如QD20241215001）应该独立维护，这样既避免主键暴露业务数据量，也为后期对接ERP等系统预留了编码规范空间。生成规则建议用"前缀+日期+当日流水号"，在代码里通过Redis自增或数据库Sequence实现。

第三，金额字段用什么类型？这里踩坑的人非常多。float和double存储金额在精度上有隐患（比如0.1+0.2不等于0.3的问题），必须用DECIMAL(10,2)或DECIMAL(12,2)。我在实际项目中就遇到过数据库存0.30000000000000004的诡异问题，排查了很久才发现是double精度惹的祸。这个细节写进论文、答进答辩，是加分的。

3. 核心业务逻辑实现：报价审批、价格策略和库存联动

3.1 报价审批状态流转：用"状态机"的思路管理业务

报价审批是整个销售系统里最有"业务含量"的环节，也是面试官最容易问"你的状态是怎么管理的"的地方。报价单从创建到最终生效，存在一个明确的状态流转：

草稿(0) → 待审批(1) → 已批准(2) → 已转合同(3) ↘ 已拒绝(4) → 重新编辑回到草稿

我建议在实体类中直接定义一个status字段，用int常量去表示，同时在代码里封装状态流转方法，不要让状态字段被随意set。比如：

public class QuotationStatus { public static final int DRAFT = 0; // 草稿 public static final int PENDING = 1; // 待审批 public static final int APPROVED = 2; // 已批准 public static final int CONVERTED = 3; // 已转合同 public static final int REJECTED = 4; // 已拒绝 public static boolean canApprove(int currentStatus) { return currentStatus == PENDING; } public static boolean canConvertToContract(int currentStatus) { return currentStatus == APPROVED; } }

这样在Service层调用时，先判断状态是否合法，再执行更新，避免"从草稿直接跳到已转合同"这种非法操作出现。我在代码讲解环节通常会特别强调这一点，因为业务规则的边界是评判系统设计水平的重要标准。

审批流程本身建议采用"角色判断+操作记录"的方式：销售员提交报价单时，状态置为待审批；销售主管登录后，在待审批列表里看到这条数据，点击批准或拒绝；每一次操作都在operation_log表中记录操作人、操作时间、操作内容，形成完整的审计轨迹。这块逻辑看起来简单，但把"谁在什么时间对什么单据做了什么操作"全部记录清楚，答辩时是最有说服力的。

3.2 价格策略：预设折扣和人工改价的平衡

精密设备的定价不是简单的"单价x数量"。客户等级不同、采购数量不同，价格都可能不同。我建议在报价明细创建时，实现以下逻辑：

1. 报价单创建时，从产品表带出标准售价（unit_price），显示为"参考价"；
2. 销售员根据客户信用等级和采购数量，在界面上填写"成交折扣"（如9.5折、9折），系统自动计算小计金额；
3. 设置一个审批阈值：如果总金额折扣后低于成本价（product_cost）或总金额超过一定额度（如50万元），必须走更高层级审批。

这个"分类分级+阈值控制"的思路，既贴合真实业务，又能在答辩时展示你对"价格管理"的理解。实现上很简单，在service层加一个金额校验方法即可：

public Result<Quotation> validatePrice(Quotation quotation) { BigDecimal costTotal = quotation.getItems().stream() .map(item -> item.getCostPrice().multiply(BigDecimal.valueOf(item.getQuantity()))) .reduce(BigDecimal.ZERO, BigDecimal::add); if (quotation.getTotalAmount().compareTo(costTotal) < 0) { return Result.error("成交总价低于成本价，需高级主管审批"); } return Result.success(quotation); }

注意这里我用了BigDecimal.compareTo而不是equals，因为equals还会比较精度（0.00和0.000是不相等的），而compareTo只看数值。

3.3 订单转合同与库存联动：不要忽略事务控制

报价单批准后，下一步是生成销售合同。我建议的做法是在合同创建的Service方法上加@Transactional注解，同一事务内完成三件事：

1. 根据报价单id和明细，复制生成合同主表和合同明细表记录；
2. 将报价单状态从"已批准"更新为"已转合同"；
3. 扣减产品库存（如果合同约定的是现货交付）。

事务的意义在于"要么全部成功，要么全部回滚"。如果合同创建成功但库存扣减失败，事务回滚后两边都不会留下脏数据。这是我反复跟学生强调的一个点：多表写操作不加事务，等于埋雷。答辩时用两分钟讲清"我这里为什么加事务"，比写一万行代码更能体现你的工程素养。

3.4 数据统计与报表：用SQL聚合看看"卖得怎么样"

系统里加一个简单的统计模块，会明显提升项目完整度。比如利用ECharts在首页展示：

• 近6个月销售额趋势（按月分组，SUM总金额）；
• 设备销量TOP5排行（按产品分组，COUNT数量）；
• 客户成交额排名（按客户分组，SUM合同金额）。

对应的Mapper SQL大概是：

SELECT DATE_FORMAT(sign_date, '%Y-%m') AS month, SUM(total_amount) AS total_amount FROM sales_contract WHERE status IN (2, 3) AND sign_date >= DATE_SUB(CURDATE(), INTERVAL 6 MONTH) GROUP BY DATE_FORMAT(sign_date, '%Y-%m') ORDER BY month;

这类SQL语句虽然简单，但是能看出你会分组聚合、会时间函数、会写条件过滤，是面试中常考的基础SQL能力。更重要的是，首页有了图形化报表，演示时的"视觉冲击力"完全不一样，老师一眼就能看出你的系统不是空壳。

4. MySQL端优化与数据安全：建表、索引、备份

4.1 建表时的几个关键约束

很多学生建表时一股脑全用varchar，懒得起约束，这是很业余的表现。实际在MySQL端，建议注意以下几点：

主键与自增：每张表都要有主键，推荐BIGINT UNSIGNED AUTO_INCREMENT。不要用UUID做主键，因为随机字符串在InnoDB聚簇索引下会产生页分裂，影响插入性能。

非空约束与默认值：业务必填字段一律NOT NULL。状态字段设置默认值（如status TINYINT DEFAULT 0）。创建时间字段设置DEFAULT CURRENT_TIMESTAMP，更新时间字段设置DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，这样在insert和update时完全不用在Java代码里手动set时间。

金额字段：用DECIMAL(12,2)，不要用double。

逻辑删除：设置deleted TINYINT DEFAULT 0字段，所有查询在service层或MyBatis Plus的@TableLogic注解中自动拼接deleted=0条件。好处是数据不物理删除，历史数据可追溯，这也是大厂通用的做法。

4.2 索引设计：不是每个字段都需要索引

索引设计是八股文里常考的内容，但很多学生只会背"索引可以提高查询效率"，在项目里却乱建索引。合理的原则是：

• 外键字段（如quotation_id、customer_id、product_id）必须建索引。由于MyBatis Plus默认不会自动为外键关联字段建索引，所以建表时要手动添加；
• 经常用于查询条件的业务编号字段（如quotation_no、contract_no），建议建唯一索引；
• 状态字段（如status）如果数据分布比较均匀（比如0/1/2/3），单个索引意义不大，但如果是"大量草稿+少量已转合同"这类偏斜分布，索引反而有奇效。不过毕设阶段，这条可以不深究；
• 不要给每个字段都加索引，索引会拖慢insert和update的速度，且占用额外磁盘空间。

一个典型的建表SQL示例：

CREATE TABLE `quotation_item` ( `id` BIGINT UNSIGNED AUTO_INCREMENT COMMENT '主键', `quotation_id` BIGINT UNSIGNED NOT NULL COMMENT '报价单ID', `product_id` BIGINT UNSIGNED NOT NULL COMMENT '产品ID', `quantity` INT NOT NULL DEFAULT 1 COMMENT '数量', `unit_price` DECIMAL(12,2) NOT NULL COMMENT '成交单价', `discount` DECIMAL(5,2) DEFAULT 1.00 COMMENT '折扣率', `subtotal` DECIMAL(12,2) GENERATED ALWAYS AS (unit_price * quantity) STORED COMMENT '小计金额', PRIMARY KEY (`id`), KEY `idx_quotation_id` (`quotation_id`), KEY `idx_product_id` (`product_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='报价单明细表';

这里用到了生成列（generated column），subtotal由unit_price和quantity自动计算，无需在Java代码中维护，既避免冗余写入错误，又简化业务代码。这种细节写在系统设计说明里，是能体现MySQL功底的地方。

4.3 事务隔离级别与Spring事务传播行为

销售系统涉及合同创建、库存扣减、支付记录写入等多个写操作，事务处理是答辩高频问点。需要掌握的核心概念：

• 事务隔离级别：MySQL默认是可重复读（REPEATABLE READ）。在这个业务场景下，因为单据号生成、库存扣减都要求较强的数据一致性，可重复读是合适的。不需要调整全局隔离级别。如果问"RR和RC有什么区别"，标准答法是：RR下存在幻读问题的场景更少（MySQL在RR下通过间隙锁部分解决了幻读），但并发度略低于RC。
• Spring事务传播行为：默认的REQUIRED就够用，重点是理解"如果外层方法加了@Transactional，内层方法是否还需要加"的问题。答案是不需要，因为REQUIRED传播级别下，内层方法会直接加入外层事务。

4.4 数据备份与恢复：答辩时能演示的小亮点

我不止一次在答辩现场看到学生演示系统时，老师突然问一句"数据库崩溃了怎么办"，学生当场愣住。为了避免这种尴尬，建议在项目中写一个简单的数据库备份脚本，比如用mysqldump定时导出SQL文件：

#!/bin/bash # backup.sh 每周日凌晨2点执行 BACKUP_DIR=/data/mysql_backup DB_NAME=sales_system DB_USER=root DB_PASS=your_password DATE=$(date +%Y%m%d) mysqldump -u${DB_USER} -p${DB_PASS} ${DB_NAME} > ${BACKUP_DIR}/${DB_NAME}_${DATE}.sql find ${BACKUP_DIR} -type f -name "*.sql" -mtime +30 -exec rm {} \;

再配合crontab写成定时任务。答辩时你就可以说："我们的系统定期全量备份，保留30天，恢复时使用source命令导入即可。"这一句话就能把一个普通项目提升到"有运维意识"的层次。

5. 开发过程中的痛点实录：配置、调试与代码讲解

5.1 Spring Boot配置文件：这些坑我基本都踩过

Spring Boot的application.yml是入门第一个坎。以下是我在学生项目中见过频率最高的几个问题：

第一，端口占用。经常出现"APPLICATION FAILED TO START: Port 8080 was already in use"。原因通常是上次运行没有关闭程序，或本机装了其他Web服务。解决办法：

# Windows netstat -ano | findstr 8080 taskkill /F /PID 对应的PID

第二，MySQL连接配置。新版MySQL 8.0的驱动类和URL格式与5.x不同，如果你用的是MySQL 8.0，需要配置：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/sales_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456

其中serverTimezone=Asia/Shanghai解决时区报错，allowPublicKeyRetrieval=true解决MySQL 8.0的公开密钥检索问题。这两个参数不加，启动必报错。

第三，MyBatis驼峰映射。如果表字段用下划线（如create_time），Java属性用驼峰（createTime），必须在配置中打开：

mybatis: configuration: map-underscore-to-camel-case: true

不打开的话，查询结果里createTime永远是null，一个很隐蔽的坑。

5.2 JDK版本与Spring Boot版本不匹配的典型报错

有一次一个学生跑项目，启动直接报UnsupportedClassVersionError，一看日志是类文件版本号不对。原因是他的Spring Boot 3.2项目需要JDK 17，但本机装的是JDK 8。这个问题的本质是JDK和框架的版本矩阵，我建议一开始就统一环境：

• JDK 1.8 + Spring Boot 2.4~2.7 + MyBatis Plus 3.x（兼容性最好，找教程也最容易）；
• JDK 17 + Spring Boot 3.x + MyBatis Plus 3.5.3+（新特性多，但遇到问题网上的解决方案相对少一点）。

对于大多数毕设同学，我推荐第一套组合，不用纠结，稳定压倒一切。IDEA中切换JDK版本要同时检查Project Structure里的Project SDK和Modules的Language Level，以及Settings里Maven的Runner JRE，三处保持一致，否则编译和运行都可能出现"找不到符号"或在IDEA内能跑但打包后不能运行的情况。

5.3 MyBatis Plus的加分用法：少写SQL不是坏事

用MyBatis Plus而不是原生MyBatis，可以显著减少工作量，比如单表CRUD完全不用手写SQL。推荐核心用法是：

LambdaQueryWrapper，比字符串列名更安全，编译期就能发现错误：

LambdaQueryWrapper<Quotation> wrapper = Wrappers.lambdaQuery(); wrapper.eq(Quotation::getCustomerId, customerId) .eq(Quotation::getStatus, QuotationStatus.APPROVED) .between(Quotation::getCreateTime, startTime, endTime) .orderByDesc(Quotation::getCreateTime); List<Quotation> list = quotationMapper.selectList(wrapper);

但是要注意，多表关联查询不要用MyBatis Plus硬拼，老老实实写XML里的自定义SQL。比如统计报表、联合查询客户+报价单+明细时，用@Select注解或XML映射文件写原生SQL更清晰。一句话：单表操作交给MyBatis Plus，多表复杂查询交给XML SQL。

5.4 前端联调与接口调试：工具和技巧

毕设项目里，前后端联调是最耗时的环节。我建议掌握几个高效工具：

• Postman / Apifox：调试后端接口必备，可以保存接口集合，测试不同参数组合。Apifox还支持从数据库表和Java代码自动生成接口文档，效率更高；
• 浏览器F12开发者工具：看Network面板里的请求状态码、请求参数、响应内容，排查"请求发送了但响应不对"的问题；
• IDEA内置HTTP Client：在IDEA里直接编写.http文件请求接口，方便做单元调试。

常见问题之一是前后端联调出现跨域。开发环境解决方案：在Spring Boot中写一个CORS配置类（或使用@CrossOrigin注解），也可以使用Vite的proxy代理解决。生产环境（部署到同一台服务器）下通常不会遇到跨域问题。答辩时老师如果问跨域，你说清楚"开发环境使用代理解决，生产环境由Nginx统一转发"即可。

5.5 代码讲解的准备工作：把"怎么讲"提前写好

这个题目里特别标注了"代码讲解"和"全bao"，我理解这不仅仅是交付一份代码，而是需要在答辩时把代码讲清楚、讲出逻辑。以我的经验，建议准备以下5个讲述点：

1. 项目启动流程：从Spring Boot启动类开始，讲@ComponentScan扫描了哪些包，Controller→Service→Mapper的调用链；
2. 登录鉴权流程：用户的登录请求如何被拦截器/过滤器处理，token如何生成和校验，权限标识（如ROLE_ADMIN、ROLE_SALESMAN）如何控制菜单和接口的访问；
3. 一条业务主线的完整数据流：比如"创建报价单"请求从Vue页面发起到数据库落库的完整过程，涉及哪些类、哪些表；
4. 一个复杂SQL的讲解：选一条报表SQL或关联查询，讲清楚为什么这么写、涉及哪些索引；
5. 一个踩坑问题的复盘：比如"我遇到MySQL时区报错，后来通过修改URL参数解决"，这比"我项目里没有bug"真实可信得多。

6. 从零到一的项目开发节奏：时间线规划

单人或双人完成这个毕设项目，建议按照以下节奏推进，避免前松后紧，最后熬夜赶工：

这个时间线里，第5-8周是核心开发期，如果你的基础一般，代码产出速度可能比预想慢，我的建议是不要等到全部模块写完再联调，每完成一个模块就马上跑一遍完整流程，确保功能闭环，否则最后联调时bug扎堆，会非常崩溃。

7. 论文写作与答辩准备的配合打法

7.1 论文结构怎么组织

毕设论文通常包含以下章节，写作顺序建议和开发顺序保持一致：

• 摘要与关键词：写清楚"基于Spring Boot和MySQL，设计并实现了一套面向工厂精密设备销售业务的综合管理系统，实现了客户管理、报价审批、合同管理、库存联动、售后跟踪等核心功能"；
• 绪论：研究背景与意义、国内外研究现状（写"大多数中小企业仍依赖Excel或手工台账管理销售流程，存在效率低、易出错、难以追溯等问题"即可，不用虚构太多）；
• 相关技术介绍：Spring Boot、MyBatis Plus、MySQL、Vue/ECharts，每个技术2-3段概述；
• 系统分析：可行性分析、需求分析（功能需求+非功能需求）、用例图；
• 系统设计：架构设计、功能模块设计、数据库设计（ER图+重点表结构说明）；
• 系统实现：按模块逐一展示核心代码和界面截图，配关键逻辑的说明；
• 系统测试：测试环境、测试用例表、结果分析。

这个小节的另一个重点是，系统测试不要只写"登录成功"。要写有深度的用例，比如：

• 报价单在"待审批"状态下，非主管角色不能审批（权限校验测试）；
• 合同创建时库存不足，事务是否回滚（事务一致性测试）；
• 删除客户时，如果该客户已有历史报价单，是否提示禁止删除（外键约束/业务校验测试）。

7.2 答辩高频问题清单

在带毕设的过程中，我总结了一些老师们大概率会问的问题，提前准备，心里有底：

• 为什么选Spring Boot？它和传统SSM比有什么优势？
• 数据库表之间怎么关联的？哪些字段建了索引？为什么？
• 说一下项目里的事务你是怎么处理的？哪里用了@Transactional？
• 报价审批流程是怎么实现的？状态有哪几种？怎么防止非法的状态跳转？
• 你的系统有哪些安全隐患？
• 如果客户量达到十万级，你觉得系统哪些地方会出现性能瓶颈？如何优化？

最后一个问题尤其能拉开差距。你可以答：数据库查询是主要瓶颈，方案是给常用查询字段加索引、对报表统计做缓存、考虑分库分表或引入ES；在应用层，可以引入Redis缓存热点客户的报价信息。这些不需要真正实现，但能说出思路已经能让老师觉得你有架构意识了。

7.3 演示时的"高光时刻"设计

答辩演示通常只有5-10分钟，要提前规划演示路径，把系统的"过人之处"放到最前面。我的建议顺序：

1. 展示首页Dashboard：数据看板直观，视觉效果好；
2. 演示完整业务闭环：新建一个报价单 → 切换到主管账号审批 → 转成合同 → 扣库存 → 发货 → 查看列表；
3. 展示你最有把握的一个技术点（比如事务回滚）；如果现场能快速演示"合同创建时把库存改成0，看系统是否报错并不留脏数据"，冲击力非常强；
4. 最后展示数据库备份脚本和日志记录功能，体现工程化意识。

8. 常见问题与排查技巧实录：照着抄就行

8.1 启动阶段高频报错速查表

8.2 运行阶段常见问题

Q：列表查询正常，但详情页面某些字段显示null？

优先检查驼峰映射是否开启（见上述mybatis配置）。如果开启了仍然为null，检查数据库字段名和Java属性名是否完全对应，比如数据库里叫serial_no，Java里叫serialNo，需要确认Mapper的查询SQL是否使用了别名。

Q：数据库表被别人改了结构，程序启动没问题但查询报错？

最常见的是新增了非空字段但没给默认值，导致insert时提示"Field 'xxx' doesn't have a default value"。解决方法是给字段设置默认值，或是在Java实体中用@TableField做insert策略控制。

Q：前端页面明明调用了接口，但F12里看到的是404？

先看请求URL和后端Controller的@RequestMapping路径是否完全一致，注意大小写和/符号；再看Controller类上是否有@RestController注解，没有的话返回的是视图而不是JSON数据。

Q：部署到服务器上打不开网页？

优先检查Linux防火墙和云服务器安全组是否开放了对应端口，然后确认Spring Boot启动时绑定的IP是不是0.0.0.0（默认是0.0.0.0，不要改成127.0.0.1）。如果前后端分离，还要确认Nginx或其他Web服务的反向代理配置是否正确。

8.3 一个很隐蔽的坑：MyBatis Plus自动填充失效

用了@TableField(fill = FieldFill.INSERT)配合MetaObjectHandler实现create_time自动填充，但插入时create_time始终为null。排查思路：

1. 检查实体类中create_time字段是否是LocalDateTime或Date类型；
2. 检查MetaObjectHandler的实现类是否被Spring管理（有没有加@Component或@Configuration）；
3. 检查strictInsertFill方法中字段名是否和实体属性名一致（比如"createTime"而不是"create_time"）。

这个坑我见过多次，因为MyBatis Plus的自动填充是基于属性名的，和数据库列名关系不大。

9. 从项目到Offer：如何把毕设变成面试作品

最后说点题外话。很多学生做毕设只是为了过关，但其实这个项目完全可以变成求职时的面试作品。你可以在简历的"项目经历"一栏这样写：

工厂精密设备销售管理系统（Spring Boot + MyBatis Plus + MySQL + Vue）

• 独立完成系统需求分析、数据库设计和核心业务模块开发，实现了客户管理、报价审批、合同管理、库存联动、售后跟踪等核心流程；
• 使用状态机模式管理报价单状态流转，通过自定义审批阈值规则实现分级审批，确保超低价和超额订单需更高层级审核；
• 在合同创建场景中通过@Transactional实现多表写入的数据一致性，库存扣减失败时整体回滚，避免脏数据；
• 基于ECharts实现销售额趋势、销量排行等数据可视化报表，通过SQL分组聚合支持运营决策。

面试官只要顺着"状态机""事务""索引优化"这几个关键词往下问，你都能用项目里的真实场景来回答，这比背概念有说服力得多。

再强调一次，毕设选题不在于题目多花哨，而在于你能不能在三个月内把它做成一个"逻辑完整、能讲清楚、有亮点"的系统。这个基于Spring Boot的工厂精密设备销售管理系统，业务纵深适当，技术栈主流，资料参考丰富，是一个性价比很高的选择。把每个模块做扎实，把每个设计决策的原因想明白，你不仅是在完成毕业设计，更是在为第一份工作提前练手。