简介面向毕业设计、课程设计及Spring Boot技术学习者这套资源是一份完整可运行的网上商城购物系统毕业设计项目资料。系统采用Spring Boot框架与MySQL数据库围绕管理员、用户及前台首页三个层面进行设计涵盖用户管理、商品分类管理、商品信息管理、订单评价管理、系统管理、订单管理、我的收藏管理、购物车、在线客服等常用功能针对传统纸质工具管理效率低的问题提供了高效、统一、易维护的信息化管理方案。压缩包为zip格式整体约32.83MB主要包含项目源码、部署文档、毕业论文和答辩PPT源码注重可读性、扩展性和易用性部署文档可辅助快速完成环境配置论文和PPT则覆盖课题背景、系统设计、实现与测试等完整写作环节。该资源已有746人浏览学习适合需要快速搭建商城系统、完成毕业设计或希望系统掌握Spring Boot整合开发的学生与开发者能够有效节省从零开发及整理材料的时间。1. Spring Boot 网上商城购物系统解决的是「能讲清楚」的问题Spring Boot 网上商城购物系统是 Java 后端里出现频率最高的项目形态GitHub 和各类毕设站点上同名项目数以千计。这类项目的标准交付物是源码、部署文档、论文和 PPT目标用户非常明确准备毕设的学生、要在一周内攒出完整后端经历的转岗者以及刚接手一个商城维护任务、需要快速看懂既有代码的新人。一个反直觉的事实是这类项目最容易暴露问题的不是登录也不是商品列表而是订单。库存扣减有没有防超卖、订单号怎么生成、订单状态怎么流转这三个问题才是源码之外评审和面试官真正会追问的地方。所以这篇按「拿到源码 → 读懂核心业务 → 部署跑通 → 组织论文与答辩 → 上线前收尾」的顺序逐层展开最后让一套商城交付物从「能跑」变成「能讲」。2. 拿到源码先看什么Spring Boot 商城系统的结构与选型2.1 技术选型Spring Boot 2.7 还是 3.xORM 选谁这类网上商城购物系统的技术栈高度同质化标配是 Spring Boot MyBatis-Plus MySQL Redis。Spring Boot 2.7.18 是 2.x 分支最后一个 OSS 版本依赖兼容性最好如果项目描述里写明基于 JDK 8 开发代码里还大量出现javax.servlet的 import就老老实实留在 2.x。Spring Boot 3.x 强制要求 Java 17 和jakarta.*命名空间强行升级会让一堆第三方 starter 失效。很多人抱怨 Spring Boot 版本太高导致教程跑不通多半是拿 2.x 的代码硬跑 3.x 的环境。ORM 层面 MyBatis-Plus 在中小型系统里比 JPA 更常见原因很实际单表 CRUD 不用写 XMLIService自带save、list、page新手和评审都能一眼看懂复杂统计报表再补 XML 也不迟。前端如果是基于 Spring Boot Vue 的项目通常是 Vue3 Element Plus Axios用户端和管理端拆成两套页面如果服务器内存只有 2G用 Thymeleaf 做服务端渲染更省资源部署时也少一层跨域问题。组件常见选择选型理由风险点基础框架Spring Boot 2.7.x生态成熟JDK 8 友好3.x 升级需改命名空间与配置ORMMyBatis-Plus单表零 SQL分页内置复杂连表需手写 XML数据库MySQL 8.0事务与行锁机制成熟驱动类名和时区配置易错缓存/会话Redis购物车、热点商品、分布式 Session连接池参数随 Boot 版本变化前端Vue3 Element Plus组件全后台管理开发快CORS 和 Token 传递需约定2.2 分层目录先读 common 和 config再读订单拿到源码包不要急着启动先花十分钟把目录过一遍。多数商城项目的包结构是entity / mapper / service / controller四层再加上common和config两个横向包src/main/java/com/example/mall ├── MallApplication.java ├── common # 统一返回、业务异常、常量 │ ├── Result.java │ └── BizException.java ├── config # 跨域、Redis 序列化、拦截器 ├── controller # 只做参数接收与路由 ├── service # 业务逻辑事务在这里 ├── mapper # MyBatis-Plus 接口 ├── entity # 表映射 └── util # JWT、订单号生成等工具 src/main/resources ├── application.yml ├── application-dev.yml └── mapper/*.xml读源码的顺序我一般按common→config→entity→mapper→service来。common里的Result类决定了所有接口的返回结构前端 axios 拦截器就是按它写的config里能看出登录拦截器拦了哪些路径、放行了哪些路径。这两个包看明白整个项目的调用约定就清楚了。接着打开pom.xml确认 Spring Boot 版本、MyBatis-Plus 版本和是否引入了spring-boot-starter-data-redis这三样决定了部署文档里的环境要求。2.3 配置文件的三个坑时区、驱动、Redis 参数application.yml是部署时改动最多的文件最常见的配置长这样spring: datasource: url: jdbc:mysql://127.0.0.1:3306/mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver data: redis: host: 127.0.0.1 port: 6379 password: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath*:mapper/*.xml global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里有几个反复踩的坑。第一MySQL 8 的驱动类必须是com.mysql.cj.jdbc.DriverURL 里不带serverTimezone会直接报时区异常第二Spring Boot 2.4 之后 Redis 配置从spring.redis挪到了spring.data.redis旧教程里的spring.redis.host在新版本里不生效第三mybatis-plus的逻辑删除配置只对 MP 自带方法生效手写 XML 里的 SQL 不会自动追加deleted0需要自己拼接。配置文件里的每个参数背后都对应一次启动失败部署文档里把这三条写清楚比写一千字介绍都有用。3. 核心业务代码在写什么购物车、下单与库存扣减3.1 表结构设计金额、库存、状态三件事最要紧商城系统表多但核心链路其实只有六张用户表、商品 SKU 表、库存表、购物车表、订单表和订单明细表。表设计的好坏直接决定后续代码的复杂度表名核心字段设计要点userid, username, password, phone密码存 BCrypt 哈希不存明文skuid, name, price, image, status价格用 decimal(10,2)单位是元sku_stocksku_id, stock, locked_stock锁定库存用于预扣与 sku 一对一cartid, user_id, sku_id, quantity加唯一索引 (user_id, sku_id) 防重复orderid, order_no, user_id, total_amount, statusorder_no 唯一索引业务幂等靠它order_itemid, order_id, sku_id, price, quantity冗余商品快照商品改价不影响历史订单金额字段用decimal(10,2)而不是double这是评审最喜欢问的点回答「浮点数有精度问题金额必须用定点数」就能过关。订单状态用tinyint配合常量类或枚举不要直接存中文状态流转时比较数字比比较字符串可靠。3.2 下单接口的防超卖事务加乐观锁下单是全文最值得精读的一段代码核心逻辑只有三步查 SKU、扣库存、生成订单。难点在并发场景下库存不能扣成负数。MyBatis-Plus 的updateById做不了条件更新必须手写 XML 做原子扣减Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, Long skuId, Integer quantity) { // 1. 校验 SKU 是否存在且上架 Sku sku skuMapper.selectById(skuId); if (sku null || sku.getStatus() ! 1) { throw new BizException(商品不存在或已下架); } // 2. 原子扣减库存受影响行数为 0 表示库存不足 int rows skuStockMapper.deduct(skuId, quantity); if (rows 0) { throw new BizException(库存不足); } // 3. 生成订单号并落库 Order order new Order(); order.setOrderNo(OrderNoGenerator.generate()); order.setUserId(userId); order.setSkuId(skuId); order.setTotalAmount(sku.getPrice().multiply(BigDecimal.valueOf(quantity))); order.setStatus(OrderStatus.WAIT_PAY); orderMapper.insert(order); return order; }update iddeduct UPDATE sku_stock SET stock stock - #{quantity} WHERE sku_id #{skuId} AND stock #{quantity} /update这段代码的关键在stock #{quantity}这个条件UPDATE 语句自带行锁两个并发请求同时进来时第二个请求会等第一个提交后再执行此时库存已经减少stock quantity不成立受影响行数为 0直接抛「库存不足」。比先 SELECT 再 UPDATE 的经典误用安全得多。配合Transactional保证扣库存和生成订单要么都成功要么都回滚不会出现扣了库存但订单没建成的中间状态。下单接口还需要幂等保护。常见做法是前端在提交时生成一个请求号后端用order_no的唯一索引兜底重复插入直接捕获DuplicateKeyException转成「请勿重复提交」。这个点面试官一定会追问答出来就比大部分候选人深一层。3.3 购物车MySQL 表够用Redis 更灵活购物车有两条实现路线。数据量小、只做登录态购物的系统直接用cart表userId skuId做唯一索引增删改查都是单表操作代码最简单需要支持游客购物车、登录后合并、自动过期清理的系统用 Redis Hash 更合适。public void addToCart(Long userId, Long skuId, Integer quantity) { String key cart: userId; // opsForHash 对应 HSET 命令商品 ID 作 field数量作 value stringRedisTemplate.opsForHash().increment(key, skuId.toString(), quantity); // 设置 7 天过期游客购物车到期自动清理 stringRedisTemplate.expire(key, Duration.ofDays(7)); }increment方法对应 Redis 的HINCRBY对不存在的 field 会自动从 0 开始累加天然支持「再加一件」的场景。购物车商品数量用字符串存储读取时再转Integer这是 Redis 客户端 API 的约定。选型时把握一条线如果后台要做购物车弃购分析、要按用户维度查历史加购记录老老实实落 MySQL如果主要目标是抗住大促峰值Redis 更合适。对小型的 Spring Boot 网上商城购物系统来说MySQL 表方案已经覆盖九成需求。3.4 统一返回和异常处理所有接口的约定public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.code 200; r.message success; r.data data; return r; } public static T ResultT error(BizException e) { ResultT r new Result(); r.code e.getCode(); r.message e.getMessage(); return r; } }这个Result是所有 controller 的返回类型。前端 axios 拦截器的逻辑就是code 200走业务处理、否则弹message。实际项目里我见过不少「controller 各写各的返回结构」的代码前端对接的人最痛苦。统一返回配上全局异常处理器RestControllerAdvice把BizException、参数校验异常、兜底Exception分别映射到不同 code整个项目异常处理的脉络就清晰了。4. 部署文档从 IDEA 到服务器的一键跑通路径4.1 本地跑通的最小操作序列拿到部署文档第一步永远是在本地把系统跑起来而不是直接上服务器。最小操作序列只有四条命令# 1. 建库并导入初始数据 mysql -uroot -p doc/sql/init.sql # 2. 打包跳过测试减少干扰 mvn clean package -DskipTests # 3. 启动指定开发环境配置 java -jar target/mall-0.0.1-SNAPSHOT.jar --spring.profiles.activedev # 4. 验证 curl -s http://127.0.0.1:8080/api/product/list | head每条命令都有对应的排错方向。导入 SQL 失败八成是 MySQL 版本差异或字符集不对检查init.sql头部是否带了CREATE DATABASE语句mvn package报错先看是不是 JDK 版本不匹配jar 启动后立刻退出直接看日志里的APPLICATION FAILED TO START这一行会明确指出哪个 Bean 初始化失败。端口被占用用lsof -i:8080查查到后换端口或杀进程。部署文档里把这些失败场景和对应解法写成对照表比只贴命令实用得多。4.2 服务器部署systemd 托管和 Nginx 反向代理服务器部署比本地多三件事数据库初始化、进程托管、静态资源分离。进程托管不要用nohup java -jar写一个 systemd service 文件崩溃自动拉起开机自启[Unit] DescriptionMall Shopping Service Afternetwork.target [Service] Usermall WorkingDirectory/opt/mall ExecStart/usr/bin/java -Xms512m -Xmx512m -jar /opt/mall/mall.jar --spring.profiles.activeprod Restartalways RestartSec5 SuccessExitStatus143 [Install] WantedBymulti-user.targetRestartalways表示进程异常退出后 5 秒自动重启SuccessExitStatus143是 systemd 识别 Spring Boot 优雅停机的关键少了这一行systemctl stop会被判定为失败。前端打包后的dist目录交给 NginxJava 只负责提供/api/接口这是最常见的部署拓扑server { listen 80; server_name mall.example.com; # 静态资源直接返回不经过 Java location / { root /opt/mall/frontend/dist; try_files $uri $uri/ /index.html; } # API 请求反向代理到 Spring Boot location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }proxy_pass http://127.0.0.1:8080;末尾不带路径等于把完整的/api/xxx原样转发给后端如果写成http://127.0.0.1:8080/路径会被截掉一段接口直接 404。这个细节是前端同事接手时最容易卡住的地方。4.3 环境隔离dev 和 prod 配置拆分部署文档必须明确配置文件的环境隔离。Spring Boot 原生支持spring.profiles.active更常见的做法是拆成多份 YAML配置文件用途典型差异application.yml公共配置端口、Jackson、MyBatis-Plusapplication-dev.yml本地开发本机 MySQL、Redis日志级别 DEBUGapplication-prod.yml线上运行服务器地址、连接池上限、日志级别 INFO线上配置里有两个参数我建议部署时顺手调整spring.datasource.hikari.maximum-pool-size默认 10对单机商城系统偏大压测时容易把数据库连接打满改成 5 足够logging.file.name指定日志文件路径配合logback-spring.xml按天滚动。服务起不来先部署文档先 Ping 一下文档里写没写「本地数据库密码和线上密码不一样」这句话很多部署事故都是拿 dev 配置跑 prod 环境造成的。5. 论文与 PPT把源码组织成能答辩的材料5.1 论文结构从代码生成素材而不是反过来论文写作最容易犯的错是先把架构图画得天花乱坠回头发现代码里根本没有对应实现。正确的顺序应当是从源码倒推素材先导表结构生成 ER 图再按 controller 路由导出接口清单最后对着 service 方法画时序图确保论文里的每一个图都能在代码里找到对应文件。# 从 controller 里提取接口清单作为论文「系统实现」章节的素材 for f in $(find src/main/java -path *controller*.java); do echo $f grep -E (Get|Post|Put|Delete)Mapping|public Result $f done这段脚本把每个 controller 暴露的 HTTP 方法、路径和返回类型打出来整理后就是论文里接口设计表的内容。时序图不要画得太复杂画「用户下单」这一条主线就够前端提交订单 → controller 接收 → service 开启事务 → 扣减库存 → 生成订单 → 返回结果。这张图配合 3.2 节的代码是答辩时最能体现技术深度的两张图。使用场景部分写购物流程时每一步都要对应一个已经截图存档的真实页面截图比文字更有说服力。5.2 PPT 演示路线与预置数据准备PPT 的总页数控制在 10 到 12 页其中系统演示别超过三分之一的时间。演示路线的顺序比内容重要照着下单主链路走不要跳来跳去登录 → 商品列表 → 详情 → 加购物车 → 提交订单 → 模拟支付回调 → 后台发货 → 物流状态更新。演示前必须准备预置数据直接在 MySQL 里造-- 预置一个演示账号和库存充足的商品 INSERT INTO user (id, username, password) VALUES (1, demo, $2a$10$...); INSERT INTO sku (id, name, price, status) VALUES (1001, 演示商品, 99.90, 1); INSERT INTO sku_stock (sku_id, stock, locked_stock) VALUES (1001, 100, 0); -- 清空演示账号的历史订单保证演示链路干净 DELETE FROM order WHERE user_id 1;密码的$2a$10$前缀是 BCrypt 哈希直接复制代码里已有的用户密码哈希即可不用手动生成。演示到支付环节时真实支付需要商户资质这类系统演示时用「模拟支付回调」按钮代替点击后后端调用一次支付成功的回调接口把订单状态从待支付改成已支付——这个设计本身就是论文「系统测试」章节的一个可讲点。答辩追问环节评审通常会挑软肋打。最常问的四类问题提前准备追问点回答里要带出的技术点并发下单库存会不会变负数原子 UPDATE 条件扣减 事务回滚订单号怎么生成会不会重复时间戳 用户 ID 随机数数据库唯一索引兜底登录状态怎么做JWT Token 拦截器鉴权Redis 存 Token 黑名单支付安全怎么保证模拟支付回调验签 订单状态机防重复回调有些前端同事接过这类 Spring Boot 项目后问后端能不能直接上手改答案是能但最先改的通常是Result的返回结构和跨域配置。答辩时如果被问前端内容只要说得清 axios 怎么读Result、路由守卫怎么校验登录态就算合格。6. 上线前要改的三个点敏感端点、配置绑定与并发验证6.1 先关掉 Actuator 的敏感端点Spring Boot 商城项目如果引入了spring-boot-starter-actuator默认只暴露health但不少源码为了演示方便会把management.endpoints.web.exposure.include设成*。线上环境这就是一个敏感信息泄露漏洞/actuator/heapdump能下载整个 JVM 堆转储里面可能含有数据库密码、Token、用户信息/actuator/env会列出全部配置项。上线前把暴露范围收窄到健康检查即可management: endpoints: web: exposure: include: health,info如果确实需要metrics、loggers这些端点配合management.endpoint.health.show-detailsnever和访问认证一起用。这条改动量最小但对安全评审价值最大。6.2 用 ConfigurationProperties 收敛散落的配置项源码里经常能看到Value(${mall.jwt.secret})这种写法配置项少时没问题一旦超过五个维护起来就乱。更好的做法是把一组相关配置收敛到一个类里Component ConfigurationProperties(prefix mall.jwt) public class JwtProperties { /** 签名密钥生产环境务必用环境变量注入 */ private String secret; /** Token 有效期默认 2 小时 */ private Duration expire Duration.ofHours(2); // getter / setter 省略 }对应的application.yml里写mall.jwt.secret和mall.jwt.expire即可。相比ValueConfigurationProperties的优势是类型安全Duration类型可以直接写2hSpring 自动完成字符串到对象的转换写错时启动阶段就会报错不会等到运行期才炸。修改代码时属性字段集中在一个类里IDE 重构也方便。6.3 并发下单的快速验证写段脚本看库存下限上线或答辩前用一段脚本验证防超卖是否真的生效。起 20 个并发请求抢同一件商品然后看库存和订单数能不能对得上for i in $(seq 1 20); do curl -s -X POST http://127.0.0.1:8080/api/order \ -H Content-Type: application/json \ -d {userId:1,skuId:1001,quantity:1} /tmp/order_$i.json done wait grep -l 库存不足 /tmp/order_*.json | wc -l mysql -uroot -p -e SELECT stock FROM mall.sku_stock WHERE sku_id 1001;观察两个数库存剩余数量加上成功下单数应等于初始库存 100库存不足的响应数量应等于失败请求数。库存出现负数说明 3.2 节的原子扣减没生效回查 XML 里是不是少了stock #{quantity}条件订单数超过库存说明事务边界不对可能有请求绕过了扣库存直接插订单。把这条验证逻辑写进部署文档的验收清单整个交付物才算闭环。本文还有配套的精品资源点击获取 
长河君 · 2026/9/16 5:20:31 · 阅读 1.2k Spring Boot网上商城购物系统全解析：从源码到部署答辩
简介面向毕业设计、课程设计及Spring Boot技术学习者这套资源是一份完整可运行的网上商城购物系统毕业设计项目资料。系统采用Spring Boot框架与MySQL数据库围绕管理员、用户及前台首页三个层面进行设计涵盖用户管理、商品分类管理、商品信息管理、订单评价管理、系统管理、订单管理、我的收藏管理、购物车、在线客服等常用功能针对传统纸质工具管理效率低的问题提供了高效、统一、易维护的信息化管理方案。压缩包为zip格式整体约32.83MB主要包含项目源码、部署文档、毕业论文和答辩PPT源码注重可读性、扩展性和易用性部署文档可辅助快速完成环境配置论文和PPT则覆盖课题背景、系统设计、实现与测试等完整写作环节。该资源已有746人浏览学习适合需要快速搭建商城系统、完成毕业设计或希望系统掌握Spring Boot整合开发的学生与开发者能够有效节省从零开发及整理材料的时间。1. Spring Boot 网上商城购物系统解决的是「能讲清楚」的问题Spring Boot 网上商城购物系统是 Java 后端里出现频率最高的项目形态GitHub 和各类毕设站点上同名项目数以千计。这类项目的标准交付物是源码、部署文档、论文和 PPT目标用户非常明确准备毕设的学生、要在一周内攒出完整后端经历的转岗者以及刚接手一个商城维护任务、需要快速看懂既有代码的新人。一个反直觉的事实是这类项目最容易暴露问题的不是登录也不是商品列表而是订单。库存扣减有没有防超卖、订单号怎么生成、订单状态怎么流转这三个问题才是源码之外评审和面试官真正会追问的地方。所以这篇按「拿到源码 → 读懂核心业务 → 部署跑通 → 组织论文与答辩 → 上线前收尾」的顺序逐层展开最后让一套商城交付物从「能跑」变成「能讲」。2. 拿到源码先看什么Spring Boot 商城系统的结构与选型2.1 技术选型Spring Boot 2.7 还是 3.xORM 选谁这类网上商城购物系统的技术栈高度同质化标配是 Spring Boot MyBatis-Plus MySQL Redis。Spring Boot 2.7.18 是 2.x 分支最后一个 OSS 版本依赖兼容性最好如果项目描述里写明基于 JDK 8 开发代码里还大量出现javax.servlet的 import就老老实实留在 2.x。Spring Boot 3.x 强制要求 Java 17 和jakarta.*命名空间强行升级会让一堆第三方 starter 失效。很多人抱怨 Spring Boot 版本太高导致教程跑不通多半是拿 2.x 的代码硬跑 3.x 的环境。ORM 层面 MyBatis-Plus 在中小型系统里比 JPA 更常见原因很实际单表 CRUD 不用写 XMLIService自带save、list、page新手和评审都能一眼看懂复杂统计报表再补 XML 也不迟。前端如果是基于 Spring Boot Vue 的项目通常是 Vue3 Element Plus Axios用户端和管理端拆成两套页面如果服务器内存只有 2G用 Thymeleaf 做服务端渲染更省资源部署时也少一层跨域问题。组件常见选择选型理由风险点基础框架Spring Boot 2.7.x生态成熟JDK 8 友好3.x 升级需改命名空间与配置ORMMyBatis-Plus单表零 SQL分页内置复杂连表需手写 XML数据库MySQL 8.0事务与行锁机制成熟驱动类名和时区配置易错缓存/会话Redis购物车、热点商品、分布式 Session连接池参数随 Boot 版本变化前端Vue3 Element Plus组件全后台管理开发快CORS 和 Token 传递需约定2.2 分层目录先读 common 和 config再读订单拿到源码包不要急着启动先花十分钟把目录过一遍。多数商城项目的包结构是entity / mapper / service / controller四层再加上common和config两个横向包src/main/java/com/example/mall ├── MallApplication.java ├── common # 统一返回、业务异常、常量 │ ├── Result.java │ └── BizException.java ├── config # 跨域、Redis 序列化、拦截器 ├── controller # 只做参数接收与路由 ├── service # 业务逻辑事务在这里 ├── mapper # MyBatis-Plus 接口 ├── entity # 表映射 └── util # JWT、订单号生成等工具 src/main/resources ├── application.yml ├── application-dev.yml └── mapper/*.xml读源码的顺序我一般按common→config→entity→mapper→service来。common里的Result类决定了所有接口的返回结构前端 axios 拦截器就是按它写的config里能看出登录拦截器拦了哪些路径、放行了哪些路径。这两个包看明白整个项目的调用约定就清楚了。接着打开pom.xml确认 Spring Boot 版本、MyBatis-Plus 版本和是否引入了spring-boot-starter-data-redis这三样决定了部署文档里的环境要求。2.3 配置文件的三个坑时区、驱动、Redis 参数application.yml是部署时改动最多的文件最常见的配置长这样spring: datasource: url: jdbc:mysql://127.0.0.1:3306/mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver data: redis: host: 127.0.0.1 port: 6379 password: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 mybatis-plus: mapper-locations: classpath*:mapper/*.xml global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这里有几个反复踩的坑。第一MySQL 8 的驱动类必须是com.mysql.cj.jdbc.DriverURL 里不带serverTimezone会直接报时区异常第二Spring Boot 2.4 之后 Redis 配置从spring.redis挪到了spring.data.redis旧教程里的spring.redis.host在新版本里不生效第三mybatis-plus的逻辑删除配置只对 MP 自带方法生效手写 XML 里的 SQL 不会自动追加deleted0需要自己拼接。配置文件里的每个参数背后都对应一次启动失败部署文档里把这三条写清楚比写一千字介绍都有用。3. 核心业务代码在写什么购物车、下单与库存扣减3.1 表结构设计金额、库存、状态三件事最要紧商城系统表多但核心链路其实只有六张用户表、商品 SKU 表、库存表、购物车表、订单表和订单明细表。表设计的好坏直接决定后续代码的复杂度表名核心字段设计要点userid, username, password, phone密码存 BCrypt 哈希不存明文skuid, name, price, image, status价格用 decimal(10,2)单位是元sku_stocksku_id, stock, locked_stock锁定库存用于预扣与 sku 一对一cartid, user_id, sku_id, quantity加唯一索引 (user_id, sku_id) 防重复orderid, order_no, user_id, total_amount, statusorder_no 唯一索引业务幂等靠它order_itemid, order_id, sku_id, price, quantity冗余商品快照商品改价不影响历史订单金额字段用decimal(10,2)而不是double这是评审最喜欢问的点回答「浮点数有精度问题金额必须用定点数」就能过关。订单状态用tinyint配合常量类或枚举不要直接存中文状态流转时比较数字比比较字符串可靠。3.2 下单接口的防超卖事务加乐观锁下单是全文最值得精读的一段代码核心逻辑只有三步查 SKU、扣库存、生成订单。难点在并发场景下库存不能扣成负数。MyBatis-Plus 的updateById做不了条件更新必须手写 XML 做原子扣减Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, Long skuId, Integer quantity) { // 1. 校验 SKU 是否存在且上架 Sku sku skuMapper.selectById(skuId); if (sku null || sku.getStatus() ! 1) { throw new BizException(商品不存在或已下架); } // 2. 原子扣减库存受影响行数为 0 表示库存不足 int rows skuStockMapper.deduct(skuId, quantity); if (rows 0) { throw new BizException(库存不足); } // 3. 生成订单号并落库 Order order new Order(); order.setOrderNo(OrderNoGenerator.generate()); order.setUserId(userId); order.setSkuId(skuId); order.setTotalAmount(sku.getPrice().multiply(BigDecimal.valueOf(quantity))); order.setStatus(OrderStatus.WAIT_PAY); orderMapper.insert(order); return order; }update iddeduct UPDATE sku_stock SET stock stock - #{quantity} WHERE sku_id #{skuId} AND stock #{quantity} /update这段代码的关键在stock #{quantity}这个条件UPDATE 语句自带行锁两个并发请求同时进来时第二个请求会等第一个提交后再执行此时库存已经减少stock quantity不成立受影响行数为 0直接抛「库存不足」。比先 SELECT 再 UPDATE 的经典误用安全得多。配合Transactional保证扣库存和生成订单要么都成功要么都回滚不会出现扣了库存但订单没建成的中间状态。下单接口还需要幂等保护。常见做法是前端在提交时生成一个请求号后端用order_no的唯一索引兜底重复插入直接捕获DuplicateKeyException转成「请勿重复提交」。这个点面试官一定会追问答出来就比大部分候选人深一层。3.3 购物车MySQL 表够用Redis 更灵活购物车有两条实现路线。数据量小、只做登录态购物的系统直接用cart表userId skuId做唯一索引增删改查都是单表操作代码最简单需要支持游客购物车、登录后合并、自动过期清理的系统用 Redis Hash 更合适。public void addToCart(Long userId, Long skuId, Integer quantity) { String key cart: userId; // opsForHash 对应 HSET 命令商品 ID 作 field数量作 value stringRedisTemplate.opsForHash().increment(key, skuId.toString(), quantity); // 设置 7 天过期游客购物车到期自动清理 stringRedisTemplate.expire(key, Duration.ofDays(7)); }increment方法对应 Redis 的HINCRBY对不存在的 field 会自动从 0 开始累加天然支持「再加一件」的场景。购物车商品数量用字符串存储读取时再转Integer这是 Redis 客户端 API 的约定。选型时把握一条线如果后台要做购物车弃购分析、要按用户维度查历史加购记录老老实实落 MySQL如果主要目标是抗住大促峰值Redis 更合适。对小型的 Spring Boot 网上商城购物系统来说MySQL 表方案已经覆盖九成需求。3.4 统一返回和异常处理所有接口的约定public class ResultT { private Integer code; private String message; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.code 200; r.message success; r.data data; return r; } public static T ResultT error(BizException e) { ResultT r new Result(); r.code e.getCode(); r.message e.getMessage(); return r; } }这个Result是所有 controller 的返回类型。前端 axios 拦截器的逻辑就是code 200走业务处理、否则弹message。实际项目里我见过不少「controller 各写各的返回结构」的代码前端对接的人最痛苦。统一返回配上全局异常处理器RestControllerAdvice把BizException、参数校验异常、兜底Exception分别映射到不同 code整个项目异常处理的脉络就清晰了。4. 部署文档从 IDEA 到服务器的一键跑通路径4.1 本地跑通的最小操作序列拿到部署文档第一步永远是在本地把系统跑起来而不是直接上服务器。最小操作序列只有四条命令# 1. 建库并导入初始数据 mysql -uroot -p doc/sql/init.sql # 2. 打包跳过测试减少干扰 mvn clean package -DskipTests # 3. 启动指定开发环境配置 java -jar target/mall-0.0.1-SNAPSHOT.jar --spring.profiles.activedev # 4. 验证 curl -s http://127.0.0.1:8080/api/product/list | head每条命令都有对应的排错方向。导入 SQL 失败八成是 MySQL 版本差异或字符集不对检查init.sql头部是否带了CREATE DATABASE语句mvn package报错先看是不是 JDK 版本不匹配jar 启动后立刻退出直接看日志里的APPLICATION FAILED TO START这一行会明确指出哪个 Bean 初始化失败。端口被占用用lsof -i:8080查查到后换端口或杀进程。部署文档里把这些失败场景和对应解法写成对照表比只贴命令实用得多。4.2 服务器部署systemd 托管和 Nginx 反向代理服务器部署比本地多三件事数据库初始化、进程托管、静态资源分离。进程托管不要用nohup java -jar写一个 systemd service 文件崩溃自动拉起开机自启[Unit] DescriptionMall Shopping Service Afternetwork.target [Service] Usermall WorkingDirectory/opt/mall ExecStart/usr/bin/java -Xms512m -Xmx512m -jar /opt/mall/mall.jar --spring.profiles.activeprod Restartalways RestartSec5 SuccessExitStatus143 [Install] WantedBymulti-user.targetRestartalways表示进程异常退出后 5 秒自动重启SuccessExitStatus143是 systemd 识别 Spring Boot 优雅停机的关键少了这一行systemctl stop会被判定为失败。前端打包后的dist目录交给 NginxJava 只负责提供/api/接口这是最常见的部署拓扑server { listen 80; server_name mall.example.com; # 静态资源直接返回不经过 Java location / { root /opt/mall/frontend/dist; try_files $uri $uri/ /index.html; } # API 请求反向代理到 Spring Boot location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }proxy_pass http://127.0.0.1:8080;末尾不带路径等于把完整的/api/xxx原样转发给后端如果写成http://127.0.0.1:8080/路径会被截掉一段接口直接 404。这个细节是前端同事接手时最容易卡住的地方。4.3 环境隔离dev 和 prod 配置拆分部署文档必须明确配置文件的环境隔离。Spring Boot 原生支持spring.profiles.active更常见的做法是拆成多份 YAML配置文件用途典型差异application.yml公共配置端口、Jackson、MyBatis-Plusapplication-dev.yml本地开发本机 MySQL、Redis日志级别 DEBUGapplication-prod.yml线上运行服务器地址、连接池上限、日志级别 INFO线上配置里有两个参数我建议部署时顺手调整spring.datasource.hikari.maximum-pool-size默认 10对单机商城系统偏大压测时容易把数据库连接打满改成 5 足够logging.file.name指定日志文件路径配合logback-spring.xml按天滚动。服务起不来先部署文档先 Ping 一下文档里写没写「本地数据库密码和线上密码不一样」这句话很多部署事故都是拿 dev 配置跑 prod 环境造成的。5. 论文与 PPT把源码组织成能答辩的材料5.1 论文结构从代码生成素材而不是反过来论文写作最容易犯的错是先把架构图画得天花乱坠回头发现代码里根本没有对应实现。正确的顺序应当是从源码倒推素材先导表结构生成 ER 图再按 controller 路由导出接口清单最后对着 service 方法画时序图确保论文里的每一个图都能在代码里找到对应文件。# 从 controller 里提取接口清单作为论文「系统实现」章节的素材 for f in $(find src/main/java -path *controller*.java); do echo $f grep -E (Get|Post|Put|Delete)Mapping|public Result $f done这段脚本把每个 controller 暴露的 HTTP 方法、路径和返回类型打出来整理后就是论文里接口设计表的内容。时序图不要画得太复杂画「用户下单」这一条主线就够前端提交订单 → controller 接收 → service 开启事务 → 扣减库存 → 生成订单 → 返回结果。这张图配合 3.2 节的代码是答辩时最能体现技术深度的两张图。使用场景部分写购物流程时每一步都要对应一个已经截图存档的真实页面截图比文字更有说服力。5.2 PPT 演示路线与预置数据准备PPT 的总页数控制在 10 到 12 页其中系统演示别超过三分之一的时间。演示路线的顺序比内容重要照着下单主链路走不要跳来跳去登录 → 商品列表 → 详情 → 加购物车 → 提交订单 → 模拟支付回调 → 后台发货 → 物流状态更新。演示前必须准备预置数据直接在 MySQL 里造-- 预置一个演示账号和库存充足的商品 INSERT INTO user (id, username, password) VALUES (1, demo, $2a$10$...); INSERT INTO sku (id, name, price, status) VALUES (1001, 演示商品, 99.90, 1); INSERT INTO sku_stock (sku_id, stock, locked_stock) VALUES (1001, 100, 0); -- 清空演示账号的历史订单保证演示链路干净 DELETE FROM order WHERE user_id 1;密码的$2a$10$前缀是 BCrypt 哈希直接复制代码里已有的用户密码哈希即可不用手动生成。演示到支付环节时真实支付需要商户资质这类系统演示时用「模拟支付回调」按钮代替点击后后端调用一次支付成功的回调接口把订单状态从待支付改成已支付——这个设计本身就是论文「系统测试」章节的一个可讲点。答辩追问环节评审通常会挑软肋打。最常问的四类问题提前准备追问点回答里要带出的技术点并发下单库存会不会变负数原子 UPDATE 条件扣减 事务回滚订单号怎么生成会不会重复时间戳 用户 ID 随机数数据库唯一索引兜底登录状态怎么做JWT Token 拦截器鉴权Redis 存 Token 黑名单支付安全怎么保证模拟支付回调验签 订单状态机防重复回调有些前端同事接过这类 Spring Boot 项目后问后端能不能直接上手改答案是能但最先改的通常是Result的返回结构和跨域配置。答辩时如果被问前端内容只要说得清 axios 怎么读Result、路由守卫怎么校验登录态就算合格。6. 上线前要改的三个点敏感端点、配置绑定与并发验证6.1 先关掉 Actuator 的敏感端点Spring Boot 商城项目如果引入了spring-boot-starter-actuator默认只暴露health但不少源码为了演示方便会把management.endpoints.web.exposure.include设成*。线上环境这就是一个敏感信息泄露漏洞/actuator/heapdump能下载整个 JVM 堆转储里面可能含有数据库密码、Token、用户信息/actuator/env会列出全部配置项。上线前把暴露范围收窄到健康检查即可management: endpoints: web: exposure: include: health,info如果确实需要metrics、loggers这些端点配合management.endpoint.health.show-detailsnever和访问认证一起用。这条改动量最小但对安全评审价值最大。6.2 用 ConfigurationProperties 收敛散落的配置项源码里经常能看到Value(${mall.jwt.secret})这种写法配置项少时没问题一旦超过五个维护起来就乱。更好的做法是把一组相关配置收敛到一个类里Component ConfigurationProperties(prefix mall.jwt) public class JwtProperties { /** 签名密钥生产环境务必用环境变量注入 */ private String secret; /** Token 有效期默认 2 小时 */ private Duration expire Duration.ofHours(2); // getter / setter 省略 }对应的application.yml里写mall.jwt.secret和mall.jwt.expire即可。相比ValueConfigurationProperties的优势是类型安全Duration类型可以直接写2hSpring 自动完成字符串到对象的转换写错时启动阶段就会报错不会等到运行期才炸。修改代码时属性字段集中在一个类里IDE 重构也方便。6.3 并发下单的快速验证写段脚本看库存下限上线或答辩前用一段脚本验证防超卖是否真的生效。起 20 个并发请求抢同一件商品然后看库存和订单数能不能对得上for i in $(seq 1 20); do curl -s -X POST http://127.0.0.1:8080/api/order \ -H Content-Type: application/json \ -d {userId:1,skuId:1001,quantity:1} /tmp/order_$i.json done wait grep -l 库存不足 /tmp/order_*.json | wc -l mysql -uroot -p -e SELECT stock FROM mall.sku_stock WHERE sku_id 1001;观察两个数库存剩余数量加上成功下单数应等于初始库存 100库存不足的响应数量应等于失败请求数。库存出现负数说明 3.2 节的原子扣减没生效回查 XML 里是不是少了stock #{quantity}条件订单数超过库存说明事务边界不对可能有请求绕过了扣库存直接插订单。把这条验证逻辑写进部署文档的验收清单整个交付物才算闭环。本文还有配套的精品资源点击获取