从Java毕设到手机销售网站：Spring Boot全栈实现与部署实战

做毕业设计那会儿，我身边十个同学里起码有六个想做电商项目。手机销售网站算是这类选题里面最好落地的一个——业务模型清楚、功能边界好划分，前台给用户逛，后台给管理员管，Java技术栈又特别成熟，资料随便一搜就是一堆。我当时选这个题目，第一反应是“会不会太普通了”，但做完之后回头看，这种“普通”恰恰是计算机毕设最该有的样子：评阅老师看得懂、答辩时有东西聊、代码量能撑起一篇论文，最关键的是，Java技术栈它能玩出的深度，远比你想象的多。

这篇文章就围绕我实际做下来的完整过程来讲，从选题评估、技术选型、数据库设计，到核心功能实现、自测踩坑、打包部署，再到论文撰写和答辩准备，把你可能遇到的每一个环节都过一遍。如果你正准备做类似的Java毕设，或者正在为“手机销售网站”这个题目挠头，这篇内容可以直接拿来当参考。

1. 选题评估：为什么“手机销售网站”是计算机毕设的稳妥选择

1.1 业务模型清晰带来的天然优势

先说个容易被忽略的事实：毕设翻车的最大原因不是技术难，而是需求不明确。有的同学选了个“智能推荐系统”，结果连推荐的数据从哪来都说不清楚；有的选“企业进销存”，调研了半个月都不知道业务流程是什么样。

手机销售网站完全没有这个问题。它本质上是一个典型的B2C电商系统，业务链路是每个人都在用的东西：注册登录、逛商品、搜手机、加购物车、下单、支付、看订单、退货取消，后台再管商品、品牌、分类、库存、订单发货。你做需求分析的时候，不需要拉着导师解释“这个业务场景是什么意思”，导师也不用费力理解，沟通成本极低。

模型清晰还有一层好处：你可以在业务之上放心地设计技术方案，而不是被业务绕晕。比如订单和订单项的一对多关系、购物车和用户的多对一关系、商品和品牌的多对一关系，这些在电商里早就是成熟的范式了，网上参考案例一抓一大把。你省下来研究业务的时间，完全可以投入到更有含金量的技术细节里。

1.2 技术栈的主流程度与实际工作量核算

Java方向有一个特别成熟的技术组合：Spring Boot + MySQL + MyBatis Plus + Redis（可选）+ 前端模板引擎或分离式Vue。这套组合在企业级开发里是绝对的主流，招聘要求里高频出现，做完这个毕设你对Spring Boot的理解能直接转化为面试聊资。

工作量方面我帮你算一笔账。前台用户端：注册登录、商品列表、商品详情、搜索筛选、购物车、下单、模拟支付、订单查询、个人中心，大概9到10个功能点。后台管理端：管理员登录、商品管理、分类管理、品牌管理、库存管理、订单管理、用户管理，大概7到8个功能点。两边加起来15到20个功能点，核心表8张左右，Java代码大概3000到5000行，论文按学校要求一般1.2万到1.5万字。单个学期做完，时间上是宽裕的。

1.3 从热搜词反推毕设评审关注点

当时我在准备这个项目的时候，顺手翻了翻和Java相关的热搜词，挺有意思。排在前面的基本都是“环境配置”“连接数据库”“排序”“JDK”“八股文”“后端和产品经理怎么确定需求”这类问题。这反过来给了我两个启示。

第一个启示：工具链的顺畅本身就是评审重点。一个Java毕设最让人崩溃的不是业务写不出来，而是JDK版本对不上、数据库连不上、依赖导不进来、打包打不出可执行文件。换句话说，谁能把环境、依赖、数据库连接、部署这套“基建”整明白，谁就已经赢了一半。所以我在后面专门花了很大的篇幅讲环境配置和部署，这部分不是凑字数，是真的容易卡人。

第二个启示：Java基础一定会在项目里被体现。热搜词里有很多“Java排序”“sort函数用法”“数据类型”“面向对象”这类基础词，这些东西不靠背，要靠代码体现。比如商品排序功能，你就能把Comparator、lambda表达式、Stream API串起来讲；订单状态流转，你就能把枚举、状态机、面向对象封装讲清楚。答辩的时候，把“知识点落在具体代码里”讲，远比背一条八股文有说服力。

