企业官网建设流程全解析

一年到头最折磨人的就是毕设选题，尤其像“基于SpringBoot的服饰电商展示与交易平台”这种看起来烂大街、实际要做出差异化很难的题目。我的建议是：别再把它当"增删改查系统"来做了，你完全可以把这套SpringBoot服装商城做成一个拿得出手的项目，关键不在功能多，而在于技术路线清晰、模块边界分明、每一处设计都说得出为什么。

这篇内容不光是写给你抄的，也把我踩了不少坑之后形成的完整思路整理出来。从需求拆解、技术选型、数据库设计，到前端如何和SpringBoot配合，再到实际开发中高频出现的报错和排查方法，都按毕设答辩的标准给你捋清楚。只要按这个思路走一遍，进度条基本就能走到80%以上。

1. 项目整体思路与需求拆解

1.1 先把角色和场景定住，功能边界就出来了

做商城系统前，最忌讳的就是一上来建表、写接口。你得先明确：这套系统是给谁用的？在什么场景下使用？

服装网站天然带有“展示”和“交易”两个属性，比普通电商系统多了一层时尚感的要求。我建议把用户划分为三种角色，对应不同的操作入口：

• 游客访客：浏览首页、看商品列表、看商品详情，但不能下单。这类用户对应的是“拉新”场景，不能一上来就逼着注册。
• 注册会员：能加购物车、能下单、能看个人订单记录、能改收货信息和密码。对应“转化”场景。
• 后台管理员：负责商品上下架、分类维护、订单状态流转、库存调整、轮播图管理。对应“运营”场景。

这样一拆，前后台功能就自然分开了。前台商城负责展示、搜索、交易入口；后台管理负责数据维护、订单跟踪和基础配置。很多毕设答辩被问“你的系统有哪些角色、各自做什么”，其实在需求分析阶段就把这个理清楚，后面根本不用慌。

1.2 功能模块拆解：前台展示和后台管理分开做

无论你的前台是用Vue单独部署，还是用Thymeleaf服务端渲染，功能清单都要列清楚。我按自己比较认可的方式给你一套标准功能清单，可以直接作为开题报告的功能模块章节：

前台用户端：

• 首页：轮播图推荐位、新品专区、热销单品展示、分类快捷入口
• 商品检索：按分类浏览、按关键词模糊搜索、按价格区间筛选、按上架时间/销量/价格排序
• 商品详情：多图展示、尺码与颜色选择、价格库存展示、商品参数详情
• 购物车：加入、修改数量、删除、批量结算、价格重新计算
• 订单：生成订单、在线支付模拟、取消订单、确认收货
• 个人中心：注册、登录、退出、个人信息修改、密码修改、收货地址管理
• 订单管理：订单列表、订单状态筛选、订单详情查看

后台管理员端：

• 管理员登录认证
• 商品管理：商品列表、商品发布、商品编辑、上下架、删除、库存调整
• 分类管理：商品分类的增删改查，支持二级分类
• 订单管理：订单列表、订单详情、订单发货、订单备注、退款处理
• 轮播图管理：首页轮播图片的更换和排序
• 用户管理：会员列表、禁用/启用账号、重置密码
• 数据概览：商品总数、今日订单数、总销售额、近期趋势

这样一套下来，技术覆盖点就非常全面：权限认证、文件上传、分页搜索、复杂状态流转、统计聚合都有。答辩时老师不管问你前台还是后台，你都能有东西讲。

1.3 常见理解误区：商城不是“商品表+订单表”那么简单的

很多同学把商城系统的设计逻辑简化成了两张表：一张商品表、一张订单表，订单里存商品名和价格就完事。这在实际开发中是有问题的，答辩时也容易被追问。

订单和商品之间必须通过“订单明细表”关联，而不是把商品信息直接冗余在订单表里。原因很简单：商品的价格和名称会变，如果直接复制到订单表里，后续商品涨价了，历史订单还是应该保持成交时的价格。所以订单表存的是订单级别的信息（总金额、状态、收货地址、用户ID、下单时间），订单明细表存的才是某一款商品的快照信息（商品ID、商品名称、单价、数量、小计）。这个细节是最能体现你有没有真正理解表结构设计的点。

