站在毕业设计的岔路口，很多Java方向的同学都会盯上“商城系统”这个经典题目。但真正动起手来，从课程作业里的“玩具项目”过渡到一个功能闭环、代码干净、能写进简历也能顺利答辩的完整SpringBoot前后端项目，中间差的可不是一星半点。这篇博文我想跟你聊的，就是一个基于SpringBoot的运动用品商城系统——从技术选型怎么定、数据库表怎么设计、前后端怎么衔接，到论文怎么写、答辩怎么答、部署踩坑怎么排，完整复盘一遍。文章偏实操，适合正在准备Java毕设、想搞懂SpringBoot实际业务开发、或者想把手头项目整理成“能打”作品的同学阅读。
1. 项目概述与设计思路拆解
1.1 这个商城系统到底要做什么
做一个运动用品商城，本质上是在做一个“人—货—单”三要素打通的业务闭环。人，就是用户和后台管理员两端；货，是商品的分类、信息、库存、上下架状态；单，是用户从加入购物车到提交订单、完成支付、确认收货的整条链路。用一句话概括：用户端逛店下单，管理端管货管单，两端共用一套数据、一套逻辑。
很多同学第一次做毕设，容易把商城做成“网页版的Excel”——商品写死在前端，订单只是往数据库塞一条记录，管理员后台能看但没法改。这其实没有真正理解“系统”二字的含义。一个合格的运动用品商城系统，至少要满足三个层面的要求：数据有状态、业务有流转、角色有分工。
- 数据有状态：商品是上架还是下架，订单是待支付、已支付、已发货还是已取消，用户是否被禁用，每个关键实体都要有明确的字段表达。
- 业务有流转：下单后库存要扣减，支付后订单状态要更新，取消订单要回补库存，这些操作不是孤立写一条SQL，而是通过Service层串联成事务。
- 角色有分工：用户端和管理端必须是两套界面、两套权限体系。用户看不到管理入口，管理员也不该在前台买东西——权限靠拦截器或鉴权框架控制。
这个项目里我把这两端拆成了“前台商城系统”和“后台管理系统”，前端走Vue + Element UI，后端是SpringBoot + MyBatis-Plus + MySQL + Redis，部署上去跑通全流程。整体并不复杂，但每一步都有值得展开讲的技术细节。
1.2 技术选型为什么要这么定
SpringBoot作为主力框架，在毕设场景下几乎是“标准答案”。原因很实际：起步快、配置少、生态强。不用像SSH那样写一堆XML配置，Maven引入依赖后开箱即用，而且现在网上关于SpringBoot的资料多到看不完，遇到问题搜一下就有答案。更重要的是，SpringBoot内嵌Tomcat，打包成jar直接跑，对没有独立运维经验的在校生来说，部署门槛低了一大截。
配套选型上，我做了这么几个决策：
- 持久层框架用了MyBatis-Plus，而不是原生MyBatis。原因不复杂——单表CRUD用MP的BaseMapper能少写一大半SQL，写复杂多表查询的时候再手写XML，效率高还不容易出错。对毕设来说，这是非常务实的选择。
- 数据库用了MySQL 8.x，配合Navicat或DBeaver管理，建库建表直观、调试方便。
- Redis用来做验证码缓存和商品热门数据缓存。之所以引入Redis，一方面是为了解决高频读取的性能问题，另一方面给项目增加一个技术亮点，论文里也有话可写。
- 前端用了Vue 2 + Element UI + Axios，前后端通过RESTful接口交互。选择Vue 2而不是Vue 3，是因为Element UI成熟稳定、网上案例最多，对毕设来说稳比新更重要。
这套选型的整体思路是：成熟优先，亮点点缀。技术上不追求新、险、偏，但要在关键地方有自己的思考——比如缓存用在哪、权限怎么控制、事务怎么保证，这些都能在答辩时讲出“为什么”，而不是背一段教科书概念。
1.3 功能模块划分与系统架构概览
我按照业务边界把系统拆成了六个核心模块：
- 用户模块：注册、登录、个人信息查看与修改。密码用MD5加盐处理后存储（也可以升级为BCrypt），登录成功后签发JWT。
- 商品模块：运动用品分类浏览、商品列表分页查询、商品详情查看、关键字搜索、热门商品推荐。
- 购物车模块：加入购物车、修改数量、删除购物车条目、批量结算。非登录状态下不能操作购物车。
- 订单模块：从购物车生成订单、订单地址填写（简单版本可直连用户表）、模拟支付、订单列表分页查询、取消订单、确认收货。
- 评论模块：用户购买后可对商品发表评论，管理员可在后台删除违规评论。
- 后台管理模块：管理员登录、商品管理（添加、修改、上架/下架、删除）、分类管理、订单管理（查看所有订单，修改订单状态）、用户管理（禁用/启用用户）、数据统计（订单量、销售额趋势等）。
系统整体采用经典的前后端分离架构。前端两个工程：mall-admin（后台管理）和mall-web（前台商城），通过Axios请求后端接口。后端一个SpringBoot工程，按Controller、Service、Mapper三层组织，控制器负责接收和响应HTTP请求，Service承载业务规则，Mapper承接数据库读写。
2. 核心技术细节与实践解析
2.1 数据库表设计：一图看懂七大核心表
数据库设计是毕设项目中“最见功底”的一环。不要上来就急着建表，先想清楚订单、商品、用户三者之间的关系，再画出ER图。我这里最终规划了七张核心表：
| 表名 | 用途 | 关键字段说明 |
|---|---|---|
user | 用户表 | id、username、password、nickname、phone、avatar、role（0用户/1管理员）、status（0正常/1禁用） |
category | 商品分类表 | id、name、parent_id（支持二级分类）、sort |
product | 商品表 | id、category_id、name、subtitle、main_image、detail、price、stock、status（0下架/1上架）、sales |
cart_item | 购物车表 | id、user_id、product_id、quantity、checked（是否选中结算） |
order | 订单表 | id、order_no、user_id、total_price、status、receiver_name、receiver_phone、receiver_address、create_time |
order_item | 订单明细表 | id、order_id、product_id、product_name、product_image、current_price、quantity |
comment | 评论表 | id、product_id、user_id、content、rating、create_time |
两张关键表再展开说一下：
订单为什么要拆成主表和明细表两张？因为在一次购物中，用户可能同时买了篮球、护腕和运动袜，每一件商品对应一行order_item，而整个订单的信息（收货人、总价、状态）只存一行order。这样设计有几个好处：查询订单列表时不需要反复扫描商品关联数据；修改某一个商品的单价不影响历史订单；统计销量时直接对order_item做聚合即可。
购物车表里我放了一个checked字段，表示“这条购物车记录是否被勾选结算”。前端点击“全选”或“单选”时，只需要更新这个布尔值。生成订单时只取checked=1的数据，这样实现起来逻辑清晰，也不会出现结算条目和用户预期不一致的情况。
2.2 后端分层设计：Controller、Service、Mapper各司其职
后端代码我一直坚持一个原则：Controller只做参数接收和结果封装，Service只做业务规则，Mapper只做数据访问。很多初写SpringBoot项目的同学喜欢把所有逻辑塞进Controller，200行的接口方法看着很“爽”，但这种写法的后期维护成本和答辩追问时的尴尬都是成倍的。
以“提交订单”为例，看这个业务在Service层是怎么编排的：
- 入参校验：校验用户是否登录、购物车选中的商品是否存在、库存是否充足。
- 价格计算：后端必须重新计算价格——永远不要直接信任前端传过来的金额，这是一条安全铁律。
- 生成订单号：用时间戳 + 用户ID + 随机数拼接，或者采用Snowflake算法生成全局唯一ID。
- 扣减库存：UPDATE product SET stock = stock - #{quantity} WHERE id = #{productId} AND stock >= #{quantity}，用数据库的行锁来防止超卖。
- 创建订单主表记录和明细记录：这两步必须放在同一个事务里，任何一个失败都要回滚。
在Controller层，我只做了三件事：从JWT里解析出用户ID，调用Service层的createOrder(Long userId, CreateOrderRequest request)，把返回结果包装成统一响应体Result.success(data)。整个流程干干净净，答辩时面试官问起来，你也能清清楚楚讲明白数据是怎么流通的。
2.3 前端页面结构与交互状态管理
前端部分，前台商城我用的Vue + Vue Router + Vuex。Vuex管理全局状态，比如用户登录信息、购物车数量，因为这些数据在多个页面都要用到。购物车数量这个细节很有意思——页面右上角的“购物车(3)”角标，如果每个页面都在created钩子里拉一次接口，就太浪费了。正确做法是：用户加入购物车成功后，commit一个Vuex mutation更新cartCount，全局响应。退出登录时重置状态。
页面路由这么规划：
/home：首页，轮播图 + 热门运动商品推荐/product/list：商品列表页，支持分类筛选、关键词搜索、分页/product/detail/:id：商品详情页，展示大图、价格、库存、商品参数、用户评价/cart：购物车页面/order/confirm：确认订单页，展示商品清单和收货人信息/order/list：订单列表页，按状态Tab切换/user/profile：个人中心
后台管理系统相对简单，左侧菜单栏 + 右侧内容区是Element UI的经典布局，路由懒加载按需拆分，就不展开了。但有一点要提醒：前端路由和后端接口的命名尽量保持对应，比如/api/admin/product对应前端“商品管理”页面菜单，debug的时候能少走很多弯路。
3. 实操过程与完整实现记录
3.1 环境准备与项目初始化
动手写代码之前，先把环境理顺。我用的版本组合，给直接照做的同学一个参考：
- JDK 8（SpringBoot 2.7.x最合适的搭档，JDK17配SpringBoot3对毕设来说没太大必要，还容易踩module坑）
- Maven 3.6+
- MySQL 8.0+
- Redis 6.x
- Node.js 14+ / npm
- IDEA 2024.x
初始化后端工程有两种办法：去Spring Initializr网站勾选依赖生成，或者直接在IDEA里新建Spring Initializr项目。依赖这里直接勾选：Spring Web、MyBatis-Plus（这个在Initializr里没有，后面手动加坐标）、Lombok、Validation。手动向pom.xml补充的核心坐标：
<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-impl</artifactId> <version>0.11.5</version> <scope>runtime</scope> </dependency>这里有个容易踩的坑：MyBatis-Plus的版本和SpringBoot版本必须兼容，我试过MyBatis-Plus 3.5.3.1配SpringBoot 2.7.x没有问题，但配SpringBoot 3.x就报Caused by: java.lang.NoClassDefFoundError。如果你用了SpringBoot 3.x，请选择MyBatis-Plus的mybatis-plus-spring-boot3-starter，这是新版专用坐标。
application.yml里最核心的配置如下：
server: port: 8088 spring: datasource: url: jdbc:mysql://localhost:3306/sports_mall?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 password: mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0map-underscore-to-camel-case这个配置务必打开，它能自动把数据库字段create_time映射到Java属性createTime，否则你会在每个实体类上被迫写一堆@TableField注解。
前端工程我用Vue CLI初始化两个项目mall-web和mall-admin，安装element-ui、axios、vue-router、vuex。开发调试时配一个代理解决跨域问题——在vue.config.js里配置devServer.proxy，把请求转发到后端地址：
devServer: { proxy: { '/api': { target: 'http://localhost:8088', changeOrigin: true, pathRewrite: { '^/api': '' } } } }这里注意一个设计细节：前端请求统一加/api前缀，后端Controller的@RequestMapping不加/api，代理转发时用pathRewrite把前缀剥掉。这样如果后端接口路径变化，前端只需改一处代理配置，不需要改每个请求地址。
3.2 登录鉴权模块：从JWT封装到拦截器配置
登录是商城系统的入口，也是整个项目技术含量最集中的地方。我用了JWT（JSON Web Token）做无状态登录，流程如下：
- 用户提交用户名和密码。
- 后端根据用户名查出用户记录，校验密码（MD5加盐后比对）。
- 校验通过后，用JWT工具类生成一个token，把用户ID和角色塞进claims，设置过期时间比如7天。
- 返回给前端
{ token, userInfo }，前端把token存到localStorage，并在axios请求拦截器里统一加上Authorization: Bearer ${token}头部。 - 后端写一个拦截器
JwtInterceptor，注册时排除登录注册接口和商品浏览接口，其他接口统一校验token有效性。
JWT工具类的核心方法大致长这样（简化版）：
// 生成token public String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 3600 * 1000L)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } // 解析token public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token) .getBody(); }拦截器里通过HandlerMethod判断是否为控制器方法，非控制器放行（比如静态资源），控制器方法则执行token校验。校验通过后把userId存入request.setAttribute("userId", ...)，Controller方法里通过@RequestAttribute("userId") Long userId获取当前登录用户。
有个细节要提醒：拦截器只做了“是否登录”的验证，还没有做“是否有权限”的验证。后台管理接口需要管理员权限，所以拦截器里还要加一个判断——从claims中取出role，如果是"1"且请求路径以/admin/开头，就放行，否则返回403。这个角色判断逻辑写在拦截器里比写在每个Controller里干净得多。
3.3 商品模块与购物车、订单的完整业务闭环
商品模块看起来是最简单的“增删改查”，但要注意接口的参数校验和返回体设计。比如分页查询商品，我要接收的入参包括：pageNum（页码）、pageSize（每页大小）、categoryId（分类ID，可空）、keyword（搜索关键字，可空）、sort（排序方式：默认综合、价格升序、价格降序、销量）。MyBatis-Plus的Page<Product>对象配合LambdaQueryWrapper可以很优雅地搞定：
public Page<Product> pageProducts(ProductQuery query) { LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(query.getCategoryId() != null, Product::getCategoryId, query.getCategoryId()) .like(StringUtils.hasText(query.getKeyword()), Product::getName, query.getKeyword()) .eq(Product::getStatus, 1); // 只查上架商品 if ("priceAsc".equals(query.getSort())) { wrapper.orderByAsc(Product::getPrice); } else if ("priceDesc".equals(query.getSort())) { wrapper.orderByDesc(Product::getPrice); } else if ("sales".equals(query.getSort())) { wrapper.orderByDesc(Product::getSales); } return productMapper.selectPage(new Page<>(query.getPageNum(), query.getPageSize()), wrapper); }购物车模块要注意CartItem和Product的关联展示问题。购物车表的粒度是“某个用户的某个商品”，但前端需要展示商品名称、单价、图片，而这些字段在product表里。处理方式是VO组装——查出购物车条目后，批量取出相关的商品ID，再一次性查商品列表，手动拼装成购物车VO返回给前端。不要在for循环里挨个查数据库，那样N+1问题会让你在并发测试时直接量出性能短板。
订单模块是整个系统中业务规则最密集的地方。前面我提到用事务保证下单一致性，在SpringBoot里加@Transactional注解即可。但这里有一个经典陷阱：@Transactional默认只对RuntimeException回滚。如果Service方法里catch住了异常然后return，事务是不会回滚的。所以下单方法不要吞异常，让统一全局异常处理器去处理，交由事务管理器决策回滚。
模拟支付我用了最简单的方案——用户点击“立即支付”，前端弹出确认框，确认后调后端“支付接口”，后端把订单状态从PENDING_PAYMENT更新为PAID，同时把该订单关联的商品销量加一。这里两个操作也在一个事务里，保证数据一致。
3.4 项目打包部署和前端联调流程
本地开发完，下一步是打包部署。后端打包很简单，IDEA右侧Maven面板双击package，会在target/下生成一个mall-server-0.0.1-SNAPSHOT.jar。但在此之前，我建议你先跑一遍这个命令：
mvn clean package -DskipTests为什么跳过测试？不是说不该写测试，而是很多毕设项目的测试类里没写断言，纯粹是为了占位，打包时执行测试反而会因为缺少运行环境报错。毕设场景下-DskipTests是务实的选择。如果打包报错“程序包xxx不存在”，多半是依赖坐标写错或本地仓库没有对应jar包，IDEA里执行一次mvn -U clean install刷新一下依赖试试。
后端跑起来之后，本地验证接口我建议用Postman或Apifox。先把登录接口调通拿token，再带着token访问需要鉴权的商品管理接口，确认拦截器生效。全部通过后再启动前端项目，把页面流程图里的链路完整走一遍。
前端部署上，如果你和我一样只是做毕设演示，npm run serve本地运行足够了。但如果你想把项目放到服务器上给老师在线演示，前端需要npm run build生成静态文件，然后扔到Nginx的html目录里，后端jar包用nohup java -jar mall-server.jar > logs.log 2>&1 &后台启动。Nginx还需要配置反向代理，把/api请求转发到后端端口。
4. 常见问题与排查技巧实录
4.1 开发期高频报错与修复速查
我把自己和身边同学踩过的高频问题整理成了一张速查表，花两分钟扫一眼，能帮你省下不少百度时间。
| 现象 | 原因 | 解决方案 |
|---|---|---|
| Failed to configure a DataSource | application.yml路径不对或数据库没启动 | 检查src/main/resources下配置文件是否存在，MySQL服务是否启动 |
| Access denied for user 'root'@'localhost' | 数据库用户名或密码错误 | 核对yml配置，注意不要有隐藏空格 |
| 中文乱码 | URL连接串没设置characterEncoding | 在JDBC URL后加useUnicode=true&characterEncoding=utf8 |
| 前端请求报404 | 代理没生效或后端路径不匹配 | 检查vue.config.js的proxy配置，用浏览器的Network面板看实际请求URL |
| 前端请求跨域报CORS | 没有配置允许跨域 | 开发环境用代理，生产环境用Nginx转发，后端配置CorsFilter兜底 |
| Invalid bound statement | Mapper接口和XML文件没有对应 | 检查Mapper接口全类名和XML的namespace是否一致 |
| java.lang.NullPointerException: mapper | 忘记在启动类或配置类上加@MapperScan | 启动类加@MapperScan("com.example.mall.mapper") |
| JWT或Shiro/JWT的401跳转登录页 | 拦截器放行路径没写对 | 核对登录接口路径是否在excludePathPatterns中 |
4.2 购物车数量“不翼而飞”的排查记录
这里分享一个让我排查了很久的bug：用户刷新页面后，右上角购物车角标显示的永远是0，但进入购物车页面能看到商品。
排查思路是这样的：角标数量是页面加载后在Vuex的created生命周期里调getCartCount接口获取的。但cartCount的初始值是0，刷新页面后Vuex状态是全新的，需要重新拉取。而我的导航栏组件在created里调用了this.$store.dispatch('fetchCartCount')，这个action却依赖登录状态——如果localStorage里有token但用户信息还没被重新拉到Vuex里，dispatch里就取不到userId，接口返回0。
问题不在后端，在前端状态管理的时序上。修复方案是：在路由守卫router.beforeEach里，先检查token，有token就调fetchUserInfo把用户信息拉进Vuex，然后放行。导航栏组件则监听用户信息变化，用户信息加载完成后再调fetchCartCount。组件之间通过Vuex这个“全局状态层”协作，而不是各自为政。
这个案例想说的是：前后端分离项目里，很多看似莫名其妙的问题，根源都在前端的数据加载时机上。排查时先看Network请求有没有发出去、请求头带没带token、返回的数据是什么，按流程一步步缩小范围，不要瞎猜。
4.3 库存超卖与并发扣减的兜底方案
商城系统答辩时，老师大概率会问：“电商系统怎么防止超卖？”这时候如果你回答“先查询库存，如果库存大于0就执行更新”，那就踩坑了——两个请求同时查到库存还剩1，同时走更新，库存在那一瞬间就变成-1了。
正确做法是使用数据库的行锁和乐观锁思维。前面贴的扣减SQL用了WHERE stock >= #{quantity}这个条件，这就是一个典型的乐观锁方案。当并发请求同时到达，MySQL的行锁会让后到的那个请求等待，原子更新只会让其中一个成功，另一个影响行数为0，Service层判断影响行数为0后抛异常“库存不足”，事务回滚，前端提示用户“手慢了，商品卖完啦”。
这个方案简单有效，是电商库存扣减的最基础实现。如果要在毕设里再拔高一层，可以聊聊Redis预减库存配合消息队列异步落库，但如果没有实际测试数据支撑，建议不要作为论文的核心创新点，容易在答辩时被追问细节而回答不上来。把“数据库原子扣减”讲清楚、讲明白，已经足够。
5. 论文写作与答辩准备要点
5.1 LW（论文/说明文档）的结构安排与写作思路
毕业设计论文不是写使用说明书，而是把你的设计过程和思考逻辑完整呈现出来。我常用的论文结构是六章：
- 第一章 绪论：研究背景与意义、国内外研究现状、主要工作内容。现状调研要引用具体的文献，不要空谈“随着互联网的发展”。
- 第二章 相关技术介绍：SpringBoot、MyBatis-Plus、MySQL、Redis、Vue。每个技术写2-4段即可，重点写“为什么选它”，不要大段抄官方文档。
- 第三章 系统分析：可行性分析（技术、经济、操作）、需求分析（功能性需求、非功能性需求）、用例图。
- 第四章 系统设计：系统架构图、功能模块设计、数据库表设计（ER图 + 表结构说明）、关键接口设计。
- 第五章 系统实现：按功能模块逐章展示页面截图，配合核心代码片段。实现和设计最大的区别是：设计说“我要做什么、怎么考虑的”，实现说“我做出来了、效果是什么样”。
- 第六章 系统测试：功能测试用例表、测试结果分析、兼容性测试。这一章往往被忽视，但对毕设来说非常重要——它是你“系统真的能用”的书面证据。
特别提醒：写完论文之后，把第五章的页面截图全部重新跑一遍项目再截，不要用开发过程中的旧图。数据要一致、时间要连贯，否则答辩老师对比一看就发现是拼凑的，印象分直接崩。
5.2 答辩时的高频追问与应答思路
答辩环节，老师一般会针对几个方向提问。我整理了高频五问，每个问题都给出应答思路：
- 问：为什么用JWT做登录鉴权，和Session有什么区别？答：Session存储在服务端，扩展时需要维护会话状态；JWT把用户信息加密放在token里，服务端无状态，适合前后端分离和分布式环境。但要补充一句JWT的缺点——无法主动失效，所以可以结合Redis黑名单或设置较短过期时间。
- 问：购物车和订单的数据是怎么流转的？答：先说表结构（cart_item的checked字段），再说下单时序（勾选条目 -> 生成订单 -> 扣库存 -> 清空购物车），强调事务保证多条数据一致性。
- 问：商品搜索是怎么实现的？答：我的实现是数据库LIKE模糊查询，数据量小够用。如果要优化，可以引入Elasticsearch或MySQL全文索引，但当前需求下LIKE在性能和数据量上是可以接受的。
- 问：页面上的销量数据从哪来？答：order_item表聚合统计——在商品表冗余了sales字段，下单支付成功后事务里同步累加，展示时直接查product表，避免实时聚合大表。
- 问：如果商品库存只剩1件，两个人同时下单怎么办？答：讲乐观锁扣减库存的SQL写法，说明MySQL行锁的作用，以及影响行数为0时的回滚处理。
这些问题的核心逻辑是“让老师感受到你真的动手做了，而且思考过为什么”。答案要点到为止，不要背诵长篇理论，用项目里的实际代码回答远比背概念有说服力。
6. 个人经验与后续扩展
做完整个SpringBoot运动用品商城，我自己的体会是：毕设项目的价值不在于功能堆得多高，而在于把一个核心流程做到闭环、做得扎实。哪怕你只是把“用户—商品—购物车—订单”这条链路实现得足够稳定，把每个模块的“为什么”想清楚，在答辩和求职介绍项目时，都比东拼西凑十个模块的空壳更有说服力。
最后再分享一个实操中的小技巧：开发过程中养成“每次改动跑一遍核心链路”的习惯——登录、加购、下单、后台发货、用户确认收货，全流程只花两分钟，但能第一时间发现接口被改坏的问题。不要攒到最后一起测，那时候bug扎堆出现，定位成本会翻好几倍。
如果学有余力，这个项目还可以往这些方向扩展：接入支付宝沙箱支付、引入RabbitMQ做订单超时取消、用Elasticsearch做商品全文检索、增加基于Redis的每日热销榜单、给后台加一个ECharts销售额可视化报表。这些扩展每做一个，都是论文里一个很扎实的“系统优化”小节，也是真正拉开你和同组同学差距的地方。