2. 技术选型与开发环境：先定骨架再写代码

2.1 框架选择的理由：Spring Boot + MyBatis Plus的组合逻辑

框架选型不是随便选的，也不是谁火选谁，而是由你的目标决定的。作为一个一人完成的毕设项目，你的目标只有一个：用最少的时间成本，做出一个结构规范、能跑通、能讲清楚、能过评审的系统。

Spring Boot的核心价值是自动装配和起步依赖。以前用Spring的时候，要配置一大堆XML，Tomcat要单独启动，依赖版本还要自己协调。Spring Boot把这些全部内部消化了，你引入一个spring-boot-starter-web，就自带内嵌Tomcat，mvn spring-boot:run或者直接java -jar就能启动。对于毕设这种规模来说，这一个理由就足够了。

MyBatis Plus的价值更直接：单表CRUD基本不用写SQL。继承一个BaseMapper<T>，连方法签名都不用写就有selectById、insert、updateById；查询条件用LambdaQueryWrapper链式写法，比在XML里维护SQL高效得多。项目里我没选原生MyBatis，因为一张商品表的基础增删改查都要写XML的话，工作量会膨胀三倍以上，没必要。也没选JPA，大部分学生不熟，复杂查询和分页反而别扭，答辩时候被追问也不好圆。MyBatis Plus在国产项目里用得极多，导师一听就懂。

我当时pom.xml的核心依赖是这样配的：

xml复制<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.7.18</version>
    <relativePath/>
</parent>

<properties>
    <java.version>1.8</java.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-thymeleaf</artifactId>
    </dependency>
    <dependency>
        <groupId>com.baomidou</groupId>
        <artifactId>mybatis-plus-boot-starter</artifactId>
        <version>3.5.3.2</version>
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>8.0.33</version>
    </dependency>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
</dependencies>

2.2 JDK环境配置和多版本切换的细节

毕设最常见的坑是版本不对。我当时用的JDK 1.8，也就是Java 8，搭配Spring Boot 2.7.x，这是最稳的组合。Java 8和Spring Boot 2.x的兼容性经过无数项目验证，网上遇到任何报错都能搜到答案。你要是直接上Java 17配Spring Boot 3.x，很多老博客的写法就不适用了，解决报错的时间成本会翻倍。

环境变量配置要搞定三个东西：JAVA_HOME指向JDK安装目录，PATH里加上%JAVA_HOME%\bin，CLASSPATH指向.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar。配置完在命令行执行：

bash复制java -version
javac -version

两个都正常输出，才算到位。

还有个细节特别容易踩坑：电脑里装了多个JDK的时候，改JAVA_HOME只对命令行新开的窗口生效，IDEA里已经打开的进程不会立刻感知。IDEA的Project Structure里指定Project SDK是一处，Settings -> Maven -> JDK for importer是一处，Settings -> Build Tools -> Maven -> Runner里JRE又是一处，三处版本不一致就编译失败。我的习惯是先统一下好JDK 1.8，然后三处全部选同一路径，省得来回折腾。

2.3 数据库选型：MySQL为主，兼容性考虑

数据库我强烈建议用MySQL，版本用5.7或者8.0都行。虽然网上还经常搜到“Java如何连接SQL Server 2008”这种老问题，但那是历史遗留，不是一个新项目该考虑的方向。MySQL开源免费、资料多、Navicat图形化操作方便，驱动配置也简单。

连接配置在application.yml里是这样：

yaml复制spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/phone_shop?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: root
    password: 123456

里面两个参数必须写明白：characterEncoding=utf8保证中文不乱码，serverTimezone=Asia/Shanghai解决数据库时区报错。建库的时候统一用utf8mb4字符集，因为utf8mb4能存emoji表情和一些特殊字符，比utf8更保险。

2.4 前端方案：服务端模板还是前后端分离

这是个绕不开的选择题。我当时考虑过Vue + Spring Boot前后端分离，用axios发请求，用JWT做认证，听起来更“企业级”，但做完才发现一个很现实的问题：前后端分离意味着你要维护两个工程，要处理跨域，要设计接口文档，还要额外准备一套前端页面。

