SpringBoot+Vue+MySQL农产品预售平台：毕设选题与完整实现指南

每年临近毕业季，计算机相关专业的学生都会面临同一个问题：毕设题目怎么选。做得太简单，答辩时老师一句"这不就是增删改查"就能让人下不来台；做得太复杂，又怕时间不够、能力撑不住，最后烂尾。如果你的定位是"中等偏上、能顺利完工，又有值得讲的东西"，那"SpringBoot+Vue+MySQL 农产品预售平台"这个题目我觉得是一个非常稳妥的答案。

这个题目好在哪里？先说技术栈：SpringBoot 是 Java 后端的主流框架，Vue 是前端招聘市场上出现频率最高的框架之一，MySQL 又是关系型数据库的标杆，这三个组合出来就是一套标准的"前后端分离"企业级开发模型。再说业务，农产品预售不是普通的商品下单，它带时间维度、带状态流转、带库存约束，比单纯的"购物车+下单"多了一层业务复杂度，但也正是因为这一层，论文里有东西可写、答辩时有逻辑可讲。

这篇文章我打算按照我从零完成这套系统（源码、数据库、论文、部署文档）的实际过程来讲，把每一步为什么要这么做、怎么设计、会遇到哪些坑都交代清楚。如果你想参考或者直接复现这个项目，这篇文章可以当作一份完整的前置说明书。

1. 为什么是农产品预售：这届题目的技术含量与答辩底气

1.1 预售场景的商业逻辑，天然适合当毕业设计

先说业务背景。农产品和普通标品不一样，它有很强的时效性。苹果、大米、茶叶这些产品，通常是先在产地把订单收上来，然后安排采摘、分拣、包装、发货，整个链路是有周期性的。预售模式的好处是：农户按订单量组织生产，避免滞销；消费者用预售价拿到比上市更便宜的货；平台提前锁定资金和货源。所以你做的不是一个虚构的商城，而是一个在真实产业里成立的商业模式，答辩老师一听就能理解，不需要你费劲解释这个系统到底解决了什么问题。

从这个业务出发，系统天然需要几个核心模块：用户模块（农户/买家/管理员）、商品模块、预售活动模块、订单模块。听上去还是那套常规功能，但因为有了"预售"，订单不再是简单的"下单-付款-发货"，而是多出了"活动状态判断""定金尾款""发货时间预告""活动取消退款"这些逻辑。这一多，题目的含金量马上不一样了。

1.2 技术栈选型的现实考量：主流、够用、找工作能写进简历

很多同学在选技术栈的时候容易走极端，要么是 JSP + Servlet 这种老掉牙的组合，要么是 SpringCloud 微服务全家桶。前者做出来像课设，后者对毕设来说根本驾驭不住，光环境搭建就能熬掉半个月。

SpringBoot + Vue + MySQL 正好卡在中间。SpringBoot 帮你省掉了大量 XML 配置，一个启动类跑起来，非常适合一个人独立开发；Vue 的组件化思想会让前端代码结构清晰，页面多了也不会乱；MySQL 加上 Navicat 这类可视化工具，建表、导数据都直观。这套组合做出来的系统，企业面试官看了不会觉得"这是个玩具"，但又完全是一个人在两个月内能完成的量。

还有一点很实际：SpringBoot 和 Vue 的中文资料极其丰富。你遇到的 90% 的问题，比如"springboot版本太高导致启动失败""vue安装及环境配置""mysql安装教程8.0"，搜索一下就有现成答案。毕设阶段时间宝贵，选一个社区成熟的技术栈，本身就是降低风险。

1.3 这套系统能展示哪些能力点，直接对应论文的章节

我做这套系统的时候，最大的感觉就是"论文的每一章都有着落了"。这句话你可以记一下，因为很多同学是做完代码才开始愁论文，但选对题目之后，论文结构是跟着系统长出来的。

• 需求分析对应预售业务的角色划分和流程梳理；
• 系统设计对应前后端分离架构、各模块的功能划分；
• 数据库设计对应实体关系、表结构、索引和约束；
• 系统实现对应后端接口、前端页面、前后端联调；
• 系统测试对应接口测试、功能测试、并发下单场景测试。

所以这个题目不是"做系统顺便写论文"，而是"系统的每一层设计都是论文的素材"。答辩的时候你只需要顺着这条线讲清楚，老师基本不会问出你答不上来的问题。

2. SpringBoot 后端怎么落：工程骨架、核心模块与预售状态机

