如果你正在为计算机毕业设计选题发愁又恰好看到“基于SpringBoot的装修建材商城”这类题目我可以很肯定地说这是一个非常经典、也相当“扛打”的方向。它表面是一个建材商品的在线交易平台本质上是一套标准的前后端分离电商系统覆盖用户注册登录、商品展示、购物车、下单支付、订单管理、后台商品维护等完整业务链路。无论是为了完成毕设还是为了系统性入门SpringBoot开发这个项目都能让你在动手过程中把框架、数据库、前后端联调的整套技能串起来。这篇内容我就基于自己带过同类项目的实际经验把这个“装修建材商城”拆开讲透为什么选这套技术栈、数据库怎么设计、下单和库存怎么处理才不出错、SpringBoot版本太高会踩哪些坑、答辩时怎么把项目讲出亮点。文章会尽量给到可以直接用的代码结构和配置也把那些常规文档里不会写、只有实际动手才会撞上的问题一并列出来。无论你是准备从零搭一个毕设项目还是已经做到一半卡在某个环节这篇都值得你花十几分钟读完。1. 项目整体设计与技术选型1.1 为什么毕设选SpringBoot这类商城项目最稳妥很多同学在选题时会纠结要不要做人工智能、要不要搞大数据感觉名字听起来更高级。但说实话毕业设计最怕的不是题目简单而是做到最后做不完、做不稳。装修建材商城这类项目之所以常年是选题热门是因为它覆盖了一个企业级Web系统最核心的模块用户体系、商品体系、交易体系、后台管理体系。这些模块在面试和答辩中都能讲出实际业务逻辑而不是堆一堆理论名词。SpringBoot在这类项目里的优势非常明显。它把Spring MVC、内置Tomcat、自动配置、依赖管理等底层细节打包好了你只需要关注业务代码。比起以前SSM时代那一大堆XML配置文件SpringBoot能把项目初始化时间从半天压缩到几分钟。对于一个需要独立完成的毕设来说时间是最宝贵的成本选SpringBoot就是在给自己节省折腾环境的精力把时间留给核心功能的打磨。另外一个很实际的原因是生态成熟。无论是MyBatis-Plus做数据访问、JWT做登录认证、Vue3做前端页面市面上都有大量现成案例和踩坑记录。这意味着你遇到问题时基本都能搜到解决方案不太会卡在一个莫名其妙的报错上好几天。对一个需要按时交付的毕设来说这种“可搜索性”和“可复现性”比什么都重要。1.2 技术栈版本怎么选才不踩坑技术选型不能只看“最新”更要看“稳定”和“配套”。这里我直接给你一套经过验证的组合照着配基本不会出大问题。技术组件推荐方案说明开发语言Java 8 或 Java 17若用SpringBoot 2.x选Java 8最稳若用3.x则必须Java 17后端框架SpringBoot 2.7.x 或 3.2.x推荐2.7.18兼容性最好追求新特性可上3.2数据访问MyBatis-Plus 3.5.x单表操作无需手写SQL非常省力数据库MySQL 8.0稳定、资料多、支持JSON字段前端Vue3 Element Plus Vite前后端分离的标配组合认证方案JWTjjwt库无状态登录适合接口分离架构工具库Hutool封装了大量工具方法减少重复代码关于“SpringBoot版本太高”这件事我必须要重点说。这个词最近在技术社区讨论很多原因是SpringBoot 3.x相比2.x有一批破坏性变更最典型的是Java EE的包名从javax.迁移到了jakarta.。也就是说如果你在SpringBoot 3项目里写import javax.servlet.http.HttpServletRequest会直接报错必须改成import jakarta.servlet.http.HttpServletRequest。类似的门户变动还有Spring Security的配置方式、一些第三方库的最低版本要求。我见过不少同学从网上下了一个基于SpringBoot 2.x的项目想升级到3.x结果一启动就几百个报错光是改包名就花了一晚上。所以我的建议很明确如果是为了稳妥完成毕设选SpringBoot 2.7.18加Java 8所有网上资料直接复用如果你确实想用3.x那就从一开始就按3.x的标准写代码千万别做“先2后3”的迁移打算。单这点想清楚能帮你省下一大笔时间。1.3 项目结构怎么划分最合理后端代码结构我建议按功能分包而不是按技术分层。所谓按功能分包就是“用户相关的所有代码”放在一起包括Controller、Service、Mapper、实体类。这样在后期维护和答辩讲解时你按业务模块逐一展示即可逻辑非常清晰。大致目录结构如下src/main/java/com/example/mall ├── common // 通用类返回值封装、异常处理、拦截器 ├── config // 配置类跨域、JWT拦截器注册、定时任务开关 ├── controller // 控制层接收请求 ├── entity // 数据库实体类 ├── mapper // MyBatis-Plus数据访问层 ├── service // 业务逻辑层 │ └── impl // 业务实现类 ├── utils // 工具类JWT生成与解析、文件上传 └── dto // 参数传输对象接收前端传入的复杂参数前端Vue3项目则按视图组织通常是views目录下放页面组件router目录管理路由api目录封装后端接口请求store目录管理全局状态。前后端分离的项目前端和后端可以分两个目录管理也可以放到同一个Git仓库的不同子目录里。如果答辩现场需要演示我更建议用同一个仓库管理这样打包演示方便代码总量也能体现出工作量。2. 核心功能拆解与数据库设计2.1 用户端到底要做哪些功能装修建材商城的用户端本质上和普通电商没什么区别但因为商品是建材类目会有一些特殊性需要体现出来。我建议把用户端分成六个核心模块。第一是账户模块包含注册、登录、退出、个人信息维护。注册时要注意用户名唯一性校验密码不能明文存储至少用BCrypt加密。这个模块是答辩时必讲的内容因为涉及安全相关的基础知识。第二是商品展示模块包含首页轮播图、分类导航、商品列表、商品搜索、商品详情。建材类商品通常会有规格属性比如瓷砖有尺寸、品牌、风格涂料有颜色、容量。这些属性建议用通用字段存储而不是每种商品建一张表否则后期扩展非常痛苦。第三是购物车模块包含添加商品到购物车、修改数量、删除、批量结算。购物车数据可以存数据库也可以用Redis等缓存但毕设场景下存MySQL的cart表最直观也便于展示数据库设计能力。第四是订单模块包含确认订单、下单、取消订单、订单列表、订单详情。这里是对整个系统要求最高的模块涉及多表操作将来做事务演示也主要靠它。第五是支付模块考虑到无法直接对接真实支付渠道建议做成“模拟支付”用户下单后跳转到一个支付确认页点击“确认支付”即可将订单状态从待支付改成待发货。如果你想让项目更有亮点也可以接入支付宝或微信的沙箱环境这一块放到后面扩展章节细说。第六是售后模块包含确认收货、评价、申请退款等。这部分不一定要做得很重但至少要有“确认收货”和“订单评价”功能因为它能让订单生命周期显得完整也是管理端展示数据的基础。2.2 管理端功能怎么设计才有完整闭环管理端是毕业设计里最容易显得单薄的部分。如果只是做一个简单的数据列表那工作量和技术含量都会大打折扣。我建议把管理端设计成五个模块让整个系统形成闭环。商品管理是最核心的包括商品新增、编辑、上下架、删除以及库存调整。建材商品的管理需要注意批量操作比如批量上架、批量改价这功能实现起来并不复杂但在演示时很能体现工程化思维。分类管理负责维护商品类目的层级结构瓷砖、地板、卫浴、五金等。分类最好设计成树形结构支持二级甚至三级分类虽然增加了实现难度但更贴近真实业务。订单管理包括订单列表查看、发货操作、查看订单详情、处理退款申请。管理端发货后用户端订单状态从待发货变成待收货这就能串联起整个订单状态机让评审老师看到完整的数据流转。用户管理包含用户列表、启停用账号、重置密码。这部分虽然实现简单但管理端必须要有否则系统缺少后台“管控”能力。此外我建议加一个用户下单量统计字段在列表里直接显示每个用户的订单数和消费总额这可以从订单表实时查询也可以在用户表冗余字段属于性价比很高的功能增强。最后是数据统计模块展示商品销量排行、订单金额趋势、类目占比。不需要什么复杂技术用几个简单的SQL聚合查询加柱状图或饼图就能实现。如果你不想引入ECharts可视化库也可以先用表格展示数字。但说实话加一个可视化的首页对答辩加分很有帮助建议保留。2.3 数据库表结构设计要点与订单状态设计数据库设计是整个毕设的地基这里如果设计不合理后面写业务代码时会处处别扭。我基于建材商城的常见需求给出一份可以直接参考的表清单。表名核心字段用途说明tb_userid, username, password, phone, status, create_time用户账户信息tb_addressid, user_id, receiver, phone, province, city, detail收货地址tb_categoryid, name, parent_id, sort, status商品分类tb_goodsid, category_id, name, subtitle, image, images, price, stock, sales, status商品主体信息tb_cartid, user_id, goods_id, quantity, checked购物车条目tb_orderid, order_no, user_id, total_amount, status, create_time, pay_time, ship_time订单主表tb_order_itemid, order_id, goods_id, goods_name, goods_image, price, quantity, total_price订单明细tb_commentid, user_id, order_item_id, content, rating, create_time商品评价tb_bannerid, image, link_url, sort, status首页轮播图我特别想展开说三个设计细节。第一个是金额字段一律用DECIMAL(10,2)千万别用float或double否则会出现0.1加0.2等于0.30000000000000004这种浮点精度问题。第二个是订单号字段order_no要唯一且可读建议用时间戳加随机数生成如20250615103012001不要用数据库自增主键直接当订单号暴露给用户。第三个是价格、库存这类高并发敏感字段在Java实体类中用BigDecimal和Long表示数据库层加逻辑删除字段is_deleted不要物理删除数据这是企业开发的基本习惯。订单状态设计是整个系统的关键。我建议用整型枚举字段表示而不是字符串因为整型存储效率更高且可以通过常量类统一管理。状态流转的完整流程是0待支付 - 1待发货 - 2待收货 - 3已完成同时包含4已取消和5退款中这两个分支状态。在代码里建一个常量类保存这些状态值然后用状态机逻辑控制流转可以避免出现用户从待收货直接跳到待支付这类非法状态。答辩时如果能把这个状态机讲清楚评审老师会觉得你对业务的理解超出了普通毕设水平。3. 核心环节的实操实现3.1 项目初始化与关键配置第一步是创建一个SpringBoot项目。虽然IDEA内置的Spring Initializr很方便但要注意选择正确的SpringBoot版本。我这里直接给出一份基于SpringBoot 2.7.18的pom.xml核心依赖清单。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.5/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.25/version /dependency /dependencies配置文件的重点是数据源和MyBatis-Plus。我在配置数据源时最容易踩的坑就是时区问题这里直接给一份完整配置。spring: datasource: url: jdbc:mysql://localhost:3306/mall_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: is_deleted logic-delete-value: 1 logic-not-delete-value: 0serverTimezoneAsia/Shanghai这行务必保留否则连接MySQL 8.0时经常会报The server time zone valueÖйú±ê׼ʱ¼ä is unrecognized。useSSLfalse则是为了避免本地开发环境出现SSL连接警告。MyBatis-Plus的配置里我开启了逻辑删除全局配置这样在执行删除操作时框架会自动把DELETE语句转成UPDATE is_deleted1数据就不会被真正抹掉。3.2 登录认证与JWT拦截器实现登录模块我推荐用JWT而不是传统Session。原因很简单前后端分离下Session需要处理跨域Cookie还要额外配置Session共享而JWT把用户信息加密放在令牌里前端每次请求携带这个令牌后端校验即可天然适合分离架构。JWT实现的核心逻辑分为两部分登录时生成令牌请求时解析令牌。登录接口的核心代码大致如下public String login(String username, String password) { LambdaQueryWrapperUser wrapper new LambdaQueryWrapper(); wrapper.eq(User::getUsername, username); User user userMapper.selectOne(wrapper); // 用BCrypt验证密码 if (user null || !BCrypt.checkpw(password, user.getPassword())) { throw new BusinessException(用户名或密码错误); } if (user.getStatus() ! 1) { throw new BusinessException(账号已被禁用); } // 生成JWT过期时间设置为1天 String token Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim(username, user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() 86400000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); return token; }生成令牌之后需要一个拦截器拦截所有需要登录的接口从请求头中获取token并解析校验。我建议单独写一个JwtInterceptor实现HandlerInterceptor在preHandle方法里完成解析同时把当前登录用户ID放ThreadLocal里方便后续业务代码随时取用。这属于一个很实用的设计模式比每个方法都传一个userId参数要优雅得多。实际编写时要注意两点。第一是JWT的密钥要单独配置在yml里不要硬编码到代码中。第二是登录接口本身不需要校验Token所以拦截器注册时要排除/api/user/login、/api/user/register以及商品浏览类公开接口否则就会出现新用户连首页都打不开的诡异问题。3.3 下单事务与库存扣减的正确姿势下单是整套系统里最考验基本功的模块也是答辩时最容易被追问的地方。我先说一个很多新手容易犯的错误直接在Controller里写下单逻辑然后一顿Transactional就算完事。真实场景中下单至少涉及订单主表插入、订单明细批量插入、商品库存扣减、购物车清除四步操作其中任何一步失败其他步骤都必须回滚。这时候事务的使用就非常关键。我给出一段下单核心逻辑的骨架代码Transactional(rollbackFor Exception.class) public Long createOrder(OrderCreateDTO dto) { // 1. 生成订单号 String orderNo generateOrderNo(); // 2. 创建订单主表记录 Order order new Order(); order.setOrderNo(orderNo); order.setUserId(dto.getUserId()); order.setTotalAmount(dto.getTotalAmount()); order.setStatus(OrderStatus.UNPAID.getCode()); orderMapper.insert(order); // 3. 批量插入订单明细 ListOrderItem items buildOrderItems(dto, order.getId()); orderItemMapper.insertBatch(items); // 4. 扣减库存 for (OrderItem item : items) { goodsMapper.decreaseStock(item.getGoodsId(), item.getQuantity()); } // 5. 清空对应购物车项 cartMapper.deleteBatchIds(dto.getCartIds()); return order.getId(); }这里要强调一个关键点扣减库存的SQL不能简单写成update goods set stock stock - #{quantity} where id #{goodsId}因为在高并发场景下会出现超卖。正确做法是加一个库存充足的条件判断UPDATE tb_goods SET stock stock - #{quantity} WHERE id #{goodsId} AND stock #{quantity}然后在Service里检查这条SQL的更新行数如果返回0说明库存不足直接抛出异常回滚事务。这就是所谓的乐观锁思路适合毕设和大部分小型系统的并发场景。如果你想让项目更“硬核”也可以在商品表的stock查询时加SELECT ... FOR UPDATE悲观锁但毕设里通常不需要这么重的手段重点是你清楚两种方案的区别并能讲出选择理由。3.4 定时任务搞定订单超时与自动收货订单模块还隐含着一个重要的业务需求订单超时未支付要自动取消发货后一段时间未确认收货要自动完成。这属于典型的定时任务场景。SpringBoot自带的Scheduled注解完全可以胜任毕设级别的定时需求。具体做法是在启动类上加上EnableScheduling注解然后新建一个OrderTask类Component public class OrderTask { Resource private OrderMapper orderMapper; // 每10分钟执行一次关闭超时订单 Scheduled(cron 0 */10 * * * ?) public void closeTimeoutOrders() { LocalDateTime deadline LocalDateTime.now().minusMinutes(30); ListOrder orders orderMapper.selectUnpaidOrdersBefore(deadline); for (Order order : orders) { order.setStatus(OrderStatus.CANCELLED.getCode()); // 恢复商品库存 ListOrderItem items orderItemMapper.selectByOrderId(order.getId()); for (OrderItem item : items) { goodsMapper.increaseStock(item.getGoodsId(), item.getQuantity()); } orderMapper.updateById(order); } } }需要注意定时任务的cron表达式建议不要设得太频繁测试时可以用短间隔正式答辩演示前改回较长间隔。否则每秒钟扫一遍全表订单既浪费数据库资源答辩时也不好看。这里我用了30分钟作为超时时间实际业务中可能会是24小时但演示场景下短时间更容易感受效果。定时任务跑完后可以打一条日志方便在控制台观察执行情况。4. 常见问题与排查技巧实录4.1 SpringBoot版本太高引发的包名问题这个我在前面已经提过这里再展开讲讲它的典型报错长什么样。如果你在SpringBoot 3.x项目里写了import javax.servlet.http.HttpServletRequest编译时会报“程序包javax.servlet.http不存在”。对很多习惯搜答案的同学来说这题在网上一搜会出现五花八门的答案最有效的一条其实只有一个把javax改成jakarta。不只是ServletJava EE相关的API在SpringBoot 3里都改了包名包括javax.validation变成了jakarta.validationjavax.annotation部分API也有变化。如果项目里用到这些全部批量替换即可。IDEA里可以用CtrlShiftR全局替换当前目录注意只替换import行不要误伤其他代码。另外MyBatis-Plus在SpringBoot 3下要使用mybatis-plus-spring-boot3-starter这个专用依赖包名不再是mybatis-plus-boot-starter这是很多人升级后踩的第二个坑。所以再次强调除非你有充分理由否则毕设项目直接留在SpringBoot 2.7.x能少很多莫名其妙的麻烦。4.2 数据库连接失败的一揽子解决方案我统计过自己带过的项目数据库连接问题排在新手报错的第一位而且种类相当集中。如果你启动项目报Cannot create PoolableConnectionFactory通常逃不出下面几个原因。驱动类没写错是最基本的。MySQL 8.x的驱动类是com.mysql.cj.jdbc.Driver不是老旧的com.mysql.jdbc.Driver虽然新版驱动可以自动识别但建议还是明确写上。然后就是时区问题前面说的serverTimezoneAsia/Shanghai必须加上。还有一种比较隐蔽MySQL 8.0默认使用caching_sha2_password认证插件而你的客户端连接驱动版本太老不支持这时升级mysql-connector-java版本到8.0.33就能解决。我建议在动手写任何业务代码前先配置好数据源并写一个简单的测试接口通过http://localhost:8080/test/db确认数据库连接正常再往下做。这个几分钟的验证能有效避免“代码写了一大堆最后发现是配置问题”的尴尬处境。4.3 前后端联调时的跨域与参数问题前后端分离的项目几乎必然遇到跨域问题。浏览器会因为同源策略拦截前端请求报错信息一般是Access-Control-Allow-Origin相关。解决方案有两个后端开启全局跨域配置或者前端使用开发代理。我更推荐先在后端加一个CorsConfig配置类实现WebMvcConfigurer接口并覆盖addCorsMappings方法允许http://localhost:5173这个前端开发服务器地址访问所有接口。这样开发时最省心前端不用配置代理也能调通。等部署上线时再把跨域配置收紧改成只允许实际前端域名访问。参数问题也比较常见。前端用Vue3的axios发送POST请求时默认发送的是JSON格式后端Controller需要用RequestBody接收。如果后端用了RequestParam就会收到Required request body is missing之类的报错。搞清楚RequestBody和RequestParam的适用场景可以避免大量改代码的时间。我建议项目里统一约定新增和修改操作传JSON对象查询和删除操作传URL参数团队协作时也不容易乱。4.4 问题排查速查表报错特征可能原因解决思路启动报端口占用8080被其他进程占用换端口或在yml中修改server.portThymeleaf模板404前后端路径映射错误检查controller的RequestMapping路径是否匹配返回日期格式为时间戳Jackson序列化配置未生效在application.yml配置日期格式化或加JsonFormatJWT解析报ExpiredJwtExceptionToken过期时间过短调大过期时间或增加自动刷新机制商品列表查询慢全表扫描没有索引在category_id、goods_name等查询字段上建索引这里我再补充一个小经验遇到报错先看完整堆栈不要只盯着第一行。我见过不少同学看到NullPointerException就开始改代码但真正的问题其实在日志前面几行明确标注了“数据库连接失败”或者“参数缺失”。先通读日志十秒往往比反复尝试十分钟更高效。5. 让毕设更出彩的扩展方向与答辩思路5.1 功能细节上如何加分基础功能按部就班做完只能算合格。想让答辩时更有底气有几个高性价比的细节值得补上。第一个是商品搜索功能不要只做简单模糊查询。用MyBatis-Plus的like条件配合关键词分词做一个简单的“标题副标题分类名”联合搜索就能在演示时展示出比“一个搜索框查一张表”更完整的检索思路。第二个是文件上传。建材商品需要上传图片可以集成一个本地存储上传接口把图片保存到项目指定目录并返回访问URL。这看起来是小功能但能体现你对资源处理的理解。第三个是操作日志。可以用Spring AOP做一个注解式的操作日志记录把用户的关键操作上架商品、发货、修改价格等记录到一张日志表里。这个功能代码量不大但答辩时是非常好的切入口可以顺势讲AOP的原理和应用场景很容易给评审老师留下功底扎实的印象。5.2 技术深度上的扩展方向如果你学有余力还可以在现有架构上叠加一些主流中间件让项目的技术含量进一步提升。Redis可以做三件事缓存热点商品数据减少数据库压力保存用户购物车临时数据实现商品浏览历史。价格不高的方案是本地安装Redis然后在Service层加缓存逻辑。这一改动能让项目在“性能优化”层面有话可说。Elasticsearch可以做商品全文搜索替换掉MySQL的like模糊查询。不过这个集成成本较高需要额外部署ES服务更适合已经有一定基础的同学。支付接口可以接入支付宝沙箱环境接口文档完善且有模拟账号能让支付流程变得真实。但需要提醒的是支付集成是双刃剑沙箱环境偶尔不稳定答辩前务必多测试几遍。5.3 答辩时怎么讲项目效果最好答辩时千万不要从头到尾念代码或者念功能列表那是最容易被追问到卡壳的展示方式。我建议按“业务背景—架构设计—核心难点—技术亮点”这条线来讲时间控制在五到八分钟。开场先讲清楚你要解决的问题装修建材商品种类多、规格差异大、交易链路长因此需要一个线上平台来规范展示和交易流程。接着展示架构图说明前后端分离的整体结构以及SpringBoot、MyBatis-Plus、MySQL之间的协作关系。然后引出你认为最有难度的两个点一个是订单与库存的一致性控制另一个是登录认证的权限拦截。前者讲事务和乐观锁后者讲JWT原理和拦截器设计这两个点足以撑起整场答辩的技术深度。还有一个很实用的技巧多准备一些“成本收益”话术。比如“我用Redis缓存商品热点数据将详情页响应时间从200毫秒降低到了约50毫秒”或“通过逻辑删除数据的可追溯性明显提升”。哪怕指标是自己测试出来的也能体现出你关注工程效果而不是只写了个能跑的代码。6. 实操心得与总结做这个建材商城项目我个人感触最深的一点是毕业设计真正拉开差距的并不是某个技术有多高级而是你能否把一条完整业务链路打磨到没有明显漏洞。登录、加购、下单、支付、发货、收货、评价每个环节都有很多细节任何一个环节出现状态错乱后面都会跟着出问题。我第一次做同类项目时就在库存扣减上翻了车测试时两个人同时下单库存从10直接变成负数后来加上库存条件判断和事务回滚才彻底解决。这种踩坑经验往往比顺风顺水写出来的代码更有价值。所以我的建议是先不要急着堆功能把核心链路老老实实跑通再逐项加亮点。数据库设计多花点时间反复推敲订单状态机画清楚再动手前端联调时提前约定好接口格式。基础版本稳定后再去考虑Redis、搜索、支付这些加分项。按这个节奏走下来你不仅能收获一个高分毕设更重要的是把SpringBoot开发的全流程真正装进自己的知识体系里。另外最后再分享一个实操小技巧项目完成后把所有接口整理成一份接口文档用Swagger或者Postman导出都可以不仅方便答辩前自查评审老师查看时也会觉得你的工程化素养不错。代码写完不着急打包先跑一遍完整的用户流程和管理员流程尤其是异常分支比如库存不足时下单、未登录时访问个人中心、超时订单自动取消。把这些边角场景都验证到位你的项目才真的算“能打”。