我个人最终选了Thymeleaf服务端模板。理由很直接：Spring Boot内嵌模板引擎，Java渲染页面，Session保持登录状态，不需要处理跨域，不需要额外启动前端项目，调试的时候刷新页面就能看到结果。配合Layui或者Bootstrap这类CSS框架，页面效果完全够用，后台管理界面也很清爽。

如果你想让论文更丰满、内容更多，也可以选前后端分离，把跨域CORS配置、接口风格、JWT拦截器校验这些都写进论文里。但前提是你要有足够的时间余量，别到写论文的时候发现功能没做完，光应付联调就焦头烂额。

3. 数据库设计与核心表结构拆解

3.1 商品、品牌、分类的表关系设计

数据库设计是整个项目的地基，这块出了问题，后面写代码全是补丁。手机销售网站的基础数据是商品，围绕商品我设计了三个基础表：分类表、品牌表、商品表。

分类表category用parent_id字段支持两级分类，比如“手机数码”是一级分类，“智能手机”是二级分类。品牌表brand就很简单了，存品牌名和logo路径。商品表product是核心，外键关联品牌和分类，再加上价格、库存、销量、图片、描述、上下架状态这些字段。

sql复制CREATE TABLE `category` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `category_name` varchar(50) NOT NULL COMMENT '分类名称',
  `parent_id` bigint(20) DEFAULT '0' COMMENT '父分类id，0表示一级分类',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `brand` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `brand_name` varchar(50) NOT NULL COMMENT '品牌名称',
  `logo_url` varchar(255) DEFAULT NULL COMMENT '品牌logo图片路径',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `product` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `brand_id` bigint(20) NOT NULL COMMENT '品牌id',
  `category_id` bigint(20) NOT NULL COMMENT '分类id',
  `product_name` varchar(100) NOT NULL COMMENT '商品名称',
  `price` decimal(10,2) NOT NULL COMMENT '价格',
  `stock` int(11) NOT NULL DEFAULT '0' COMMENT '库存',
  `sales` int(11) NOT NULL DEFAULT '0' COMMENT '销量',
  `image_url` varchar(255) DEFAULT NULL COMMENT '图片路径',
  `description` text COMMENT '商品描述',
  `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '上下架状态：1上架 0下架',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_brand` (`brand_id`),
  KEY `idx_category` (`category_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有两个细节值得说。价格字段用decimal(10,2)而不用double，因为浮点数做金额运算会有精度损失，这是面试官和评审老师都爱挑的点。外键字段brand_id和category_id建了普通索引idx_brand、idx_category，商品列表按品牌筛选时就靠这两个索引提速。

3.2 用户与购物车、订单、订单项的数据流

用户、购物车、订单、订单项这四张表构成了系统的业务核心。用户表user存账号密码、手机号、昵称、头像；购物车表cart关联用户和商品，一个用户对同一商品只允许有一条记录，数量累加；订单表order和订单项表order_item是一对多关系，一次下单生成一个主单和多个明细项。

sql复制CREATE TABLE `user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `username` varchar(50) NOT NULL COMMENT '用户名',
  `password` varchar(100) NOT NULL COMMENT '密码（加密存储）',
  `phone` varchar(20) DEFAULT NULL,
  `email` varchar(50) DEFAULT NULL,
  `avatar` varchar(255) DEFAULT NULL,
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `cart` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) NOT NULL,
  `product_id` bigint(20) NOT NULL,
  `quantity` int(11) NOT NULL DEFAULT '1' COMMENT '购买数量',
  `checked` tinyint(4) DEFAULT '1' COMMENT '是否选中结算',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_user_product` (`user_id`, `product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `t_order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '订单编号',
  `user_id` bigint(20) NOT NULL,
  `total_price` decimal(10,2) NOT NULL COMMENT '订单总金额',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '状态：0待支付 1已支付 2已发货 3已签收 4已取消',
  `receiver_name` varchar(50) DEFAULT NULL,
  `receiver_phone` varchar(20) DEFAULT NULL,
  `receiver_address` varchar(255) DEFAULT NULL,
  `pay_time` datetime DEFAULT NULL,
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`),
  KEY `idx_user` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `order_item` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_id` bigint(20) NOT NULL,
  `product_id` bigint(20) NOT NULL,
  `product_name` varchar(100) NOT NULL,
  `product_image` varchar(255) DEFAULT NULL,
  `price` decimal(10,2) NOT NULL COMMENT '成交价格',
  `quantity` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_order` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