另外，库存和商品的关系、轮播图与商品的关联、分类与商品的从属关系，都需要在设计阶段想清楚。宁可在前期多花一小时画表结构，也不要写了一半再重构。

2. 技术选型：为什么是SpringBoot，以及生态搭配怎么选

2.1 之所以选SpringBoot，不只是因为它“简单”

SpringBoot在Java后端开发中已经是事实标准了，毕设选它有几个肉眼可见的优势：

• 内嵌Tomcat，不用额外装容器，打包成jar一键运行，部署省事
• starter机制把常用功能的依赖和配置都自动封装好了，加依赖就能用
• 自动装配让数据源、事务、参数校验这些配置不再需要XML堆积
• 生态庞大，只要Java方向，几乎所有中间件都有对应的Starters

但在答辩时不要只说“SpringBoot开发效率高”这种套话，我给你一个更深层的说法：SpringBoot的核心价值在于自动配置和约定优于配置，它把Spring生态里复杂的Bean装配过程封装成自动配置条件判断，让我们专注于业务代码而不是框架整合。结合你的项目，比如spring-boot-starter-data-redis、spring-boot-starter-validation这些starter就能说明：开发中大部分功能只需要引入starter并写业务代码，框架层面的复杂逻辑由自动配置完成。

2.2 我的推荐组合：SpringBoot 2.x + MyBatis-Plus + MySQL + Vue3

技术选型我建议遵循“稳定优先、资料丰富、自己能驾驭”的原则。

后端主框架：SpringBoot 2.7.x。为什么要2.x而不是3.x？3.x要求JDK17，很多同学本机还在用JDK8，而且3.x后的javax包名变成了jakarta，网上大量老教程不适用，踩坑成本高。毕设求稳，用2.7版本最合适。

持久层：MyBatis-Plus。单表CRUD基本不用写SQL，内置分页插件，代码量直接砍掉一大截。默认驼峰映射、逻辑删除这些功能都很实用。关键是我觉得答辩时聊MyBatis-Plus的“条件构造器QueryWrapper实现动态SQL”比聊“写了一大堆XML”更有亮点。

数据库：MySQL 5.7或8.0。这俩都可以，注意SQL语法兼容即可。需要特别注意：如果本机装的是MySQL 8，驱动的URL需要指定serverTimezone参数，否则会报时区错误。

前端：如果是做前后端分离，选Vue3 + Element Plus不会错。要是你前端基础比较弱，或者时间紧张，也可以直接用Thymeleaf模板引擎，在SpringBoot里写页面，这样项目整体是单体应用，部署更简单。但从学习价值角度，我更推荐前后端分离方案，哪怕做得简单些，也比全用模板引擎强——因为能体现出你懂接口设计和跨域处理，这两点答辩时非常加分。

其他组件方面：如果你要做登录Token鉴权，可以用SpringBoot + JWT + Hutool工具包，Hutool负责生成和解析JWT特别方便，几行代码搞定。如果验证码需要，用Hutool的CaptchaUtil接口就行。文件上传如果人脸识别、OSS这些太复杂，那就先把图片存本地磁盘目录，后续可以再换对象存储，对毕设来讲完全够用。

2.3 项目结构怎么组织，答辩时才不慌

很多人喜欢把所有代码堆在controller、service、mapper三个包里，写的时候确实快，但答辩时展示项目结构就非常难看了。我推荐使用一个清晰的分层结构，同时体现Controller-Service-Mapper三层架构：

com.example.fashionshop ├── controller // 接收请求、返回结果 ├── service // 业务逻辑层，接口+实现类 │ └── impl ├── mapper // MyBatis-Plus数据访问层 ├── entity // 数据库实体类 ├── dto // 前端请求参数封装（登录参数、下单参数等） ├── vo // 前端响应数据封装（商品详情VO、订单VO等） ├── config // 配置类（跨域、拦截器、文件上传配置） ├── common // 公共类（统一返回结果、异常处理、常量定义） ├── utils // 工具类（JWT、文件存储等） └── FashionshopApplication.java

