做毕业设计选了个电商系统，还是带地域特色的那种——“基于Web技术的海南水产品销售系统”。这个题目看着普通，但真正动手之后你会发现，一套完整的电商系统从前台商品浏览到后台订单管理，涉及的技术点远比想象中多。这篇文章我打算把这个项目的选题思路、技术选型、数据库设计、核心模块实现和踩过的坑全部梳理一遍，给正在做同类型课题的同学一份可以直接参考的实操手册。
先交代一下背景：我是某高校计算机专业的应届生，做这个题目时前后花了两周左右，技术栈用的是现在毕设最主流的组合——Spring Boot + MyBatis-Plus + MySQL，前端用的是Vue + Element UI，另外配了拦截器做登录校验。整套源码打包后两百多MB，包含数据库脚本、前端工程、后端工程和一份完整的论文文档，也就是标题里那个14644编号对应的资源包。接下来我按从设计到实现的顺序，把整个项目的关键环节逐一拆开讲。
1. 项目整体设计与需求拆解
1.1 为什么选“海南水产品”这个方向
毕设题目的选择其实挺讲究的。我见过太多人一上来就做“XX管理系统”，用户管理、商品管理、订单管理三板斧，做完发现所有模块都长得一模一样，答辩的时候导师问一句“你这个系统解决了什么实际问题”就卡住了。
选“海南水产品”这个方向，核心逻辑有三个。第一，电商系统是管理信息类项目的经典载体，天然涵盖用户端和后台端两套完整流程，功能密度高，方便展示自己的工程能力。第二，海南水产品有很鲜明的地域特征——热带水产、鲜活配送、季节性强，这些特征能自然引出物流方案、冷链提示、退货规则等业务细节，让系统不只是“空壳增删改查”。第三，选题本身带有场景故事感，论文里的需求分析、可行性分析都容易写出内容，答辩时也更好讲。
实际开发时，我把它拆成了前台商城和后台管理两个大端。前台主要服务普通用户：注册登录、浏览商品、按分类筛选、关键词搜索、商品详情、加入购物车、提交订单、模拟支付、个人中心（地址管理、订单查看）。后台服务管理员：商品类别管理、商品信息管理（上下架、库存、价格）、订单处理（发货、查看详情）、用户管理、数据统计（简单的销量排行和销售额柱状图）。
功能清单列完之后，我给自己定了一条红线：所有功能必须围绕“让用户能完成一次真实的水产品购买闭环”来设计，不做多余的装饰功能。这条原则在后期帮我挡掉了很多没必要的返工。
1.2 技术选型：用最稳妥的组合拿高分
技术选型这块，我直接说结论：Spring Boot + MyBatis-Plus + MySQL + Vue + Element UI，是当前高校毕设场景下最不容易翻车的组合。
为什么这么选？后端用Spring Boot是因为它零配置起步、内嵌Tomcat，一个java -jar就能跑起来，方便答辩现场演示。MyBatis-Plus比原生MyBatis少写大量XML映射，分页插件和代码生成器对工期紧张的毕设来说简直是救命工具。前端选Vue + Element UI则是因为组件库成熟，表格、表单、弹窗、分页这些后台管理页面最常见的元素全是现成的，套一套就能出效果。
有些同学喜欢在这个基础上强行引入Redis、RabbitMQ、微服务网关，我的建议是：除非你论文里有明确的非用不可的理由，否则别加。毕设考察的是完整度和逻辑自洽，把单体架构做到高质量完成，比半吊子分布式更拿分。我这个项目里唯一引入的中间件就是MySQL，连Redis都没加，因为业务量级根本不需要，加了反而是负担。
注意：选题和选型阶段是最容易被忽略但最重要的阶段。我见过太多人先下载源码再反推论文，结果功能和代码对不上，答辩时漏洞百出。正确做法是先想清楚业务场景，再根据场景确定功能，最后才是选技术和找参考。
2. 核心技术方案与关键实现
2.1 数据库设计：从用户到订单的完整建模
数据库表是整个项目的骨架。我设计的时候遵循了一个原则：电商领域有成熟的数据模型可以参考，但一定要结合“水产品”这个业务场景做调整。
最终落地的数据表一共有七张核心表：
| 表名 | 作用 | 关键字段 |
|---|---|---|
| sys_user | 用户表（含管理员） | username, password, role |
| address | 收货地址表 | user_id, receiver, phone, address |
| category | 商品分类表 | name, sort |
| product | 商品表 | category_id, name, price, stock, image, detail |
| cart | 购物车表 | user_id, product_id, quantity |
| orders | 订单主表 | order_no, user_id, total_amount, status, create_time |
| order_item | 订单明细表 | order_id, product_id, quantity, price |
说几个容易被忽略的设计细节。
第一，用户表一定要加上角色字段。我用了一个简单的int类型区分管理员和普通用户（0表示用户，1表示管理员），后台接口通过拦截器判断角色来决定是否放行，比单独建一张角色关联表简单得多，对于这个体量的项目完全够用。
第二，订单编号不要用自增ID直接暴露给用户。我在生成订单时用了时间戳加随机数的方案，格式类似20250612001，这样既能保证唯一性，看起来也比较专业。
第三，订单状态字段我参考了电商常见的状态流转：待付款、待发货、待收货、已完成、已取消。代码里用int类型存储，通过一个常量类封装，避免魔法值散落在各个层里。
数据库这块还有一个重要选择：要不要做外键约束。我的答案是——不要。物理外键在删除和更新时会带来连锁约束，尤其毕设后期要调整数据时非常麻烦。正确的做法是在实体类层面维护逻辑关联，由Service层保证数据的完整性和一致性。
2.2 后端分层与接口设计思路
后端代码我严格按照Controller-Service-Mapper三层来组织。也许有同学觉得这种分层老套，但它确实是最清晰的职责划分：Controller只做参数接收和结果封装，Service专注业务逻辑，Mapper只负责数据库操作。
接口设计上采用RESTful风格，统一返回Result对象，结构包含code、message、data三个字段。所有Controller返回的都是这个Result，前端通过axios拦截器统一处理code状态，200表示成功，其他状态弹出错误提示。这样写的好处是前端不用为每个接口单独写错误处理分支。
还有一点容易被忽视，就是全局异常处理。我写了一个GlobalExceptionHandler，用@RestControllerAdvice注解捕获所有未处理的异常，统一封装成Result返回。不要小看这个类，它能让你的代码在答辩演示时即使出现预料之外的错误，也不会把一堆堆栈信息直接砸在屏幕上——那些东西很影响印象分。
会话管理我用了传统的Session方式，登录成功后把用户对象放进去，拦截器每次请求检查Session中是否存在用户。这里有个心得：不要把密码字段放进Session对象里。我踩过一次坑，后来改成只放用户ID和用户名，安全性和传输体积都更合理。
2.3 购物车和订单闭环的业务逻辑
购物车功能的实现本身不难，就是往表里插记录，但有几个边界情况必须处理：用户重复添加同一商品时应该累加数量而不是新增记录；库存不足时不能加到购物车里；购物车结算时如果商品已经下架，要提示用户并阻止下单。
订单流程是核心中的核心，整个业务的完整链路是：用户从购物车勾选商品提交订单，系统校验库存和地址，生成订单主表和明细表，锁定库存，跳转到模拟支付页面，确认支付后订单状态从待付款变成待发货，管理员在后台点击发货进入待收货，用户确认收货后流程结束。
库存扣减这块，我采用的是下单即扣减库存。虽然严格来说支付确认后再扣减更准确，但鉴于这是模拟支付场景，下单扣减能有效防止超卖，逻辑也更好写。真正上线时可以用缓存加锁，但那种复杂方案在毕设里属于过度设计。
3. 实操过程与核心功能落地
3.1 环境准备与初始化步骤
本地开发环境我用的是一套最常见的配置：JDK 8、MySQL 5.7、IDEA 2023、Maven 3.8，前端用Node.js 16搭配Vue 2的Element UI版本。为什么选这么“古早”的组合？因为稳定，网上资料多，遇到问题搜一下遍地都是答案。Vue 3虽然已经是大趋势，但Element Plus的文档和示例在部分场景下没有Element UI那么顺手，毕设求稳优先。
项目初始化建议按这个顺序来：
- 先在MySQL里创建数据库，字符集选utf8mb4，然后导入项目自带的sql脚本。很多人忽略字符集，导致后面插入中文变成乱码，排查半天才发现是字符集的问题。
- 后端工程用IDEA打开，配置Maven仓库指向本地或阿里云镜像，刷新依赖。这个步骤可能比较慢，耐心等就行。
- 修改application.yml里的数据库连接配置，这是唯一必须动的地方。
- 启动后端，确认控制台不报错，端口默认8080没有被占用。
- 前端工程用命令
npm install安装依赖，然后npm run serve启动开发服务器，Vue项目默认端口8080会和后端冲突，记得在vue.config.js里改成8081并配置代理转发。
最后一步特别重要。前后端分离项目一定要在开发环境配好跨域代理，我采用的是Vue脚手架自带的proxy配置，把请求转发到后端地址，这样前端代码里所有请求路径都写相对路径，部署和演示时都不会因为地址问题翻车。
3.2 商品展示与搜索功能实现细节
商品展示是用户进到系统的第一印象，做得是否顺畅直接影响整体体验。首页我规划了几个区块：轮播图展示爆款水产、分类导航、新品推荐和热销榜单。这些数据都来自product表，通过在product表里增加两个字段——is_hot和is_new，用简单的标记位控制展示逻辑，不需要额外的表。
列表页的关键是分页和筛选的组合。我使用MyBatis-Plus的Page对象做物理分页，配合LambdaQueryWrapper构建动态查询条件。这里有个细节：当用户选择分类、输入关键词、或者按价格排序时，这些条件要能叠加生效。所以查询方法接收一个包含所有筛选条件的DTO对象，用条件构造器逐层追加条件，最后统一分页返回。
商品详情页除了基础信息展示，还需要处理两个特殊情况。第一，图片加载：我用的是本地文件上传方案，上传目录配置成项目外的绝对路径，通过自定义静态资源映射暴露访问地址。第二，库存状态展示：如果库存为0，详情页要明确显示缺货，且置灰加入购物车按钮。这个需求看似简单，但很容易在前后端联调时漏掉，导致用户把没货的商品塞进购物车。
3.3 订单模块与模拟支付流程
订单模块的代码量在全部业务代码中占比最高，因为涉及事务和多表联动。创建订单时，要同时完成三件事：读购物车数据生成订单明细、更新主表信息、扣减库存。这三件事必须在一个事务里执行，任何一步失败都要整体回滚。我用的是Spring的@Transactional注解，在方法上声明即可。
事务这块有个容易忽略的点：事务不能直接加在Controller层的方法上。的确有同学为了方便直接在Controller加注解，但这会让所有绕过Service的直接调用都失效，也破坏了分层规则。正确姿势是加在Service层的业务方法上，且要注意抛出异常时Spring才能触发回滚，千万不能把异常吞掉了。
模拟支付我做了个简单页面：订单提交成功后跳转到支付页面，展示订单编号和金额，点击“确认支付”按钮后调用支付接口，把订单状态从待付款改为待发货。虽然只是模拟，但流程上完全对齐了真实电商的支付体验。
后台订单管理是管理员端最高频的操作界面。我用Element UI的表格展示订单列表，支持按状态筛选和按订单号搜索，点击操作列的“发货”按钮弹窗确认，更新状态后刷新列表。为了防止管理员误操作，发货动作我加了一个二次确认的对话框，这个小细节在答辩演示时其实挺加分的。
3.4 权限控制与安全防护实操
权限控制用的是拦截器方案。我写了一个LoginInterceptor，实现HandlerInterceptor接口，在preHandle方法里检查Session中是否有登录用户。针对后台管理接口，还要额外校验用户的角色字段是否为管理员。
拦截器需要配置放行规则，否则会把登录页、注册接口、商品列表这些不需要登录就能访问的地址全部拦截掉。我的配置思路很简单：
- 放行：/api/user/login、/api/user/register、/api/product/**下的查询类接口、静态资源路径
- 拦截：/api/cart/下所有接口、/api/order/下所有接口、/api/admin/下所有接口
静态资源和接口的放行配置放在WebMvcConfigurer里统一管理。这里有个经验：配置完拦截器之后，最好把前后端所有请求路径过一遍，逐一排查是否放行正确，漏掉一个就会导致前端界面白屏或者数据加载不出来，而排查这种问题往往比写代码更耗时。
安全方面我还做了三件事：密码在数据库层做了加盐处理，前端登录时用MD5处理后再传输，后台的敏感操作接口记录操作日志。这个强度对毕设来说足够了，论文里可以留出一小节专门讨论安全设计。
4. 常见问题与排查技巧实录
4.1 开发期高频报错与解决方法
两周开发下来，我把遇到最多的几个问题整理成了一张速查表，分享出来希望能帮大家少走弯路。
| 现象 | 根本原因 | 解决方式 |
|---|---|---|
| 前端访问接口返回404 | 后端Controller的请求路径和前端请求路径不一致 | 两端统一好路径规范，前后端同时打开日志逐条核对 |
| 插入用户数据后中文乱码 | MySQL表或连接URL缺少utf8mb4配置 | 建库时明确字符集，application.yml连接串追加useUnicode=true&characterEncoding=utf8 |
| 项目启动端口被占用 | 上一个进程没关干净 | 用netstat -ano找到PID后kill掉，或直接改端口 |
| 前端请求报跨域错误 | 没有配置代理或后端没开CORS | 优先用Vue的proxy配置做转发，后端辅以CORS配置双保险 |
| 分页查询数据不准确 | MyBatis-Plus分页插件未配置 | 在配置类里添加PaginationInnerInterceptor，很多人栽在这里 |
| 登录后刷新页面就失效 | Session的cookie未设置有效期 | 在application.yml配置server.servlet.session.timeout |
| 上传的图片访问不了 | 本地路径没有做静态资源映射 | 写一个WebMvcConfigurer把上传目录映射成/upload/**访问路径 |
这里我要单独提一下MyBatis-Plus分页插件的坑。新版MyBatis-Plus从3.4.0开始，分页插件必须单独配置PaginationInnerInterceptor，否则Page对象里的total永远是0，数据也查不全。不少同学会用旧版的配置方式，在启动类上扫描拦截器，结果代码一直报错。这个配置类的代码我贴一下：
@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }4.2 答辩演示与文档准备的几条实在建议
代码能跑只是及格线，想要拿高分还得在演示和论文上下功夫。我总结了几条实测有效的心得。
演示顺序一定要精心设计。我的顺序是：先花一分钟讲清楚业务背景和系统价值，然后从前台用户注册开始，走完整条购买链路，再切换到后台处理订单和商品管理，最后打开数据库演示核心表的关联查询。整个演示控制在十分钟以内，流畅顺畅远比内容多更重要。
论文里最容易拉开差距的部分是需求分析和系统设计。很多同学的论文把需求分析写成泛泛而谈的功能列表，正确的做法是画清楚业务流程图、用例图、E-R图，并针对每个核心功能描述具体的流程和规则。比如订单状态流转，论文里用一个状态图加一段文字说明，评审老师一看就明白你是认真做过的。
还有一个容易被忽视的细节：源码注释和命名规范。评阅老师可能会直接打开源码翻一翻，类名全用拼音缩写、方法名一团乱麻的代码，即使功能都跑通了也会被扣印象分。我最后专门花了两小时统一了命名规范，把核心业务的方法都补上了中文注释，这属于投入小收益大的加分项。
最后提醒一句：拿到任何参考源码之后，一定要先看懂整体结构再开始改，直接在看不懂的代码上叠功能，最后只会越改越乱。我身边好几个同学的翻车案例，都是因为急着加功能，结果改出了各种意想不到的诡异Bug。
说实话，这个项目做完之后对我自己帮助最大的，不是那套前后端代码，而是完整走了一遍从选题、设计、开发到验收的整个流程。特别是数据库表的关联设计和对业务状态流转的理解，这些东西在课本上学十遍都不如在真实的项目里被坑一遍记得牢。
如果你正在为毕设选题发愁，或者已经拿到了这套源码但不知道从哪下手，希望这篇文章能给你一个清晰的路线图。我个人最大的建议就是：先吃透需求，再动手写代码，遇到问题不要慌，按照我上面整理的排查表一个个对照，大部分都能在半小时内找到原因。