order_item里冗余了product_name和product_image，这也是电商设计的常见做法。订单生成之后商品信息可能改价、可能下架，你要从订单详情里还原当时的快照，就必须依赖冗余字段，不能再去关联商品表查最新数据。

3.3 使用MyBatis Plus实体类反向生成建表SQL的技巧

很多教程教你先写SQL建表再写实体类，但我的习惯是反过来：先把Java实体类写出来，再用实体类反推建表语句。这样做的好处是实体类和表结构一定对得上，不会出现那种“SQL里字段叫user_name，实体类里叫username”的低级错位。

MyBatis Plus里实体类的写法是这样的：

java复制@Data
@TableName("product")
public class Product {
    @TableId(type = IdType.AUTO)
    private Long id;
    @TableField("brand_id")
    private Long brandId;
    @TableField("category_id")
    private Long categoryId;
    private String productName;
    private BigDecimal price;
    private Integer stock;
    private Integer sales;
    private String imageUrl;
    private String description;
    private Integer status;
    private LocalDateTime createTime;
}

@TableName指定表名，@TableId(type = IdType.AUTO)指定主键自增，字段上用@TableField("brand_id")把Java驼峰和数据库下划线对应起来。写完实体类，你就可以对着字段清单去写建表SQL，一一对应，基本不会错。MyBatis Plus本身不需要你手动建表，但它会根据实体类字段自动映射查询列名，所以实体类和表结构的一致性直接决定框架能不能正常跑。

4. 核心功能实现：从用户登录到订单闭环

4.1 用户认证与会话管理

用户模块是整个网站的第一道门，也是答辩时最容易被问到底的地方。注册流程：前端提交用户名、密码、确认密码，后端先做参数校验，再判断用户名是否已存在，最后把密码加密存入数据库。登录流程：按用户名查用户，比对密码，成功就把用户对象放进Session。

密码加密这里必须多说一句。明文存密码是毕设的低级错误，一旦被评审问到“数据库被拖库怎么办”，你就很难圆。我的方案是MD5加盐，虽然现在工业界更推荐BCrypt，但MD5加盐逻辑简单、容易讲清楚，在毕设层面已经能体现安全意识。

java复制@Service
public class UserServiceImpl extends ServiceImpl<UserMapper, User> implements UserService {

    @Override
    public boolean register(User user) {
        LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();
        wrapper.eq(User::getUsername, user.getUsername());
        if (this.count(wrapper) > 0) {
            return false; // 用户名已存在
        }
        String salt = RandomUtil.randomString(8);
        user.setSalt(salt);
        user.setPassword(SecureUtil.md5(user.getPassword() + salt));
        return this.save(user);
    }
}

会话管理用一个拦截器实现。写一个LoginInterceptor，在preHandle里判断session.getAttribute("user")是否为空，为空就重定向到登录页。然后在WebMvcConfigurer里注册拦截路径，注意放行登录页、注册接口、商品列表、商品详情这些用户未登录也能访问的路径。

4.2 商品展示、搜索、排序的实现

商品模块是最能体现Java基础的地方，也是热搜词里“Java排序”“sort函数用法”的实际落点。商品展示要支持分页、按分类筛选、按品牌筛选、按关键词搜索、按销量/价格/上架时间排序。

分页用MyBatis Plus的PaginationInnerInterceptor，配置一次就能全局生效。搜索和筛选用LambdaQueryWrapper链式条件拼接。排序逻辑我是这样设计的：前端传一个sortValue参数，取值有sales_desc（销量降序）、price_asc（价格升序）、price_desc（价格降序）、new_desc（上架时间降序）四种，后端用一个Map映射到具体的排序字段，而不是直接拼接前端传的参数。