这样分层的好处是：职责明确，controller只做参数接收和结果返回，service做业务判断和事务控制，mapper只操作数据库。答辩时可以讲三层架构的职责划分，显得有设计感。尤其是Result统一返回结果类，一定要做，别用Map散装返回。

3. 数据库设计：商品、订单、用户这三块是核心

3.1 核心表结构和关键字段

数据库是这类项目的命脉。表结构设计得好，后面写业务代码就顺畅。我给出核心的几张表设计，你可以直接参考：

用户表（user）：

• id 主键，自增
• username 用户名，唯一索引
• password 密码，加密存储
• nickname 昵称
• avatar 头像URL
• phone 手机号
• email 邮箱
• gender 性别
• status 状态（0正常，1禁用）
• create_time 创建时间

商品分类表（category）：

• id 主键
• name 分类名称（比如“上装”、“下装”、“连衣裙”）
• parent_id 父分类ID，0表示顶级分类（支持二级分类）
• sort 排序号
• icon 分类图标

商品表（product）：

• id 主键
• category_id 分类ID，对应分类表
• name 商品名称
• subtitle 副标题/卖点描述
• main_image 主图URL
• detail 商品详细描述（富文本或长文本）
• price 当前售价（Decimal）
• original_price 划线原价
• stock 库存数量
• sales 销量
• status 上架状态（0下架，1上架）
• create_time 创建时间
• update_time 更新时间

这里要注意，商品的颜色和尺码是比较特殊的字段。如果只是简单做，可以直接用逗号分隔存到一个字段里，比如color="黑色,白色,灰色"，size="S,M,L,XL"。如果要做得更规范，就拆分出一个商品SKU表（product_sku），记录具体某个颜色某个尺码对应的库存和价格。毕设做简单方案够用，但如果想加分，SKU表才是难点和亮点。

订单表（orders）：

• id 订单号
• order_no 订单编号（用时间戳+随机数生成，对外展示用）
• user_id 下单用户ID
• total_amount 订单总金额
• status 订单状态（我建议定义为：0待付款、1待发货、2待收货、3已完成、4已取消）
• receiver_name 收货人姓名
• receiver_phone 收货人电话
• receiver_address 收货地址
• create_time 下单时间
• pay_time 付款时间
• deliver_time 发货时间
• receive_time 收货时间

订单明细表（order_item）：

• id 主键
• order_id 订单ID
• product_id 商品ID
• product_name 商品名称快照
• product_image 商品图片快照
• price 成交单价快照
• quantity 购买数量
• total_price 小计金额

购物车表（cart）：

• id 主键
• user_id 用户ID
• product_id 商品ID
• quantity 数量
• selected 是否选中（有些系统做结算勾选功能）

轮播图表（banner）：

• id 主键
• image 图片URL
• product_id 关联商品ID（点击跳转详情）
• sort 排序
• status 是否显示

3.2 字段类型和设计的关键细节

价格字段：必须用Decimal类型，不要用Float或Double。Java端对应的也得用BigDecimal。为什么？Float和Double是浮点数，有精度损失，商品价格和订单金额这种涉及钱的字段一旦精度出错就完蛋。MySQL里用DECIMAL(10,2)表示总长度10位、小数2位，够用了。

状态字段：用户状态、商品状态、订单状态都要加，这属于业务中间状态控制，不用枚举来写死。尤其订单状态，是这类系统的核心状态机，换季、退款这些业务都建立在订单状态基础上。

时间字段：用datetime类型，统一存服务器时间。Java实体用Date或LocalDateTime都可以，MyBatis-Plus对LocalDateTime默认支持，推荐用后者。插入时不要手动逐个set时间，直接用MyBatis-Plus的自动填充功能：@TableField(fill = FieldFill.INSERT)就能在insert时自动写入createTime，更新时用FieldFill.INSERT_UPDATE。