2.1 工程结构与三层架构：先定骨架再写代码

拿到题目之后别急着写业务代码，我建议先花半天时间把工程骨架搭好。用 IDEA 创建一个 SpringBoot 工程，Java 版本建议选 JDK 8 或者 JDK 11，这两个版本和大多数毕业设计环境、服务器环境都比较兼容。热搜词里有"springboot版本太高"，这个问题确实是真实存在的——如果你用了 SpringBoot 3.x，最低要求 JDK 17，而很多学校的实验环境和老项目插件并不支持，所以稳妥起见用 SpringBoot 2.5.x 或 2.7.x 版本。

包结构我按下面这样设计，每个包职责非常明确，后面写代码和写论文都省心：

com.agri.pre ├── config // 配置类：跨域、拦截器、WebMvc配置 ├── controller // 接口层：接收前端请求，返回统一结果 ├── service // 业务层：核心逻辑都在这里 │ └── impl // 业务实现 ├── mapper // 数据访问层：MyBatis的Mapper接口 ├── entity // 数据库实体类 ├── dto // 前端传入的参数对象 ├── vo // 返回给前端的视图对象 ├── common // 统一返回结果、异常处理、常量 └── util // 工具类（JWT、日期处理等）

然后统一返回结果类 R 我会这样设计：code（200 成功、500 失败）、message、data。这个类虽然简单，但能保证前后端对接口的认知一致，后面联调时不用各说各话。

2.2 三大核心模块：用户、商品、预售活动

用户模块主要做注册、登录、权限控制。密码不要明文存，用 MD5 加盐或者 BCrypt 加密；登录成功之后返回一个 Token（可以用 JWT），前端把 Token 存起来，每次请求带在 Header 里，后端用一个拦截器校验。这样就是一个最标准的前后端分离鉴权流程，写进简历里也不丢人。

商品模块相对常规：后台管理端维护商品信息（名称、图片、描述、普通售价、库存），前台展示商品列表和详情。注意一个设计点：预售价格和普通价格可以同时存在，因为预售活动通常让利，但活动结束后商品恢复原价销售。所以 product 表里既要有 price（原价），也要支持从 activity 表里取 pre_sale_price（预售价），不要把两个价格揉在一个字段里。

预售活动模块是这个系统的灵魂。一张活动表至少要包含：关联商品 ID、预售开始时间、预售结束时间、预计发货时间、预售价或定金比例。活动状态不要用定时任务去改数据库里的状态字段，直接用时间判断：当前时间小于开始时间是"未开始"，在开始和结束之间是"进行中"，大于结束时间是"已结束"。这种设计的好处是，状态永远是从时间计算出来的，不会因为定时任务没跑而出现状态错误。

2.3 预售状态机的设计：订单在什么节点做什么事

订单模块对预售的支持是这个系统最值得讲的部分。普通电商订单状态一般是"待支付-已支付-已发货-已完成"，预售订单要在这个基础上增加几个分支。

我把状态设计成下面这套，实际开发时用枚举常量定义：

• 待支付：用户提交订单但未付款；
• 已支付（待发货）：用户已付款，等待商家按预计发货时间发货；
• 已发货：商家已发货，等待确认收货；
• 已完成：订单结束；
• 已取消：用户在支付前取消，或者活动因故取消后自动关单。

如果做了定金尾款模式，还要加一个"待付尾款"状态，尾款支付时间到了之后，用户可以支付尾款，订单才进入"已支付（待发货）"。但定金尾款这个模式说实话做起来细节不少，如果毕设周期比较紧张，可以先做全款预售，论文里留一段"扩展方向"提一下定金尾款的设计即可。我当年就是这么处理的，既控制了工作量，又显得有思考深度。

3. 预售核心链路：下单、库存扣减与订单状态流转的接口实现

3.1 一条完整的预售下单请求是怎么走通的

前端用户看到预售活动，点击"立即预订"，到订单创建成功，中间经过的接口链路是这样的：

POST /api/order/create 前端参数：activityId、userId、quantity 后端逻辑： 1. 校验用户登录状态（来自Token） 2. 根据activityId查询预售活动 3. 校验活动状态：当前时间必须在开始时间和结束时间之间 4. 校验活动关联的商品库存是否充足（库存 >= 购买数量） 5. 生成订单号，写入订单表（状态：待支付） 6. 扣减商品库存 7. 返回订单信息（订单号、金额、支付截止时间）