java复制private static final Map<String, String> SORT_MAP = new HashMap<>();
static {
    SORT_MAP.put("sales_desc", "sales");
    SORT_MAP.put("price_asc", "price");
    SORT_MAP.put("price_desc", "price");
    SORT_MAP.put("new_desc", "create_time");
}

public Page<Product> getProductPage(int pageNum, int pageSize, Long categoryId, String keyword, String sortValue) {
    Page<Product> page = new Page<>(pageNum, pageSize);
    LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(categoryId != null, Product::getCategoryId, categoryId)
           .like(StrUtil.isNotBlank(keyword), Product::getProductName, keyword)
           .eq(Product::getStatus, 1);
    String sortField = SORT_MAP.getOrDefault(sortValue, "sales");
    if ("price_asc".equals(sortValue)) {
        wrapper.orderByAsc(Product::getPrice);
    } else {
        wrapper.orderByDesc(Product::getPrice);
    }
    return this.page(page, wrapper);
}

写的时候要注意MyBatis Plus的orderBy方法支持lambda表达式引用实体字段，这样连排序字段都是类型安全的，不会写错列名。如果你想在答辩时展示一下Java 8的功底，也可以在内存里用Comparator和Stream流再做一次排序，比如“在数据库查完后，用stream().sorted(Comparator.comparing(Product::getSales).reversed())做一个热点商品排行”，这就直接把热搜词里的排序知识点变成了项目代码。

4.3 购物车与库存扣减的并发控制

购物车逻辑不复杂，核心就三个动作：加购、改数量、删除。加购时先查商品是否存在且是上架状态，然后查购物车表里有没有同一用户同一商品的记录，有就把数量加一，没有就新增一条。购物车的唯一索引uk_user_product保证数据层的幂等性。

真正考验技术的是下单时的库存扣减。这里有个著名的“超卖”问题：假设商品库存只剩1件，100个用户同时下单，如果代码是“先查出库存判断大于0，再执行更新”，那么100个请求都可能看到大于0的库存，然后一起扣减，最终库存变成负数。这是答辩时最容易追问并发场景的点。

我的方案是乐观锁思路，直接让数据库帮我们保证原子性：

sql复制UPDATE product SET stock = stock - 1 
WHERE id = ? AND stock > 0

执行这条SQL，返回受影响行数为1表示扣减成功，为0表示库存不足或商品不存在。一个原子SQL就解决了并发问题，不需要加分布式锁，也不用select for update。在此基础上，下单和扣库存要放在一个事务里，用@Transactional保证要么都成功要么都回滚。

关于@Transactional有个坑得提一嘴：Spring的事务只对通过代理调用的public方法生效，一个Service方法内部调用另一个方法不走代理，事务会失效。另外，事务里别去写耗时操作（比如调用外部模拟支付接口），长事务会占用数据库连接，在高并发下容易出现连接池耗尽。

4.4 订单状态机与支付回调模拟

订单状态不能随便用数字散落在代码里，我用了一个枚举来管理：

java复制public enum OrderStatusEnum {
    WAIT_PAY(0, "待支付"),
    PAID(1, "已支付"),
    SHIPPED(2, "已发货"),
    RECEIVED(3, "已签收"),
    CANCELED(4, "已取消");

    private final int code;
    private final String desc;

    // 构造方法、getter...
}

这样写的好处有两个。一个是代码里不会出现魔法数字，order.setStatus(OrderStatusEnum.PAID.getCode())一眼就能看懂。另一个是状态流转可以写在业务方法里校验，比如只有WAIT_PAY状态的订单才能执行取消操作，只有PAID状态才能发货，非法流转直接抛异常。

支付环节，真实的电商网站要对接第三方支付网关，毕设里做一个模拟支付接口就够了。我的做法是：订单提交成功后，给用户一个“模拟支付”按钮，点击后调用/pay/mock接口，传入订单号，后端校验订单状态确实是待支付，然后把状态改成已支付，记录支付时间，同时把订单里的商品销量累加到商品表。这个模拟流程已经把支付回调的核心逻辑完整走了一遍，答辩时你可以解释：真实场景是支付平台回调我们的异步接口，这里简化为同步调用。