逻辑删除：给订单、商品表可以留一个deleted字段，使用MyBatis-Plus的逻辑删除功能，避免物理删除导致的数据丢失，答辩时可以说明这一点体现数据安全意识。

3.3 外键的取舍

很多教材喜欢把表关系画成有外键的ER图，但实际企业开发中，外键约束其实很少用。因为外键会影响写入性能，而且业务层已经保证了数据的一致性。我刚入行时有段时间不加外键总觉得不踏实，后来做了一段时间就明白了：为了保证性能和灵活性，MySQL本身的主力互联网架构也是尽量少用物理外键，一致性交给代码事务和逻辑约束处理。毕设里推荐不用物理外键，但表关系要靠逻辑字段关联，ER图里该标的外键关系还是要标出来给老师看。

4. 后端核心功能实现：认证、商品、订单一个都不能落

4.1 统一返回结果类和统一异常处理

我建议任何接口都返回统一结构：code、message、data三个字段。无论前端还是后端联调，都能减少很多沟通成本。定义一个Result 泛型类，里面放一个静态方法ok()、error()就可以了。

另一个必须做的是全局异常处理。SpringBoot里用@RestControllerAdvice + @ExceptionHandler就可以捕获所有异常，业务异常直接抛自定义的ServiceException，未知异常返回友好提示而不是打印一堆堆栈。这个设计点不复杂，但答辩时一提“全局异常处理”，老师就知道你有生产环境思维。

4.2 登录认证：JWT还是Session？

毕设最常见的做法是Session + Cookie，因为顺手，登录成功往session里塞个userId就行。但Session在前后端分离场景下不太方便：跨域时Cookie处理麻烦，分布式场景Session共享更麻烦。

我建议直接用JWT方案。核心思路是：

• 用户登录成功后，后端用JWT工具生成一个Token返回给前端
• 前端把Token存到localStorage，每次请求在header里带Authorization: Bearer xxx
• 后端写一个拦截器或Spring MVC拦截器，拦截除登录、注册、商品浏览外的接口，校验Token，解析出userId放入ThreadLocal或request attribute

JWT的生成用Hutool的JWTUtil特别简单，几行代码就实现签名和验签。注意秘钥要定一个足够长的字符串，过期时间建议设成24小时，前端到期再跳登录页。

这个方案和传统的Session方案比，面试和答辩时能展示你对无状态认证的理解，而且符合前后端分离的项目架构。

4.3 商品模块：动态查询和搜索排序

商品列表是典型需要写动态SQL的场景：用户可能传分类ID、可能传关键词、可能传价格区间、还可能要求按不同字段排序。用MyBatis-Plus的LambdaQueryWrapper就能解决：

LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.hasText(keyword)) { wrapper.like(Product::getName, keyword); } if (categoryId != null) { wrapper.eq(Product::getCategoryId, categoryId); } if (minPrice != null) { wrapper.ge(Product::getPrice, minPrice); } if (maxPrice != null) { wrapper.le(Product::getPrice, maxPrice); } wrapper.eq(Product::getStatus, 1); wrapper.orderByDesc(Product::getSales);

这个写法就是不写SQL，全部用方法链完成，让条件判空控制动态拼接，非常直观。加上MyBatis-Plus的分页插件，前端传入pageNum和pageSize，后端返回总记录数和列表即可。

搜索这里还可以再加一个细节：关键词搜索时如果同时匹配了商品名和副标题，可以用EntityWrapper的and嵌套实现优先匹配。不过对毕设来说，一个like查询已经够用，不用过度设计。

4.4 购物车：怎么保证数据不错乱

购物车本质是用户和商品的对应关系，加上数量和选中状态。加购的时候先判断是否存在，存在就增加数量，不存在就插入新记录。这个逻辑不复杂，但有几种情况要处理，否则数据会错乱：