这一步里最关键的数据库操作是"校验库存"和"扣减库存"必须保证原子性。很多同学第一次写会写成：先 select 库存，判断数量，再 update 库存-1。这个写法在单线程测试下没问题，但一旦两个人同时下单，就可能出现超卖。正确做法是把判断和扣减合并成一条 SQL。

3.2 库存扣减的并发安全：一条 SQL 解决超卖

我直接给出这条用得最多的扣减 SQL：

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

这条 SQL 的关键在于 WHERE 条件里带了 stock >= quantity。MySQL 执行 update 时会加行锁，当库存不足时影响行数为 0，代码里判断 update 返回的条数，如果是 0 就抛异常提示"库存不足"，如果是 1 说明扣减成功，再继续下单流程。这样既不发锁、也不超卖，性能和安全性都兼顾了。整个下单方法记得加上 @Transactional 事务注解，保证"扣库存"和"生成订单"要么都成功，要么都回滚。

然后说一下乐观锁。有些教程会让你在表里加 version 字段，每次更新时 compare and set。但我个人实践下来的结论是：在毕业设计这个体量下，用"条件 UPDATE"就可以解决超卖，没必要引入 version 字段增加复杂度。如果你的论文想体现并发控制能力，可以两种方案都写进"系统设计"章节作对比，然后说明你选择了哪种、为什么，答辩的时候这就是一个亮点。

3.3 支付环节的务实做法：回调 vs 模拟支付

支付是很多毕设的痛。接微信支付、支付宝支付，需要企业资质、需要商户号，个人开发者很难搞定。所以我的建议是分两种做法：

第一种，如果你的系统想演示完整闭环，可以用微信支付沙箱或者支付宝沙箱环境，网上的 demo 很多，但配置过程确实比较繁琐，要花不少时间。

第二种，也是我更推荐的，做一个"模拟支付"接口。用户在订单页点击支付，弹出一个支付确认框，点击确定后，后端把订单状态从"待支付"改成"已支付"。然后你在论文里写清楚：真实场景下这里应该对接第三方支付，支付成功后由支付平台回调通知服务器；毕设环境下用模拟支付代替，不影响业务逻辑的完整性。答辩时老师问起来，你能讲清楚真实链路是什么样的，这就已经达到毕业设计了。

3.4 订单状态流转的时序控制

有了状态之后，谁在什么时机修改状态，必须定义清楚，不能谁都能改：

• 用户：创建订单（待支付）、取消订单（待支付->已取消）、模拟支付（待支付->已支付）、确认收货（已发货->已完成）；
• 系统/管理员：发货（已支付->已发货）、取消活动自动关单（已支付->已取消并退款）。

这里容易出 bug 的地方是：用户取消订单之后，库存要加回来；活动取消之后，所有已支付订单要进入退款逻辑（模拟退款就是把订单状态标记为"已取消"）。这些"反向操作"在写接口的时候就要想到，不要后面测试时被老师一操作才发现。

4. Vue 前端从页面到接口：路由、组件与联调的那些细节

4.1 前端工程初始化：Vite 搭起来比 Webpack 省心

前端我用的方案是 Vue 3 + Vite + Element Plus + Pinia + Axios。如果你之前用过 Vue 2，上手 Vue 3 唯一的门槛是 Composition API 的写法——把逻辑按功能组织在 setup 里，而不是按选项分散在 data/methods/computed 里。建议不要在这时候花时间研究源码级别的原理，先会用，能写页面、能调接口，等系统做完了再回头补原理。

Vite 的好处是冷启动快，开发时改代码刷新几乎无感，比 Webpack 那种每次改完等几秒的体验舒服太多。初始化命令很简单：

npm create vite@latest agri-front -- --template vue cd agri-front npm install npm run dev

装依赖的时候加几个常用的包：Element Plus 做后台界面组件，Axios 做请求，Vue Router 做路由，Pinia 做状态管理。别小看这一步，很多同学卡在"npm run dev 跑不起来"，九成是 Node.js 版本问题。Vite 3 以上要求 Node 14.18+，我建议直接装 Node 16 或 18 的 LTS 版本，省心。

4.2 页面路由与核心页面设计

路由我分成两个区域：前台商城和后台管理。前台包括首页、商品列表、商品详情、预售活动页、购物车、订单确认、订单列表、个人中心；后台包括商品管理、预售活动管理、订单管理、用户管理。用 Vue Router 的动态路由来做权限控制：未登录用户访问个人中心/订单页，路由守卫直接跳转到登录页。