订单编号的生成也有讲究。create_time精确到秒会冲突，直接自增id当订单号又太暴露业务量。我的生成方案是：yyyyMMddHHmmss + 3位随机数 + 用户id后4位，拼成一个32位以内的字符串。单机场景这个方案够用，不会重复。

5. 我给代码动手术：一轮自测抓出的真实问题

做完第一版功能，我以为万事大吉，结果自己测试了一遍，抓出一堆问题。这部分我按排查链路写，算是这篇文章里最值钱的一段。

5.1 排序字段的SQL注入风险与白名单校验

第一次测试商品排序时，我图省事，直接把前端传的sortValue拼进了查询条件，想着“就一个排序值，能有什么事”。后来自己拿了一个攻击字符串去测，往sortValue里传了1;drop table product，日志里SQL直接炸了。虽然MyBatis Plus是预编译防止了大部分注入，但我用了queryWrapper.last()拼了原生SQL片段，就绕过了预编译保护。

根因是：我没有对用户输入做校验，把不可信的字符串当成了SQL片段的一部分。修复方案就是我在4.2里写的那个SORT_MAP白名单：前端只能传sales_desc这种枚举值，后端把它映射成固定字段名和排序方向，其他任何值一律走默认排序。这样哪怕有人传恶意字符串，也到不了SQL语句里。

这是很好的答辩素材。评审问“你的项目有考虑安全性吗”，我直接说“商品排序参数我做了白名单校验，防止SQL注入”，比说一百句“我注意了安全”都管用。

5.2 库存超卖问题的排查链路

做并发测试的时候，我用开源的压测工具模拟了100个用户同时抢购一件库存只有10的商品，结果发现订单都创建成功了，库存变成了负数。我当时的第一反应是：事务没生效？还是SQL写错了？

排查链路是这样的：

第一步，看数据库最终状态。库存值为负，说明有多个请求同时通过了“库存>0”的判断。

第二步，看代码执行顺序。我当时的下单逻辑是：先查库存 -> 判断是否充足 -> 执行更新库存 -> 插入订单。问题就出现在“查库存”和“更新库存”之间有一个时间差，并发请求会在这个时间差里读到同一个旧值。

第三步，看更新SQL。我原来的SQL是UPDATE product SET stock = #{newStock} WHERE id = #{id}，这个写法在并发场景下会发生更新覆盖，A请求算出的newStock=9，B请求也算出newStock=9，后执行的反而把先执行的覆盖了。

修复方案就是我前面写的原子更新：UPDATE product SET stock = stock - 1 WHERE id = ? AND stock > 0。把“判断”和“更新”合并成一条SQL交给数据库处理，利用数据库的行锁保证同一时刻只有一条更新能成功。改完再压测，库存数量始终正确，并发下单不再出现超卖。

5.3 Redis和Session混用的坑

我在项目里用Redis做了两件事：缓存验证码、缓存购物车商品数量。登录状态还是用Session存。有次测试发现一个诡异现象：用户明明已经登录了，进入个人中心却发现Session里取不到用户信息，被拦截器拦下来重定向到了登录页。

