很多做毕业设计的同学，选"地方特产商城"这个题目的时候，第一反应都是："不就是商品列表加购物车嘛，电商系统，网上模板一大把。"结果真正动手才发现，特产这个前缀带来的业务细节，比普通商城要多出一大截——产地、时令、保质期、运费规则、配送状态，每一个都能让你的代码量翻倍，也每一个都是答辩时拉开差距的得分点。
这篇文章我就按实际带过类似项目的经验，完整拆一个基于SpringBoot的区域特色产品电商交易平台该怎么落地。从业务边界、技术选型、数据库设计，到下单和配送的核心链路，再到大伙儿最容易翻车的几个现场，一次讲完。适合正在做毕设、准备做毕设、或者想拿这个题目练手的人。
1. 特产电商毕设的需求盘点：先把业务边界划清楚
很多人拿到题目第一件事是建工程，这是典型的顺序错误。特产商城虽然挂着电商的名，但和普通标品电商在业务规则上差得挺多，先盘清楚做哪些、不做什么，后面才不会返工。
1.1 卖特产的系统和卖手机的系统，差在哪
普通电商的商品是全国统一的大路货：手机、图书、数码配件，价格透明、物流从中央仓发、没有地域属性。特产电商恰恰相反，它的商品天然带有三个标签：产地、时令、保存条件。
- 产地属性：五常大米必须在五常，赣南脐橙必须写赣南，这个"地域标签"是商品的核心卖点。用户在首页可能不会直接搜某件商品，而是先选一个产地，再看这个产地有什么特产。
- 时令属性：很多特产是季节性的。阳澄湖大闸蟹只有秋天有货，春茶清明前是最贵的时候。系统里必须支持商品的上下架时间和季节标记，否则商品过了季还挂在首页，很不专业。
- 保存条件：茶叶怕潮、生鲜要冷链、腊味要真空包装。这决定了订单配送时要用常温还是冷链，也直接影响到运费计算。
所以在你画用例图之前，先问自己一句：我的系统要不要体现这些特产特性？要，那商品表里就不能只有普通商城那套字段；不要，那你做的就只是个普通商城，题目里的"区域特色"四个字答辩时完全立不住。
1.2 用户端、商家端、管理员端的核心功能矩阵
特产商城在毕设里通常做成三类角色，功能边界建议按下表来切：
| 角色 | 核心功能 | 说明 |
|---|---|---|
| 用户端 | 注册登录、商品浏览、按产地/分类筛选、购物车、订单结算、模拟支付、收货地址管理、订单查询 | 这是主流程，必须完整跑通 |
| 商家端 | 商品管理、库存管理、处理订单（发货）、更新配送状态、查看订单明细 | 毕设中可与管理端合并，但逻辑上建议单独拆service |
| 管理端 | 用户管理、商品分类管理、产地管理、订单总览、数据统计 | 管理员是全局视角，所有角色的数据都能查 |
如果你是单商户模式，也就是只有一个"本店"自己在卖特产，那商家端和管理员端可以合并成一个后台，操作的人只有管理员。如果你做成平台模式，多商家入驻，那就要多做一层商家与商品的关联关系，工作量直接上一个台阶。
这里我给个实在建议：毕设选单商户模式就够用了。多商家入驻涉及店铺审核、商家结算、平台抽成，这一套做完，已经顶得上一个学期的期末大作业了，作为毕设反而容易做不透。
1.3 从评分角度圈定"必须做"和"可选做"
我见过不少把精力花在炫技上的项目：接了一堆第三方SDK，做了人脸识别登录、做了大屏可视化，结果核心的购物车下单流程反而有bug。这是本末倒置。
毕设评分最看重的，永远是业务逻辑的完整性和技术点的合理性。按这个原则排序：
- 必须做：注册登录、商品浏览与筛选、购物车、下单结算、模拟支付、订单状态流转、配送地址管理。
- 建议做：产地维度浏览、运费规则配置、后台商品上下架、库存管理、订单发货处理。这几项是特产题目的差异化加分点。
- 可选做：优惠券、评论、收藏、数据统计图表、支付沙箱对接。这些属于锦上添花，有余力再做。
一句话，先把"用户能买、商家能发、订单状态能流转"这条主线跑通，你再考虑往上面加东西。
2. SpringBoot技术选型与项目骨架：为什么这套组合最稳
说完了业务边界，再落到技术上。这个题目用SpringBoot几乎是标配，但为什么是它、配套选什么，还是值得花点篇幅讲清楚，答辩时老师问"你为什么要用这个技术"，你得答得出来。
2.1 为什么是SpringBoot而不是SSM或者其他框架
老一代的毕设项目爱用SSM（Spring + SpringMVC + MyBatis），但SSM最大的问题在于配置地狱：Spring配置、MyBatis配置、web.xml、各种XML扫描规则，光把环境跑起来就得折腾两三天。SpringBoot把这些约定俗成的配置全部自动完成，内嵌Tomcat，一个mvn spring-boot:run或者直接执行main方法就能启动，对毕设这种要在短时间拿出成果的场景非常友好。
另外SpringBoot生态成熟，Redis、MyBatis、文件上传、定时任务、接口文档这些常用的组件都能通过起步依赖快速接入，不会在整合环境上浪费时间。你跟答辩老师说"SpringBoot简化了SSM时代的配置复杂度，通过自动配置和起步依赖提升了开发效率"，这句话本身就是一个正确的技术认知。
2.2 技术栈清单与版本搭配
下面的组合是我在模拟项目里验证过多次的，稳定、文档多、踩坑少：
| 技术项 | 推荐选型 | 版本说明 |
|---|---|---|
| 后端框架 | SpringBoot | 2.7.x 配JDK8，毕设环境兼容性最好；3.x需要JDK17，除非你有把握，否则别赶新 |
| 持久层 | MyBatis-Plus | 3.5.x，自带分页插件和Service封装，写CRUD效率极高 |
| 数据库 | MySQL | 5.7或8.x均可，8.x推荐utf8mb4字符集 |
| 缓存 | Redis（可选） | 做购物车临时缓存、接口幂等、首页热点缓存时用 |
| 前端 | Vue2 + ElementUI 或 Thymeleaf | 前后端分离和模板渲染各有优势，下面细说 |
| 接口文档 | Knife4j | 自动生成Swagger文档，答辩时打开给老师看，很加分 |
| 工具库 | Lombok + Hutool | 简化实体代码，处理日期、加密、随机数等常用工具 |
前端到底用Vue前后端分离还是用Thymeleaf模板？我的观点是：如果你前端基础一般，用Thymeleaf + Bootstrap反而更稳，后端渲染不需要考虑跨域，部署也简单，一个jar包全搞定。如果你前端有基础，Vue分离式开发体验更好，管理后台用ElementUI做出来的表格、表单、弹窗档次高不少，但需要多处理一层跨域配置。两种都有大量队友踩过坑，看你更擅长哪一端。
2.3 项目目录结构与分层约定
工程结构建议按业务模块分包，而不是按技术层分包。很多人习惯建controller、service、mapper这种顶层包，商品、订单、用户全混在一起，后面前面一写多，找文件找到崩溃。按模块拆则清晰得多：
com.shop ├── common # 通用返回结果、异常处理、常量、工具类 ├── config # 配置类：跨域、文件映射、拦截器注册 ├── controller # 第一层入口，只做参数接收和路由 ├── service # 第二层业务逻辑，事务边界在这里 ├── mapper # MyBatis-Plus的Mapper接口 ├── pojo # 实体entity、VO、DTO、请求参数 └── modules # 各业务模块包 ├── user # 用户：登录注册、地址管理 ├── product # 商品：分类、产地、商品CRUD、检索 ├── cart # 购物车 ├── order # 订单：下单、支付、取消、确认收货 ├── delivery # 配送：运费规则、配送状态流转 └── admin # 后台：用户管理、数据统计分层约定上有一条红线：Controller里不要写业务逻辑，只负责拿参数、调Service、返回结果。Service里不要写SQL，只负责组合业务，真正查数据库的活全在Mapper。这样的一致性在写代码的时候可能觉得多了一层，但等到答辩前改需求、加功能、查bug，你会感谢这个结构。
3. 数据库表设计：特产属性、库存、订单和配送是怎么串起来的
数据库设计是整个系统最值得花时间的部分。表设计合理，后面代码写得顺；表设计不合理，写着写着就得返工。特产商城的核心表我认为是六张：用户表、商品表、分类/产地表、购物车表、订单主表、订单明细表，外加配送地址和配送规则各一张。
3.1 商品表：特产属性要落进字段里
商品表是关键中的关键，它决定你的系统能不能体现"特产"二字。一个建议的product表结构是这样的：
CREATE TABLE `product` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(120) NOT NULL COMMENT '商品名称', `subtitle` varchar(255) DEFAULT NULL COMMENT '卖点副标题', `main_image` varchar(255) NOT NULL COMMENT '主图路径', `images` text COMMENT '轮播图，逗号分隔', `detail` text COMMENT '详情介绍', `category_id` bigint(20) NOT NULL COMMENT '分类ID', `origin_id` bigint(20) NOT NULL COMMENT '产地ID，关联origin表', `price` decimal(10,2) NOT NULL COMMENT '销售价', `stock` int(11) NOT NULL COMMENT '库存', `sales` int(11) DEFAULT 0 COMMENT '销量', `status` tinyint(4) DEFAULT 1 COMMENT '1上架 0下架', `is_seasonal` tinyint(4) DEFAULT 0 COMMENT '是否时令商品', `seasonal_time` varchar(50) DEFAULT NULL COMMENT '上市时间描述，如：每年9-11月', `shelf_life` varchar(50) DEFAULT NULL COMMENT '保质期，如：冷藏7天', `shipping_type` tinyint(4) DEFAULT 0 COMMENT '0常温 1冷链', `weight` int(11) DEFAULT 0 COMMENT '单件重量(克)，运费计算用', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='特产商品表';产地单独建一张origin表，别在商品表里存一个"产地名称"字符串就完事。原因很简单：如果产地是独立的表，前端首页的"按地域逛特产"、后台的"按产地统计销量"、配送模块的"按产地计算运费"全都能直接JOIN查询，数据是活的。如果你存字符串，这些需求全都做不了，将来加需求等于重写。这个点也是答辩时的一个亮点，可以重点讲你对地域维度设计的思考。
3.2 订单主表 + 订单明细表：为什么必须拆两张
只要你的订单可能包含多个商品，就必须拆主表和明细表。
order主表存一笔订单的汇总信息：订单号、用户ID、总金额、运费、实付金额、订单状态、收货人姓名、电话、地址、下单时间。order_item明细表存这笔订单里每个商品的信息：商品ID、名称、主图、单价、数量、小计。
这里有一个特别值得讲的细节：明细表里要冗余商品名称和商品图片。什么意思？就是下单那一刻，把商品当前的名称、图片、单价都复制一份存进order_item。为什么？因为商家可能改了商品名字、换了图片、调整了价格，但你的历史订单不能跟着变——用户查看他三个月前的订单，看到的应该是当时买的东西的样子，而不是现在改版后的样子。这是电商系统里非常经典的"快照"思想，写在论文里是一个很好的设计说明。
3.3 购物车和收货地址：两个容易被低估的表
购物车表有两种做法，临时型的存Redis、持久型的存MySQL。毕设建议用MySQL持久型购物车，逻辑简单且不丢数据：
CREATE TABLE `cart` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `product_id` bigint(20) NOT NULL, `quantity` int(11) NOT NULL DEFAULT 1, `checked` tinyint(4) DEFAULT 1 COMMENT '是否勾选结算', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_product` (`user_id`,`product_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='购物车表';注意这个唯一键uk_user_product很关键。它保证同一个用户对同一个商品只有一条购物车记录，用户再次加入购物车时做的是数量累加而不是插入新记录，这就是数据库层面防重复的唯一约束。
收货地址表shipping_address就比较常规了，用户ID、收货人、电话、省市区、详细地址、是否默认地址。默认地址的逻辑是：当把一条地址设为默认时，需要把该用户其他地址的is_default都清掉，再设这一条为默认，这是事务内的两步操作，代码里别落掉。
3.4 配送模块的数据支撑：运费规则表与配送状态
特产配送和标品不太一样，运费不能统一写死"满99包邮"。因为特产里面生鲜要冷链，冷链贵；腊味要真空，真空有包装费；产地远不远也影响运费。所以建议单独设计一张delivery_rule运费规则表，按区域+配送方式配置：
| 字段 | 说明 |
|---|---|
| region_id | 配送区域ID，如华东、华南、东北 |
| shipping_type | 0常温 / 1冷链 |
| first_weight | 首重（克） |
| first_fee | 首重费用 |
| extra_weight | 续重（克） |
| extra_fee | 续重费用 |
结算时根据收货地址所在区域、订单商品总重量、是否需要冷链，计算出运费。这个运费计算逻辑是特产题目里少有的、可以写进论文的"业务算法"，比一级分类二级分类那种流水账有价值得多。
4. 核心交易流程实现：从商品详情到订单配送的完整链路
业务边界和技术骨架都确定了，就可以聊最核心的代码实现了。我按一条完整的主链路讲：用户浏览商品 → 加入购物车 → 结算下单 → 模拟支付 → 商家发货 → 配送状态流转 → 用户确认收货。
4.1 下单流程的Service骨架与事务控制
下单是交易系统的核心，涉及多张表操作，必须包在一个事务里。经验不足的同学容易把下单逻辑拆到Controller里一步步调用，真出问题时没法回滚。正确姿势就是在Service方法上打@Transactional：
@Override @Transactional(rollbackFor = Exception.class) public OrderVO createOrder(OrderCreateDTO dto) { // 1. 校验收货地址是否存在且属于当前用户 ShippingAddress address = addressService.getById(dto.getAddressId()); if (address == null || !address.getUserId().equals(currentUserId())) { throw new BizException("收货地址不存在"); } // 2. 校验购物车中的商品并计算商品金额 List<CartItemVO> cartItems = cartService.listCheckedItems(currentUserId()); if (cartItems.isEmpty()) { throw new BizException("请选择要结算的商品"); } // 3. 锁定库存（条件扣减，防止超卖） for (CartItemVO item : cartItems) { boolean success = productService.deductStock(item.getProductId(), item.getQuantity()); if (!success) { throw new BizException("商品[" + item.getProductName() + "]库存不足"); } } // 4. 生成订单主表和明细表 Order order = new Order(); order.setOrderNo(generateOrderNo()); // ... 计算订单金额、运费、实付金额 orderMapper.insert(order); for (CartItemVO item : cartItems) { OrderItem orderItem = new OrderItem(); // ... 拷贝商品快照信息 orderItemMapper.insert(orderItem); } // 5. 清空购物车中已结算的商品 cartService.removeCheckedItems(currentUserId()); return buildOrderVO(order); }这段代码看下来可能觉得平淡，但它藏着三个关键决策：扣库存放在生成订单之前、所有写操作包在同一个事务里、任何一步失败都会整体回滚。答辩时如果能讲清楚"为什么先扣库存再生成订单"，面试官一般就会认定你理解交易链路。
4.2 库存扣减的SQL写法，决定你踩不踩超卖的坑
很多同学扣库存的逻辑是这样写的：
Product product = productMapper.selectById(id); if (product.getStock() >= num) { product.setStock(product.getStock() - num); productMapper.updateById(product); }这个写法在单线程下没问题，但一旦两个并发请求同时读到同样的库存，然后再分别更新，库存就可能变成负数，这就是经典的超卖问题。正确的做法是把"判断库存够不够"和"扣减库存"合并成一条带条件的UPDATE：
@Update("UPDATE product SET stock = stock - #{num} WHERE id = #{id} AND stock >= #{num}") int deductStock(@Param("id") Long id, @Param("num") Integer num);这条SQL执行后返回的影响行数，如果为0，说明库存不够，直接抛异常让事务回滚。这样数据库本身通过行锁保证了同一时刻只有一个请求能扣成功，从根上避免了超卖。这个知识点在简历里写"解决并发库存扣减问题"，是可以拿出来现场讲细节的。
4.3 订单状态机，把状态流转做成一张表
订单不是用一个status字段存个数字就完事，你得设计好状态和操作之间的流转关系。推荐用状态枚举：
| 状态 | 含义 | 可以进行的操作 |
|---|---|---|
| 0 | 待支付 | 用户模拟支付、用户取消订单 |
| 1 | 待发货 | 商家发货 |
| 2 | 配送中 | 商家/配送员更新配送节点 |
| 3 | 已完成 | 无（可评价） |
| 4 | 已取消 | 无 |
这里要注意，不是所有状态之间都能任意跳转。一个已取消的订单不能突然变成配送中，一个已完成订单不能又变成待发货。代码里建议写一个状态流转变更服务，每次变更都校验"当前状态能不能执行这个操作"，而不是让每个业务方法自己去改状态字段。这样订单数据的可信度才有保障，答辩演示的时候老师也可能故意问：取消的订单能不能发货？你就能答：我在代码里做了流转校验，不允许非法状态变更。
4.4 模拟支付和配送状态：不接真实接口也能把链路走通
很多同学纠结要不要接支付宝沙箱。我的建议是：可以接，但不是必须。毕设重点在于业务闭环，支付环节完全可以做成模拟的：
- 下单后订单状态为"待支付"，前端展示一个"模拟支付"按钮。
- 用户点击后，调用后端支付接口，后端生成一条支付记录、修改订单状态为"待发货"。
- 这个接口里面你可以模拟一笔支付流水号、支付时间，入库保存。
如果你的确想接支付宝沙箱，就把对接代码放在一个payService里，通过策略模式区分"模拟支付"和"真实支付"，答辩时主要演示模拟支付，话术上说明"我已经预留了真实支付接口的扩展点"。这比硬接一个沙箱又调不通要体面得多。
配送环节同理。不用接真实的快递API，自己设计一张配送记录表，由商家在后台逐级更新：已出库 → 运输中 → 派件中 → 已签收。每个更新操作都往配送记录表里插入一条时间线，用户在前端就能看到类似"10:24 您的包裹已到达【XX转运中心】"的效果。能做到这个程度，订单配送系统的完整性就已经超出绝大多数同类毕设了。
5. 做毕设最容易翻车的几个现场：库存并发、图片上传和地址解析
代码写通之后，接下来是运行和调试阶段。我把这些年看别人踩过、以及我自己踩过的坑集中讲一下，这几个问题几乎每个做SpringBoot商城的人都会撞上。
5.1 库存超卖：从现象到根因的完整排查思路
假设你已经按上面说的条件扣减写了SQL，还是出现了超卖，怎么查？
首先，打开MySQL命令行，执行：
SHOW ENGINE INNODB STATUS;重点看事务隔离级别和锁等待部分。排查思路通常分三步：
- 是不是Service方法前忘了加
@Transactional？没有事务包裹时，每条SQL自动提交，先查询再更新的窗口期被无限放大，超卖几率极高。检查方法：看方法调用链上是否有人绕过了Service直接调Mapper。 - 是不是扣减SQL的条件写错了？最常见的是
WHERE id = ?漏了AND stock >= #{num}，变成了无条件扣减，负数照样扣。检查方法：把SQL打印出来，看实际执行的语句。 - 是不是走了缓存里的库存数据？如果商品详情页展示了Redis里的库存，而下单扣减的却是数据库的库存，两边数据不一致，用户看到的库存是5，实际下单时数据库可能已经是0。检查方法：确认Redis只用于"读展示"，所有写操作都以数据库为准。
这三个方向排查完，超卖问题基本能定位。经验之谈：毕设项目里超卖问题九成是前两个原因，第三个一般不会出现，因为做到Redis缓存商品库存这个深度的人不太会犯这种低级错误。
5.2 图片上传成功但页面加载不出图片：路径映射的坑
商品图片上传是个高频翻车点。现象是：上传接口返回了保存成功，文件也确实写在磁盘的某个uploads目录下，但浏览器访问http://localhost:8080/upload/xxx.jpg就是404。
原因很简单：Spring Boot默认不会把磁盘上的uploads目录暴露成可以HTTP访问的静态资源。你在项目里看到的src/main/resources/static下的东西才会被当成静态资源处理，而业务上传的文件是动态写入磁盘的，不在classpath里。
解决办法是在配置类里加一个虚拟路径映射：
@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath = "file:" + System.getProperty("user.dir") + "/upload/"; registry.addResourceHandler("/upload/**").addResourceLocations(uploadPath); } }注意System.getProperty("user.dir")拿的是当前工作目录，在IDEA里运行和用java -jar运行时，这个路径很可能不一样。更稳妥的做法是把上传目录写进application.yml配置文件里，用@Value注入，部署换机器时只改配置不改代码。
还有一个坑是Windows下用反斜杠路径，存到数据库后网页上拼URL时反斜杠处理出错。建议统一用正斜杠/保存路径，存相对路径/upload/2025/03/xxx.jpg，前端直接拼域名访问即可。
5.3 用户双击下单按钮，生成了两笔订单：幂等性的问题
下单接口没有做幂等处理时，用户快速点了两下"提交订单"，前端发出了两个一模一样的请求，后端就会生成两笔订单、扣两次库存。解决方法有两个层面：
前端在点击提交后立刻把按钮置灰，加上loading状态，这是第一道防线。但前端防不住不怀好意的直接调用接口，所以后端也要做。一个简单方案：前端在进入结算页面时，向后端申请一个orderToken，下单请求必须携带这个token，后端接到请求后先校验token是否存在，存在则删除并用它继续下单；不存在则直接拒绝。这个token建议存Redis，设置5分钟过期。用数据库唯一索引也能做，但Redis的方案表达能力更强，也能在论文里写一笔。
5.4 接口没做权限校验：一次"无意间"看到别人订单的尴尬
很多商城项目Controller里的查询订单接口长这样：
@GetMapping("/order/list") public Result listOrders(Long userId) { return Result.success(orderService.listByUser(userId)); }前端传什么userId就查什么userId。如果没登录的人构造一个请求，传别人的userId，就能看到别人的订单列表。这就是越权漏洞。
修复思路是：不从前端参数里拿当前用户身份，而是从会话里取。登录成功后把用户ID存到Session或者生成一个Token，后端在拦截器里统一解析出当前登录用户ID，放到ThreadLocal里，订单查询一律用ThreadLocal里的用户ID，前端传的userId参数直接忽略。
用户登录 → 后端签发Token/写入Session → 请求进入拦截器 → 解析出当前用户ID → 放入上下文 → Service只认上下文里的ID把这个逻辑写成代码不难，但很多同学压根没这个意识，非得等演示的时候被老师发现才慌。
6. 从"系统能跑"到"答辩能过"：演示准备和论文撰写的经验补充
最后一部分，聊点代码之外但决定项目成绩的事。很多人的系统功能是全的，但答辩现场演示翻车、论文里体现不出工作量，最后分数不理想，非常可惜。
6.1 演示数据怎么造，才能让系统看起来"有内容"
答辩演示时最忌讳打开一套空荡荡的系统。提前造好一批演示数据，是性价比最高的准备工作。
我的建议是准备这些数据：
- 商品：8到15个，覆盖3到5个产地，每个商品都有清晰的主图和详情图。
- 订单：至少6到8笔，分布在不同的状态：待支付、待发货、配送中、已完成、已取消。这样老师想看哪个状态你都能现场调出来。
- 用户：一个普通用户账号、一个管理员账号，密码简单好记，比如
admin/123456，演示时不至于手忙脚乱输错。
演示的顺序也要提前走两遍：首页 → 按产地筛选 → 商品详情 → 加入购物车 → 结算下单 → 模拟支付 → 切换管理端发货 → 切回用户端看配送状态。这条链路完整走一遍，比你面面俱到地讲所有功能有用得多，因为评委看到的是业务闭环，而不是零散的功能点。
6.2 论文里最能体现工作量的四个章节
写论文不用把每个功能都写一遍，那样会写成流水账。我建议重点打磨这四个地方：
- 系统需求分析：画好用例图、功能结构图、主要业务流程活动图。评审老师翻论文第一眼看的就是图多不多、画得规不规范。
- 数据库设计：放ER图、核心表结构说明、字段注释。把你对特产属性、订单快照、运费规则表的设计思路写清楚，这是工作量的硬证据。
- 核心功能详细设计：选下单、库存扣减、配送状态流转这三个模块，画时序图和关键代码片段，重点讲设计理由。
- 系统测试：写测试用例表格，包括正常流程、异常流程、并发场景。并发下单测试能截图就截图，库存不超卖的结果截图放在论文里非常有说服力。
写论文时记住一个原则：少贴整页代码，多讲设计思路。评审老师不会逐行看你的代码，但会通过你的设计描述判断你是真懂还是在拼凑。
6.3 还能往哪些方向扩展：点到为止，别贪多
如果你的核心链路已经很稳，想再加点亮点，可以考虑这几个方向：
- 接入对象存储服务，把商品图片从本地磁盘迁移到云端，顺便讲讲"本地存储的局限性和云存储的优势"。
- 用Redis给首页热点商品做缓存，降低数据库压力，这个点可以和性能优化呼应。
- 接入真实的物流查询API，把模拟配送升级成输入快递单号自动查轨迹。
- 加一个简单的销量统计接口，后台用图表展示各产地的订单占比。
但我要泼一盆冷水：扩展方向点到为止即可。你加一个功能，就得保证它不出错，并且能讲清原理。一个核心链路完美、附带两个亮点功能的系统，远胜过一个什么功能都有但全是半成品的系统。
做毕设这件事，最深的体会是：它考察的不是你堆了多少功能，而是你有没有把一个完整的业务逻辑想透、做透。信息化特效、接口权限、库存并发、配送流转，这些东西单独拆开看都不难，但串起来还能跑得干净利落，就是真功夫。最后分享一个小技巧：写代码的时候习惯性地打上清晰的注释和日志，答辩现场一旦被问到某个分支为什么这么写，你能直接找到对应的位置讲出来，那种从容的状态，比背稿有用得多。