• 同一用户同一商品不能出现两条记录，所以表上可以建一个(user_id, product_id)的唯一索引，代码上先查询再判断是否更新
• 购物车商品数量不能超过库存，要在加购时就把库存上限作为校验
• 用户修改数量时要重新计算金额，这个不用存数据库，响应前端时通过商品价格计算展示即可

购物车数据前端展示时，要返回商品的最新价格，不能直接拿购物车里存的快照字段。所以查询接口要联表，查询购物车时把商品的最新信息组装出来。这类VO的设计就是项目亮点。

4.5 订单模块：状态流转是关键

订单功能是整个系统的核心和难点，尤其是订单状态管理。我强烈建议你理清状态机，然后写清楚每次状态变更的条件和动作。

定义如下状态流转：

• 创建订单 = 待付款
• 待付款 + 支付成功 = 待发货
• 待发货 + 管理员发货 = 待收货
• 待收货 + 用户确认收货 = 已完成
• 待付款 + 超时/主动取消 = 已取消
• 待发货 + 管理员取消 = 已取消

实现时要注意，下单这个操作要放在一个事务里：先创建订单主记录，再批量创建订单明细，再扣减库存。这三步任何一步失败都要回滚。

扣库存建议用乐观锁或者加条件更新，保证并发时不会超卖：

boolean success = productService.update( new LambdaUpdateWrapper<Product>() .eq(Product::getId, productId) .ge(Product::getStock, quantity) .setSql("stock = stock - " + quantity) );

通过where条件里的ge(stock, quantity)实现剩余库存必须大于购买数量的约束，这样并发场景下不会把库存扣成负数。这是非常经典的高并发防超卖写法，比先查再更新要安全得多。

订单号生成方式：可以用年月日时分秒 + 用户ID后四位 + 随机数，然后用字符串拼接。注意别用数据库自增ID当订单号，那是主键，不是业务编号。启动时随机种子这些细节不用纠结，Hutool的IdUtil.getSnowflakeNextIdStr()直接生成雪花ID也行。

4.6 支付：怎么实现一个“看起来真实”的支付

毕设没必要对接支付宝或微信支付真实接口，既需要商户资质，流程又复杂。常见做法是“模拟支付”，页面里放一个“确认支付”按钮，点击后把订单状态从未付款改成待发货，同时记录支付时间。但要注意在支付接口里加一个校验：订单必须是当前登录用户的，且订单状态必须等于待付款，否则拒绝操作。还要在代码注释里说明：真实支付流程在这里需要调用第三方支付平台的API，比如支付宝的电脑网站支付，用统一收单下单接口，支付成功后通过异步通知修改订单状态。这样解释给老师听，他知道你理解完整链路，只是没接真实通道。

4.7 文件上传：图片存哪里、怎么访问

商品图片上传是敏感点。普通的做法是：后台管理端上传图片，SpringBoot接收MultipartFile，写入服务器本地磁盘，然后把相对路径存数据库，再通过一个映射URL对外提供访问。

核心配置：

spring.servlet.multipart.max-file-size=10MB spring.servlet.multipart.max-request-size=20MB

文件存储地址建议配成绝对路径，比如D:/fashion-shop/upload/，不要用相对路径。然后写一个WebMvcConfigurer把磁盘路径和URL路径做映射：

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceResolver(new PathResourceResolver()) .addResourceLocations("file:D:/fashion-shop/upload/"); }

存数据库的字段就存“/upload/2025/06/01/xxx.jpg”，前端直接拼域名访问。这里容易踩的坑就是本地路径分隔符跨平台问题，别在代码里硬编码“/”，尽量用File.separator或者相对路径拼接。答辩时可以提一句：正式部署时文件会存到OSS对象存储，本地磁盘方案是为了开发环境方便。

5. 前端联调与部署：Vue打包塞进SpringBoot，还是分离部署？

5.1 两种方案的取舍

前端如果用Vue开发，会面临部署方式的决策。一种是将Vue打包后的dist目录塞进SpringBoot的static静态资源目录，打成同一个jar；另一种是前后端完全分离，各部署各的。