排查了半天，问题出在拦截器配置上。我的WebMvcConfigurer里把路径/user/**全部拦截了，其中包含了登录接口，导致用户在登录页面提交登录请求后，还没执行“把用户放进Session”的操作，拦截器就先拦截了这个请求，Session里自然取不到用户。

这个问题的价值在于：设计拦截路径时，一定要把公开接口放进放行名单里。我最终的拦截配置是这样的：放行/user/login、/user/register、/product/**、/category/**、/静态资源，拦截/cart/**、/order/**、/user/info/**这些真正需要登录的操作。写完这个，Session和Redis各管各的，再也没有混用过。

5.4 乱码与日期格式的细节处理

中文乱码是Java Web的老毛病。解决方法分三层：数据库连接串里加characterEncoding=utf8，模板引擎或Servlet层统一UTF-8编码，页面文件本身保存成UTF-8格式。Spring Boot里还可以用强制编码过滤器兜底：

yaml复制server:
  servlet:
    encoding:
      enabled: true
      force: true

日期格式的问题更隐蔽。默认情况下LocalDateTime序列化到前端会带个字母T，比如2024-01-01T10:30:00，页面显示很难看。解决方案是统一配置时间格式：

java复制@Configuration
public class JacksonConfig {
    @Bean
    public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() {
        return builder -> {
            builder.serializerByType(LocalDateTime.class, new LocalDateTimeSerializer(
                    DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
            builder.deserializerByType(LocalDateTime.class, new LocalDateTimeDeserializer(
                    DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")));
        };
    }
}

配置完之后，所有接口返回的日期都变成了2024-01-01 10:30:00这种可读格式，同一类问题在一个地方解决，不需要在逐个接口上打注解。

6. 打包部署与项目上线：从本地跑到服务器

6.1 Maven多环境打包配置

本地跑通和服务器跑通是两回事，最大的坑就是配置环境不同。我一开始把所有配置都写在application.yml里，本地连接的是localhost:3306的数据库，直接把jar包扔到服务器上，启动就报连不上数据库，因为服务器上根本没有那个库。

后来我拆成了三个文件：application.yml放通用配置，application-dev.yml放本地环境，application-prod.yml放服务器环境。然后在pom.xml里用profiles定义环境切换：

xml复制<profiles>
    <profile>
        <id>dev</id>
        <properties>
            <activatedProfile>dev</activatedProfile>
        </properties>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
    </profile>
    <profile>
        <id>prod</id>
        <properties>
            <activatedProfile>prod</activatedProfile>
        </properties>
    </profile>
</profiles>

打包的时候执行mvn clean package -Pprod，构建出的包就会自动加载application-prod.yml。这个方案最大的好处是：你本地怎么折腾都不会影响线上配置，而且代理密码、数据库账号不会被误打包进测试包，算是一点安全意识。

6.2 将Java项目打成可部署Jar包并运行

Spring Boot项目天生就是为“一个jar包部署”设计的。在pom.xml里加上spring-boot-maven-plugin，执行打包命令：

bash复制mvn clean package -DskipTests

执行完，target目录下会生成一个可执行的jar包，比如phone-shop-0.0.1-SNAPSHOT.jar。这里有个坑需要注意：有的同学直接把打出来的jar双击运行或者用java -jar运行，发现端口被占用、配置不对，各种问题。我部署到云服务器的标准操作是这样：

bash复制# 上传jar包到服务器，然后启动
nohup java -jar phone-shop-0.0.1-SNAPSHOT.jar --server.port=8080 > app.log 2>&1 &

nohup的作用是让程序退出终端后继续运行，> app.log 2>&1把日志重定向到文件，最后的&表示后台运行。启动之后用tail -f app.log实时盯日志，看到Started Application in x.x seconds就说明启动成功了。停止服务的命令是：

bash复制ps -ef | grep phone-shop
kill -9 进程id

云服务器上还要放行端口。除了服务器本身的防火墙要开放8080端口，云厂商的安全组也要在控制台里配置入站规则。这个细节容易漏，漏了的话本地永远访问不了服务器上的网站。

6.3 数据库初始化与首次启动的验证清单

服务器上数据库初始化是上线前最容易出问题的一步。我的做法是：先把本地开发好的建表SQL整理成init.sql，在服务器MySQL里执行，然后检查表的数量、字段结构、初始数据（比如管理员账号、初始分类和品牌）是否齐全。

首次启动后的验证，我列了一个清单，逐个过：

这个清单每项都过一遍，项目才算真正可以拿去演示和交差。我之前见过有同学把项目做完就扔在本地，答辩前一晚才想到部署，结果现场演示的时候连不上数据库，尴尬到脚趾抠地。部署验证这事一定要提前做，最好留出一到两天专门处理服务器环境问题。

7. 论文与技术答辩的准备思路

7.1 论文结构怎么搭最容易过审

很多同学毕设代码写得不错，论文却写成一笔流水账，最后被导师打回大改。结合我自己和身边同学的经验，Java毕设的标准结构这样搭最稳妥：选题背景与意义、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望。

选题背景不要写太空，把“手机销售网站解决什么问题、为什么用Java技术栈”说清楚就行。相关技术介绍部分，Spring Boot、MyBatis Plus、MySQL、Thymeleaf各写一小节，注意不要纯抄官网定义，最好结合你的项目说明“在这个项目里我用它做了什么”，比如“MyBatis Plus的LambdaQueryWrapper帮我实现了商品的多条件筛选，比原生SQL减少了约一半的代码量”。

系统设计部分是重头戏，数据库设计要给出ER图和每张表的字段说明，功能模块设计要画出体系结构图。这里有个经验：评审老师最喜欢翻的章节就是数据库设计和系统实现。数据库表怎么设计的，实体字段合不合理，外键有没有必要的索引，这部分扎实了论文就稳了一半。

系统实现部分不要只堆代码，要“截图+讲解+关键代码”三件套。每个核心功能页面的截图写上，下面对应代码逻辑的讲解，再用一个代码块展示最关键的一段实现。比如并发扣库存那段，就把乐观锁SQL单独展示，配一段“为什么这么写”的解释。测试部分列出功能测试用例表，再简单写一个并发测试的结论就够了。

7.2 答辩时如何把“亮点”讲成故事

答辩不是复述论文，而是把你认为最有技术含量的几个点讲成小故事。我当时挑了三个亮点，每个都按“遇到了什么问题 -> 怎么排查 -> 最终怎么解决”三段来讲。

第一个亮点是并发扣库存。讲法是：一开始我写的是“先查库存再更新”，结果压测发现超卖，追查原因是查询和更新之间存在时间差，最后用一条UPDATE ... WHERE stock > 0的原子SQL解决。这个故事里包含了并发意识、排查方法和优化手段，比干巴巴说“我用了乐观锁”有说服力得多。

第二个亮点是SQL注入防护。讲法是：我发现排序参数直接拼进SQL有风险，于是设计了白名单映射加枚举校验，让用户输入永远进不了SQL片段。这个例子虽然简单，但体现的是安全设计思维。

第三个亮点是订单状态机。讲法是：我用枚举封装了订单状态流转，把状态的合法跳转放在业务方法里统一校验，避免了魔法数字满天飞和非法状态流转。这个故事直接落在面向对象思想这个基础考点上，一举两得。

7.3 高频追问与应对话术

答辩前一定要把下面这些高频问题在脑子里过一遍，不是为了背八股，而是确保你真的能结合自己的代码回答。

第一个高频问题：“为什么选Spring Boot + MyBatis Plus？”不要只答“方便”，要说出它和原生Spring、原生MyBatis的对比：Spring Boot解决了配置繁琐和部署复杂的问题，MyBatis Plus在单表CRUD场景下能省掉大量重复的SQL编写，同时保留了自定义SQL的灵活性。

第二个高频问题：“数据库符合第几范式？”你要能说出订单表、用户表这些表字段的粒度没有冗余，订单项表中的冗余字段是为了做快照，属于有意识的反规范化设计。能回答到这个程度，说明你不是背的，是真的理解。

第三个高频问题：“两个用户同时买一个商品怎么办？”这就是你展示并发库存方案的最佳时机，直接说原子更新SQL，再说返回受影响行数判断成功与否。

第四个高频问题：“Session和Cookie有什么区别？”结合项目答就行：Session存在服务端，Cookie存在客户端，我把登录信息存在Session里，购物车数量存过Redis，而Cookie我只用来存过上次浏览的分类ID。

第五个高频问题：“项目里哪些地方用到了面向对象思想？”答：订单状态我用枚举封装、把公共CRUD让MyBatis Plus的BaseMapper统一处理、把返回前端的通用结果封装成了Result对象，这些都是面向对象封装、继承、多态思想的体现。

最后说点个人体会。毕设这个东西，项目本身并不是终点，写完代码、交完论文，你会发现自己对Java这门语言的理解跟做之前完全不一样。我到现在还记得第一次把自己的项目部署到云服务器上，然后在手机浏览器里访问到那个手机销售网站首页时的感觉——它可能不像商业网站那样精致，但它是我一行一行写出来的。如果你们打算做类似的题目，我的建议就一句：先把核心链路（商品 -> 购物车 -> 订单）跑通，再去完善权限、统计、缓存这些加分项。核心链路通了，这个毕设就稳了。祝你们顺利。