每个页面的数据流都是同一个套路：页面加载时在 onMounted 里调用接口取数，数据交给 ref/reactive 管理，模板里用 v-for 渲染列表，用户操作时调用另一个接口提交数据。这个套路你会了，整套前端基本就拿下了。

预售活动页是前端最核心的页面。它需要展示活动剩余时间、预售价格、预计发货时间、剩余库存。剩余时间建议在前端用 setInterval 做倒计时，每秒计算一次当前时间和活动结束时间的差值并刷新显示。这里有个小坑：后端返回的时间是 JSON 字符串，比如 "2024-06-15 20:00:00"，不要用 new Date() 直接解析，不同浏览器的解析行为不一样，稳妥做法是后端返回时间戳（long），前端用 new Date(timestamp) 格式化，就不会有兼容问题了。

4.3 Axios 封装与联调常见问题

Axios 我建议封装一个 request.js，统一处理 baseURL、请求头、响应拦截、错误提示。baseURL 开发环境写成 http://localhost:8080，生产环境打包时改成你的服务器 IP 或者域名，这个配置抽取到一个常量文件里，方便后续部署切换。

联调阶段我遇到的、也是热搜词里出现最多的问题是"前后端跨域"。前端跑在 5173 端口，后端跑在 8080 端口，浏览器会拦截跨域请求。解决办法有两种：一种是在 SpringBoot 里写一个 WebMvcConfigurer 配置类，允许指定来源的跨域请求；另一种是用 Vite 的 proxy 代理，把 /api 开头的请求转发到后端。我个人的习惯是两种都配上，开发时用 Vite 代理，部署后由 Nginx 统一代理，双保险。

联调时的另一个常见问题是时间格式不一致。Java 后端默认返回的 LocalDateTime 序列化出来可能带 T，比如 "2024-06-15T20:00:00"，前端展示会很难看。解决方式是在配置文件里统一一下：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这个配置我强烈建议一开始就加上，不然后面每个时间字段都要单独处理，相当折磨人。

5. MySQL 表设计：核心表结构、索引与外键约束怎么定

5.1 核心表与字段要点

数据库设计是整个系统设计章节的重头戏。我建了六张核心表，每张表的字段都有明确的业务含义。

用户表 user：

• id 主键自增
• username 用户名唯一
• password 加密后的密码
• nickname 昵称
• role 角色（USER/ADMIN）
• phone、email 联系方式
• create_time 注册时间

商品表 product：

• id 主键
• name 商品名称
• category 所属分类（水果/粮油/茶叶等）
• price 原价
• stock 库存
• image 商品图片URL
• description 商品描述
• status 上下架状态

预售活动表 pre_sale_activity：

• id 主键
• product_id 关联商品
• pre_sale_price 预售价
• start_time 开始时间
• end_time 结束时间
• delivery_time 预计发货时间
• limit_quantity 每人限购数量（这个字段很容易被遗忘，但对农产品预售来说很重要）
• status 手动控制是否启用

订单表 orders：

• id 主键
• order_no 订单号，唯一索引
• user_id 下单用户
• activity_id 关联预售活动
• product_id 关联商品
• quantity 购买数量
• total_price 订单总金额
• status 订单状态（待支付/已支付/已发货/已完成/已取消）
• create_time 下单时间
• pay_time 支付时间
• cancel_time 取消时间
• 注意：订单表名不要用 order，因为 order 是 SQL 的保留字，执行 SQL 时会报错。要么用 orders，要么在写 SQL 时加反引号。我用的是 orders。

订单明细表 order_item（如果一张订单只对应一个商品，可以把明细合到订单表，但加上明细表更规范，论文也能多写一页）：

• id 主键
• order_id 关联订单
• product_id 关联商品
• activity_id 关联活动
• product_name 下单时的商品名称快照
• price 下单时的价格快照
• quantity 数量

购物车表 cart，以及一个可选的支付记录表 payment_record，用来记录模拟支付的回调信息，便于论文测试章节写"支付流程验证"。

5.2 索引、外键和约束：学术上完整，工程上务实

索引方面，我的经验是：订单表要加 (user_id, create_time) 联合索引，因为最常用的查询是"我的订单列表"；预售活动表要加 (product_id) 索引和 (start_time, end_time) 索引，因为活动校验时高频按商品和时间查询。订单号 order_no 加唯一索引，防止并发生成重复订单号。