塞在一起的好处是：一个进程、一个端口、不用配Nginx、答辩时不用解释一堆部署细节。缺点是：前端每次修改后都要重新打包，再拷贝到Java工程里，开发效率低，而且在springboot里配history路由还得改写请求转发规则，用一个controller处理404转发到index.html。

我的建议是：答辩阶段用分离部署，本地起Nginx托管前端，后端起SpringBoot，接口地址通过Nginx反向代理到8080。这样展示清晰，老师如果要看部署图，也好看。但如果时间紧张，前端也很简单，那就全塞一个jar，省事。

5.2 联调过程中的跨域问题

前后端分离开发中，跨域是最常见的坑。前端在5173端口跑Vite开发服务器，后端在8080，两个端口不同就必然跨域。解决方式主要有两种：

• 后端加CORS配置，写一个WebMvcConfigurer，注册CorsRegistry允许指定来源、指定header和方法。因为JWT要放到请求头里，注意设置allowedHeaders("*")。
• 直接用Nginx反向代理，前端请求/api下的地址，Nginx转发到后端的实际端口，这样从前端视角是同源请求，就不存在跨域。

我建议两个方案都了解，开发环境用后端CORS，部署环境用Nginx，这样怎么都能通。

5.3 启动端口和配置修改

开发过程中很多同学被端口占用坑过。SpringBoot默认8080，如果被占了，改配置：

server.port=8080 server.servlet.context-path=/api

在配置里加了context-path后，所有接口路径都会自动带一个/api前缀。要注意的是，JWT拦截器里的排除路径也要跟着改，不然放行规则就失效了。

数据库连接配置统一放application.yml里，密码、用户名、URL都配好，注意MySQL的时区参数：

spring: datasource: url: jdbc:mysql://localhost:3306/fashion_shop?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456

字符编码这里一定要用utf8mb4，不要用utf8，因为utf8在MySQL里是utf8mb3，有些冷门字符（比如emoji）存不进。数据库连接串里的characterEncoding=utf8，实际指向的是utf8mb4，仍然建议你建库时直接指定utf8mb4。

6. 高频问题与排查技巧实录

6.1 SpringBoot版本和依赖冲突

搜教程的时候我发现一个很普遍的现象：有人下了个SpringBoot 2.7项目改了JDK、依赖之后，启动报错找不到SpringApplication。原因多半是JDK版本不对，或者Maven没有正确导入。2.x最低要求JDK8，3.x必须JDK17，先检查本机java -version，再检查pom.xml里spring-boot-starter-parent版本。如果Maven依赖一直标红，先mvn clean + 重新导入。

还有MyBatis-Plus版本和SpringBoot版本之间也有兼容性问题。比如SpringBoot 2.7 + MyBatis-Plus 3.5.x版本是没问题的，但如果你去用MyBatis-Plus 4.x的早期版本，可能因为分页插件写法调整而踩坑。建议直接锁定MyBatis-Plus 3.5.3.1版本，稳定。

6.2 启动时报数据库连接失败

先检查MySQL服务是否启动。Windows上可以在服务管理里看MySQL是否在运行。然后检查URL、用户名、密码有没有写错，最隐蔽的问题是URL中没有加serverTimezone=Asia/Shanghai，导致连接时报“The server time zone value”的错误。这个问题基本只要加上参数就解决。

再往深的可能有MySQL 8的驱动类名变了，要用com.mysql.cj.jdbc.Driver。这些细节都要核对，不要指望一次性就能起成功。

6.3 前端跨域报错怎么办

看到“Access-Control-Allow-Origin”相关的报错，说明跨域配置没生效。先确认后端CorsRegistry有没有配置，前端的请求地址是不是写成了绝对地址而不是相对地址，前端代理有没有配置正确。调试时打开Chrome开发者工具看Network，重点看那个请求的状态码和响应头，响应头里有没有Access-Control-Allow-Origin字段，一目了然。

6.4 文件上传后访问404