外键方面，毕业设计建议用物理外键，虽然很多企业开发为了性能会放弃外键改用逻辑关联，但毕设场景下物理外键能直观展示实体关系，论文里的 E-R 图画出来也更有说服力。我自己实践时是加上了外键的，测试数据量小，性能影响完全可以忽略。

还有一个细节：数据库的字符集一定要设置成 utf8mb4，而不是 utf8。因为 utf8 在 MySQL 中最多存 3 个字节，像 emoji 或者一些生僻字会存入失败。农产品名称里难免有特殊字符，这个坑我在导入数据时踩过，后来统一改成 utf8mb4 就没再出现过。

5.3 持乐观锁方案和事务隔离级别

前面提到库存扣减用条件 UPDATE 解决超卖，这里再说一下事务。MySQL 默认的 InnoDB 事务隔离级别是 REPEATABLE READ（可重复读），在这个级别下，结合行锁，上面的扣库存 SQL 是安全的。如果论文要写事务隔离级别，可以重点讲一下这段逻辑：为什么不用 READ COMMITTED、什么是当前读和快照读。不需要写太多，但写了就是加分项。

设计数据表的时候还要考虑"数据字典"这类的附页，把每张表每个字段的含义列成表格放进论文附录，这也是凑论文字数的一种正经方式，而且评阅老师通常会觉得你工作做得很细致。

6. 部署文档的价值：从本地跑通到服务器上线的完整流程

6.1 本地环境准备：先把一套干净的环境装对

部署这件事最核心的一点，是把环境搞一致。我第一次部署的时候就是吃了环境不一致的亏，本地跑得好好的，服务器上就是启动报错。

本地你需要的工具清单如下：

MySQL 安装的时候有同学会碰到"mysql ssl连接错误"，这个问题多数出现在 Navicat 8.0 连接时的 SSL 配置上，连接时在 SSL 选项卡选择"禁用"即可。我建议写部署文档的时候把这步写进去，因为这套系统我复现过不止一次，每次都有同学卡在数据库连接上。

6.2 前后端打包：后端 jar 包 + 前端 dist 目录

后端打包很简单，在项目根目录执行：

mvn clean package -DskipTests

构建完成后，target 目录下会生成一个 xxx.jar。如果打出来的 jar 包启动时找不到主类或者报缺少依赖，先检查是不是打包插件没配好，SpringBoot 项目用 spring-boot-maven-plugin 才能打出可执行的 fat jar。这个细节排查起来很隐蔽，文档里务必写清楚。

前端打包：

npm run build

生成 dist 目录，里面是纯静态文件。前端如果要调后端的接口，注意 getBaseURL 里的地址在生产环境要改成服务器的 IP 或者域名，不然前端页面打开了，接口请求却指向 localhost，就变成"页面能看，数据全无"。

6.3 部署到 Linux 服务器的步骤与 Nginx 配置

服务器上部署，我用的是一套最简单的方案：jar 包直接跑 + Nginx 托管前端静态文件并反向代理接口请求。

后端启动：

nohup java -jar agri-backend.jar --spring.profiles.active=prod > app.log 2>&1 &

后台运行，日志输出到 app.log，方便排查问题。如果你用 --spring.profiles.active=prod，记得在 application-prod.yml 里配置线上数据库地址和账号密码。

Nginx 配置这样写：