文件上传后图片打不开，大概率是资源映射没配置对。先确认上传路径存到数据库的是什么，再确认addResourceHandler的路径模式，然后手动在浏览器里访问一下地址。注意路径映射的Location必须是file:开头的绝对路径。有一种很常犯的错误是：开发时File写到D盘，部署到Linux后路径不存在，记得改成Linux路径，或者干脆用相对路径动态获取。

6.5 页面中文乱码

乱码几乎都是字符集没统一。Java文件编码、前端页面编码、数据库连接URL的编码三个地方全部要统一为UTF-8。IDEA里可以在右下角把文件编码改成UTF-8。另外，如果使用了Thymeleaf，页面开头要加 。

6.6 JWT拦截器把登录和注册也拦截了

如果登录都调不通，检查拦截器的addPathPatterns和excludePathPatterns的配置。排除的路径要写对，比如排除/login、/register，而其他所有请求都需要Token。还有一点，微信公众号开发之类没有任何关系，别总想着把外部平台登录耦合进来，登录模块自己走得通就够了。

6.7 MyBatis-Plus 分页不生效

分页插件不生效，通常是分页拦截器没有注册成Bean。MyBatis-Plus从3.5.x之后，用MybatisPlusInterceptor替代了之前的PaginationInterceptor。在配置类里注册一下就好了。

@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }

另外查列表时返回的IPage要作为方法的返回值，不能把它当参数传进去然后返回List，那样分页数据总数为0。

7. 时间规划和后续扩展方向

7.1 怎么分配各阶段时间

每次带毕设都有人问我时间够不够。我的建议是：如果还没有开始写，按下面的节奏走，保持每天两小时，基本一个月能做完。

• 第1周：需求分析、表结构设计、项目搭建、通用类编写
• 第2周：用户模块（注册登录JWT）、商品模块（分类+列表+详情）
• 第3周：购物车+订单模块（含事务+库存）
• 第4周：后台管理端（商品、订单、轮播图管理）+ 前端页面整合
• 最后留2-3天做整体测试、写文档、准备答辩

不要一上来就写代码，更不要直接改别人的完整项目。可以看参考项目的设计思路，但一定要自己敲一遍，因为答辩时要能随手改代码、解释运行逻辑，否则一眼就会被识破。

7.2 如果你的项目想加分，可以扩展这几块

基础功能做完后，如果想在答辩时拉开差距，可以挑一个方向做增强：

• Redis做热点商品缓存：把首页轮播图、热销商品列表缓存到Redis，减少数据库压力
• Elasticsearch做商品全文检索：比MySQL的like查询体验好很多，能体现大数据量下的搜索设计思路
• RabbitMQ做订单超时取消：用户下单15分钟不支付自动取消，利用延迟队列实现
• 微信小程序/H5前端：做成多端展示，体现适配能力

注意这些都是可选的，一个项目里挑一个做透就够了，贪多嚼不烂。

7.3 根据我个人经验，给你几个最实在的建议

第一，把项目跑起来之后再写文档。很多同学喜欢先写一堆开发文档再写代码，结果代码和文档对不上。我建议是把核心代码写完，联调通过后再回头写开题报告和论文中的系统设计部分，效率和准确度都会高很多。

第二，数据库连接串、版本问题这类环境坑，遇到一次就记录下来。毕设过程中百分之六十的时间会花在排错上，把这些问题汇总成一份自己的排错文档，答辩前翻一遍，你会心态稳很多。

第三，不要执着于自己造轮子。JWT就用Hutool的，分页就用MyBatis-Plus的，验证码就用Hutool的，先把项目做出来，再去谈优化和底层原理。你把这套系统和它的关键机制讲清楚，远比你在一个点上钻牛角尖有价值。

最后再分享一个小技巧：答辩演示前，一定确保把项目里的测试数据做得“像样”。不要只有一张图一件衣服，要多放几件不同风格的衣服、不同品牌的数据、几十条订单数据、不同状态的订单各几条。老师看演示的时候，真实的数据会让系统显得完整可信。这个细节，比你在答辩时背一大段技术名词有用得多。