server { listen 80; server_name your_server_ip; # 前端静态文件 root /usr/share/nginx/html/dist; index index.html; # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这里有一个关键点：Vue 的 history 路由模式，刷新页面会 404，因为 Nginx 只在根路径找到了 index.html，而 /order/list 这样的路径没有对应文件。解决办法是在 Nginx 配置里加一句：

location / { try_files $uri $uri/ /index.html; }

这句配置我在部署文档里标了五颗星的重要性，没有它，前端路由跳转没问题，但你一刷新页面就是白屏。很多同学第一步部署就卡在这，以为是打包错了，其实是 Nginx 少了这个回退规则。

6.4 部署文档应该怎么组织，让同学照着就能跑通

部署文档是这套交付物里很容易被忽视但实际价值很高的东西。我建议文档按下面的目录写：

• 环境要求（JDK/Node/MySQL 版本）
• 数据库初始化（执行 SQL 脚本的步骤，说明每个脚本是干什么的）
• 后端部署（修改配置文件、打包、启动、验证日志）
• 前端部署（修改 API 地址、打包、Nginx 配置）
• 常见问题排查（端口被占用、数据库连不上、刷新 404、jar 包启动失败）
• 默认账号说明（管理员账号/密码、测试用户账号）

文档里每条命令都要写完整，不要写"输入打包命令"而不写命令本身。这篇部署文档不仅能帮助你复现整个系统，放到简历的项目描述里也是实打实的加分项。

7. 论文、源码与答辩：毕业设计交付物的组织方式

7.1 论文结构怎么安排：从摘要到展望的写法思路

论文这块，我梳理一下我当时用下来很顺的结构，供你参考。第 1 章绪论：农产品预售背景与意义、国内外研究现状、本文的主要工作——这一段别写太长，重点是把"预售能解决农产品滞销问题"这个逻辑讲顺。第 2 章相关技术：把 SpringBoot、Vue、MySQL、前后端分离架构各写一小节，注意不要变成网上教程的复制粘贴，要结合你系统里具体用到的特性来写。第 3 章系统需求分析：功能性需求（用户、商品、活动、订单、管理等）、非功能性需求（性能、安全、易用性）、用例图（可以用 PlantUML 画，Word 里贴图片）。第 4 章系统设计：总体架构、功能模块设计、数据库设计、接口设计、时序图。第 5 章系统实现：每个模块的实现思路加截图，代码核心片段放一小段，不要整页贴代码。第 6 章系统测试：测试环境、测试用例表格、测试结果分析。第 7 章总结与展望。

数据库设计这一章是论文里最像"干货"的部分，E-R 图加表结构说明两份料放进去，篇幅马上就有基础了。接口设计部分我建议用一张表格列出所有核心接口的路径、方法、参数和返回值，答辩时老师翻到这里能快速了解系统全貌。

7.2 答辩演示的路径设计：按业务闭环走，不要按页面走

答辩时最容易犯的错误是打开系统后从首页开始一个个点页面。正确做法是按一条业务闭环来演示：注册登录 -> 管理员后台添加预售活动 -> 普通用户浏览预售活动 -> 下单 -> 模拟支付 -> 查看订单状态 -> 管理员发货 -> 用户确认收货 -> 订单完结。整个流程走完，系统里每个模块都覆盖到了，而且老师能直观理解预售的完整业务逻辑。

然后在演示过程中，我会特意找机会讲两个点：一个是库存扣减的原子性操作设计，另一个是预售活动状态的动态判断逻辑。这两个点就是你答辩的"技术护城河"，别的同学还在说"这个是查数据库显示出来"的时候，你已经在讲并发安全和状态机了，高下立判。

7.3 源码、数据库、部署文档怎么交付才算是"一份好交付物"

交付物通常要打包成压缩包，里面包含源码、数据库脚本、论文、部署文档。我的建议是目录结构长这样：

agri-pre-sale-project ├── backend // SpringBoot 后端源码 ├── frontend // Vue 前端源码 ├── sql // 数据库脚本（包括建库脚本、初始化数据脚本） ├── docs // 部署文档（markdown 或 PDF） └── thesis // 毕业论文（word 或 PDF）

数据库脚本要分成两个文件：schema.sql（建表语句）和 data.sql（初始数据）。初始数据里必须包含一个管理员账号和一个测试用户账号，以及几条商品和预售活动数据，这样拿到交付物的同学导入数据库后，系统直接就能跑，不用自己造数据。我还建议在项目根目录放一个 README.md，写清楚快速启动步骤，三分钟跑起来的那种。很多老师评阅时会先看这个文件，体验好了印象分会高不少。

源码部分注意不要把 target、node_modules 这些目录打进去，既大又没用。提交前清理一下，Git 里配上 .gitignore。

7.4 拓展方向：如果你想让这个项目再往上走一步

如果时间充裕，这套系统还可以加不少东西：预售时增加"定金膨胀"玩法，下单时配合优惠券，订单完成后接入评价体系，后台增加数据统计图表（用 ECharts 展示各品类预售占比），物流信息追踪。我个人的看法是，正文中不要贪多，把这些写进"总结与展望"那一章作为后续工作，答辩时老师如果问你"系统还能怎么改进"，你直接把这段讲出来，就是一个非常完整的回答。

最后再分享一个我自己的体会：做毕设最怕的不是不会，而是闷着头写代码，写到一半发现方向错了，回头改就是伤筋动骨。这套系统我在做之前花了差不多一个星期画原型、定表结构、理接口清单，真正写代码反而很快。你如果打算复制这个项目或者参考它做自己的毕设，我建议你也不要急着写代码，先把表结构和接口清单列出来，再动手。省下来的时间，都是你的。