SpringBoot茶叶电商与文化传播平台：从需求到部署的保姆级实战教程

1. 项目定位与需求梳理

1.1 这个项目到底在解决什么问题

茶叶是中国最传统的消费品之一，但线下茶企普遍面临两个痛点：一是销售渠道单一，好茶卖不出去；二是品牌文化讲不清楚，消费者面对几十种茶叶根本不知道怎么选。一个基于SpringBoot的茶叶电商与文化传播平台，说白了就是用一套系统同时解决"卖茶"和"讲茶"两件事。

从毕设的角度看，这个题目的聪明之处在于它覆盖了Web开发的核心知识面：前端展示、后端接口、数据库设计、权限控制、订单流程，全都有。技术的难度梯度也合理——既有CRUD的基础操作，也有文化资讯的内容管理，如果愿意深入研究，还可以加上推荐算法、文件存储甚至支付对接，作为扩展点。

它的核心用户场景有三类：

• 普通消费者：浏览茶叶商品、查看茶文化文章、下订单购买
• 茶企/商家：管理商品信息、处理订单、发布文化内容
• 平台管理员：审核内容、管理用户、统计数据

这三类角色决定了系统的权限模型不能简单粗暴，至少需要用户端和管理端两套界面，后端的角色控制也要做到接口级别的区分。

1.2 为什么选Java技术栈而不是别的

市面上的电商系统方案很多，Python的Django、Node.js的Express、PHP的Laravel都能做。但这套选题用Java + SpringBoot，放在毕设场景下有几个实打实的优势：

第一，SpringBoot是目前Java Web开发的事实标准。它对Spring和SpringMVC做了大量的自动化配置，一个spring-boot-starter-web依赖就能拉起完整的Web服务，不需要像早期SSH框架那样写一堆XML。对于学生来说，学到的不是过时的技能，毕业找工作面试时也是有直接价值的。

第二，生态成熟，组件丰富。做权限有Spring Security、Sa-Token，做持久层有MyBatis-Plus，做缓存有Redis Starter，做文档有Knife4j/Swagger——几乎你能想到的功能，都有开箱即用的依赖。

第三，自动配置机制让开发效率极高。比如配置数据源，只需要在application.yml里写几行URL、用户名、密码，SpringBoot会自动创建DataSource和SqlSessionFactory。这种"约定优于配置"的设计，对毕设这种需要快速出成果的场景非常友好。

第四，部署和运行成本低。SpringBoot内置Tomcat，最终打包成一个可执行的JAR文件，不用单独装Web容器。这一点在毕设答辩演示的时候非常关键——一台装了JDK的Windows电脑就能跑起来，不用折腾环境。

1.3 场景拆解：目标用户与技术侧重点

做项目之前先想清楚"为谁做"这个问题，比急着写代码重要得多。

从用户端来看，这套系统的核心任务有三个维度的体验要求：

• 逛：茶叶商品要有清晰的信息结构，品类分类、产地、等级、价格范围都能筛选
• 读：文化传播部分要有文章列表、详情展示、推荐阅读，内容质量比界面华丽更重要
• 买：购物车、订单结算、收货地址管理，流程要顺畅，状态要清晰

从管理端来看，核心诉求是：

• 商品上下架、库存管理
• 订单处理（发货、取消、退款）
• 文化文章发布与审核
• 用户管理（封禁、解封、角色分配）

技术的侧重点对应起来就是：MySQL表结构设计要合理，用户与订单的关联要清晰；SpringBoot的Controller层要做好参数校验和统一返回；MyBatis-Plus的CRUD封装要会用；前端Vue的组件化页面要能和后端接口联调通过。

一个比较合适的整体架构是典型的单体分层架构：前端Vue + Axios → Controller → Service → Mapper → MySQL，中间穿插Redis做登录态缓存和热门文章统计。这种架构清晰、好讲、好维护，答辩时也容易展示调用链路。

2. 技术选型详解与架构设计

2.1 核心技术栈清单及选型理由

如果从头开始搭建这个项目，我建议的技术栈清单如下，每一项的选择都有具体原因：

这个组合里最值得说明的是MyBatis-Plus和Sa-Token的选择。

MyBatis-Plus最大的价值在于它把单表操作从"写一堆XML"解放出来。BaseMapper接口自带selectById、selectList、insert、updateById、deleteById，配合QueryWrapper或LambdaQueryWrapper做条件查询，基本能覆盖项目中80%的数据库操作。复杂的手写SQL只需要保留在多表关联查询（比如订单详情关联商品）的场景。

Sa-Token对比Spring Security，核心优势是"简单"。登录之后前端拿到Token，之后每次请求放到请求头satoken字段里，Sa-Token通过拦截器自动鉴权，注解@SaCheckLogin、@SaCheckRole("admin")就能控制接口访问权限。这一套在毕设中完全够用，代码量比Spring Security的SecurityFilterChain配置少一半以上。

2.2 整体架构：前后端分离与单体部署

这个项目我强烈建议采用前后端分离架构，但部署时合并为一个项目处理。

开发阶段，前端Vue项目独立运行在开发服务器上（默认端口8081），后端SpringBoot运行在8080端口，通过Vite代理转发解决跨域问题。前后端分离的好处是职责清晰、开发效率高，Vue的组件化开发对于商品列表、购物车这种高度交互的页面太合适了。

部署阶段，执行npm run build打包Vue项目，生成dist目录下的静态文件，然后有两种常见处理方式：

• 方式一：把dist目录直接复制到SpringBoot的src/main/resources/static下，重新打成JAR包。这样访问后端端口就能同时访问前端页面，规避了跨域问题，部署也简单。
• 方式二：前端和后端分别部署，用Nginx做反向代理，/api前缀的请求转发给后端，其他请求指向前端静态文件。

毕设场景下我推荐方式一，一个JAR包搞定所有事情，答辩的时候不需要解释Nginx配置。

在代码层面，后端项目要按业务模块分包，这一点对答辩加分很有用。我的分包习惯是：

text复制com.example.tea
├── controller      // 控制层，接收请求、参数校验、返回结果
├── service         // 业务层，核心逻辑都在这里
├── dao/mapper      // 数据访问层，MyBatis-Plus接口
├── entity          // 实体类，对应数据库表
├── dto             // 数据传输对象，用于接收前端参数
├── vo             // 视图对象，用于返回给前端的数据结构
├── config         // 配置类，如Knife4j、拦截器、跨域配置
├── common         // 公共类，统一返回结果、异常处理、枚举
└── utils          // 工具类，如JWT工具、日期工具

分层之后，代码结构一目了然，答辩时能清楚说出每层职责。

2.3 数据库设计：11张核心表的建模思路

MySQL数据库设计是这套系统的基础，表与表之间的关联关系直接决定了业务流程的顺畅度。基于"用户-商品-订单-内容"四大核心，我设计了11张表：

• user：用户表，存储账号、密码（BCrypt加密）、昵称、手机号、头像
• role：角色表，管理员、商家、普通用户三种
• user_role：用户角色关联表（简化版可以直接在user表加role字段，但多对多更规范）
• category：茶叶分类表，如绿茶、红茶、普洱茶、白茶、黑茶、乌龙茶
• product：商品表，名称、简介、详情、价格、库存、主图、产地、等级
• orders：订单表，订单号、下单用户、总金额、状态（待付款/待发货/待收货/已完成/已取消）
• order_item：订单明细表，关联订单和商品，记录下单时的单价和数量
• address：收货地址表，多地址关联用户
• article：文化文章表，分类、标题、封面、正文、作者、浏览量
• article_category：文章分类表，如茶史茶道、冲泡技巧、茶器鉴赏、健康饮茶
• cart：购物车，关联用户和商品，冗余商品名和价格方便快速展示

以product表举例，核心字段设计可以参考这个SQL片段：

sql复制CREATE TABLE `product` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `name` varchar(100) NOT NULL COMMENT '商品名称',
  `category_id` bigint DEFAULT NULL COMMENT '分类ID',
  `origin` varchar(100) DEFAULT NULL COMMENT '产地',
  `grade` varchar(50) DEFAULT NULL COMMENT '等级',
  `price` decimal(10,2) NOT NULL COMMENT '售价',
  `stock` int NOT NULL DEFAULT 0 COMMENT '库存',
  `main_image` varchar(255) DEFAULT NULL COMMENT '主图URL',
  `detail` text COMMENT '商品详情',
  `sales` int DEFAULT 0 COMMENT '销量',
  `status` tinyint DEFAULT 1 COMMENT '状态 1上架 0下架',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='茶叶商品表';

注意，价格和金额相关的字段一定要用DECIMAL类型，不要用double或者float，否则浮点数精度问题会在订单金额计算时闹出大麻烦。库存字段设置INT，在扣减库存时用UPDATE product SET stock = stock - #{n} WHERE id = #{id} AND stock >= #{n}这种写法，防止超卖。

另外所有表都加上create_time和update_time，一是排错方便，二是答辩时可以展示用户注册趋势、订单增长趋势，为数据可视化加分。

3. 核心功能模块设计与实现

3.1 用户模块：注册登录与权限控制

用户模块是所有功能的基础。登录方式我采用账号密码登录 + Token鉴权。密码用BCryptPasswordEncoder加密存储，BCrypt每次生成的哈希值都不同，即使数据库泄露，彩虹表也破解不了。

核心登录逻辑伪代码：

java复制public LoginVO login(LoginDTO dto) {
    // 1. 根据用户名查询用户
    User user = userMapper.selectOne(
        new LambdaQueryWrapper<User>()
            .eq(User::getUsername, dto.getUsername())
    );
    // 2. 用户不存在直接抛异常
    if (user == null) {
        throw new BusinessException("用户名或密码错误");
    }
    // 3. BCrypt校验密码
    if (!bcrypt.matches(dto.getPassword(), user.getPassword())) {
        throw new BusinessException("用户名或密码错误");
    }
    // 4. Sa-Token登录，生成Token
    StpUtil.login(user.getId());
    // 5. 返回Token和用户信息
    LoginVO vo = new LoginVO();
    vo.setToken(StpUtil.getTokenValue());
    vo.setUserInfo(user);
    return vo;
}

这里要注意一个体验细节：登录失败时返回的信息，必须是"用户名或密码错误"这种笼统消息，不能直接告诉用户"用户名不存在"，否则攻击者可以通过接口枚举出系统中存在的账号。

权限控制方面，用一个自定义拦截器或Sa-Token的SaInterceptor拦截所有/api/**请求，然后通过注解在需要登录或者需要管理员权限的接口上做控制：

java复制// 需要登录才能访问
@SaCheckLogin
@GetMapping("/cart/list")
public Result<List<CartVO>> getCartList() { ... }

// 需要管理员权限
@SaCheckRole("admin")
@PostMapping("/admin/product")
public Result<String> addProduct(@RequestBody Product product) { ... }

热点问题延伸：很多人答辩时会被问到"拦截器和过滤器有什么区别"。简单回答：过滤器（Filter）是Servlet层面的，在请求进入Controller之前和响应返回之后起作用；拦截器（Interceptor）是SpringMVC层面的，可以拿到Controller方法和Handler对象，能做更细粒度的控制。Sa-Token的鉴权主要基于拦截器。

3.2 商品模块：分类浏览与高级搜索

商品模块是电商的平台，核心功能是分类浏览、列表查询和详情展示。列表页最常见的需求是"筛选+排序+分页"，MyBatis-Plus的Page对象配合LambdaQueryWrapper实现起来非常优雅：

java复制public Page<ProductVO> getProductPage(ProductQueryDTO dto) {
    // 构建分页参数
    Page<Product> page = new Page<>(dto.getPageNum(), dto.getPageSize());
    // 构建查询条件
    LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>();
    // 分类筛选
    if (dto.getCategoryId() != null) {
        wrapper.eq(Product::getCategoryId, dto.getCategoryId());
    }
    // 价格范围筛选
    if (dto.getMinPrice() != null) {
        wrapper.ge(Product::getPrice, dto.getMinPrice());
    }
    if (dto.getMaxPrice() != null) {
        wrapper.le(Product::getPrice, dto.getMaxPrice());
    }
    // 搜索关键词模糊匹配
    if (dto.getKeyword() != null && !dto.getKeyword().isEmpty()) {
        wrapper.like(Product::getName, dto.getKeyword());
    }
    // 排序
    if (dto.getSort() != null) {
        if ("sales".equals(dto.getSort())) {
            wrapper.orderByDesc(Product::getSales);
        } else if ("price_asc".equals(dto.getSort())) {
            wrapper.orderByAsc(Product::getPrice);
        }
    }
    // 2. 只查询上架状态的商品
    wrapper.eq(Product::getStatus, 1);
    Page<Product> result = productMapper.selectPage(page, wrapper);
    // 3. 转换Vo并返回
    ...
}

商品详情页要展示的信息比较多：主图、名称、价格、库存、销量、产地、等级、详细图文介绍。为了减少前端联调时字段对不上的问题，建议定义一个ProductVO，把实体类和前端需要展示的字段一一对应。比如实体类是Product，ProductVO里多一个categoryName用来展示分类名称。

卖的最好的商品放在最前面算是电商的基础运营策略，销量排序字段sales需要在前台下单成功后实时加一。注意这里我用的是"销量累加"而不是"从订单表count"，虽然实时性差一点，但性能好，不需要订单表每次归总。

3.3 购物车与订单流程：状态机的设计

购物车模块相对简单，核心就是增删改查，关联用户ID、商品ID、数量。但订单模块是整个系统的核心，业务流程复杂，涉及库存扣减、金额计算、状态流转。

我建议用"状态机"的思想来设计订单状态，每个状态定义清楚它允许流转到哪些状态：

下单的核心流程大概是这样的：

1. 从购物车勾选的商品中创建订单主表和明细表
2. 计算总金额（这里注意：金额计算不要在前端算完传后端，要以后端数据库的价格为准，防止前端篡改价格）
3. 检查库存并扣减
4. 清空已选购的购物车记录
5. 返回订单号

java复制@Transactional
public String createOrder(OrderCreateDTO dto) {
    // 1. 生成订单号，格式：时间戳 + 随机数
    String orderNo = "T" + System.currentTimeMillis() + 
                     RandomUtil.randomNumbers(6);
    // 2. 查询用户地址
    Address address = addressMapper.selectById(dto.getAddressId());
    // 3. 计算订单金额
    BigDecimal totalAmount = BigDecimal.ZERO;
    List<OrderItem> items = new ArrayList<>();
    for (CartItemVO cartItem : dto.getItems()) {
        Product product = productMapper.selectById(cartItem.getProductId());
        // 4. 扣库存，防止超卖
        int rows = productMapper.deductStock(product.getId(), cartItem.getQuantity());
        if (rows == 0) {
            throw new BusinessException("商品" + product.getName() + "库存不足");
        }
        // 5. 构建订单明细
        OrderItem item = new OrderItem();
        item.setProductId(product.getId());
        item.setProductName(product.getName());
        item.setPrice(product.getPrice());
        item.setQuantity(cartItem.getQuantity());
        item.setSubTotal(product.getPrice()
             .multiply(BigDecimal.valueOf(cartItem.getQuantity())));
        items.add(item);
        totalAmount = totalAmount.add(item.getSubTotal());
    }
    // 6. 保存订单
    ...
}

看到没有，整个下单逻辑最危险的地方就是库存扣减。先检查库存再扣减是不安全的，两个用户同时下单各自检查到库存还剩1件，然后都去扣，就超卖了。所以扣库存的SQL必须写成stock = stock - n WHERE id = ? AND stock >= n，把检查和扣减合并成一个原子操作。

@Transactional注解是保证订单和明细一起写入的关键，任何一个环节出错都全部回滚。网上有很多文章吐槽事务失效的坑，比如类内部调用（A方法调B方法，@Transactional写在B上不生效）、非public方法、异常被catch吞掉导致不触发回滚——毕设答辩的时候如果能主动说出"事务在什么情况下会失效"这个话题，是非常加分的。

3.4 茶文化传播模块：文章的发布与展示

这个模块是选题的"灵魂"，也是区别于普通电商系统的差异化亮点。设计上要兼顾两个视角：

从用户视角，文化板块提供的是分类阅读体验。文章按"茶史文化、冲泡品鉴、茶器茶具、养生茶饮"等分类组织，支持列表分页、关键词搜索、浏览量统计。文章详情排版要支持富文本内容，前端用v-html渲染（注意XSS防护）。

从管理视角，后台要支持富文本编辑器发布文章、封面图上传、分类管理、置顶和推荐位设置。

这里有一个实现上的细节：富文本上传图片，是把Base64图片直接存到数据库，还是上传到服务器生成URL再插入内容？对于毕设项目，图片切图后转成BASE64存数据库虽然简单，但数据库会迅速膨胀。更合理的做法是把图片上传到本地服务器的指定目录，返回访问URL。MVP方案甚至可以：在application.yml中配置file.upload-dir，用MultipartFile.transferTo()保存，由SpringBoot的静态资源映射对外开放这个目录。

比较大的工作量在文章详情页的"相关推荐"。最简单的方案是：同一分类下随机取4篇，排除当前文章：

java复制public List<Article> getRelatedArticles(Long articleId, Long categoryId, int limit) {
    LambdaQueryWrapper<Article> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(Article::getCategoryId, categoryId)
           .ne(Article::getId, articleId)
           .orderByAsc(RANDOM())
           .last("LIMIT " + limit);
    return articleMapper.selectList(wrapper);
}

3.5 后台管理模块：数据可视化与内容审核

后台管理是电商系统的"驾驶舱"。核心页面包括：

• 数据概览仪表盘：展示今日订单数、今日销售额、用户总数、商品总数
• 订单管理列表：支持按时间范围、状态、订单号筛选，可发货、可取消
• 商品管理：增删改查，上下架操作
• 用户管理：封禁/解封、重置密码
• 内容管理：文章发布、编辑、删除，分类管理
• 地址与评价管理（可选扩展）

数据概览仪表盘是很多毕设的加分项。可以从订单表和商品表聚合数据，返回给前端用ECharts绘制折线图、饼图：

java复制public DashboardVO getDashboardData() {
    DashboardVO vo = new DashboardVO();
    // 今日订单数和销售额
    vo.setTodayOrderCount(orderMapper.countToday());
    vo.setTodaySalesAmount(orderMapper.sumToday());
    // 近7日订单趋势
    List<OrderTrend> trend = orderMapper.getOrderTrendByDay(7);
    vo.setOrderTrend(trend);
    // 商品分类销量TOP5
    List<CategorySales> topCategories = orderItemMapper.getSalesByCategory(5);
    vo.setTopCategories(topCategories);
    return vo;
}

SQL部分需要注意MySQL的时间函数用法：

sql复制-- 今日订单数
SELECT COUNT(*) FROM orders 
WHERE pay_time >= CURDATE() AND pay_time < CURDATE() + INTERVAL 1 DAY;

-- 近7日每天订单数
SELECT DATE(pay_time) AS day, COUNT(*) AS count
FROM orders
WHERE pay_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
GROUP BY DATE(pay_time)
ORDER BY day;

4. 前端实现与前后端联调

4.1 Vue 3项目结构与路由划分

前端的核心工作是把用户端和管理端两套页面组织好。以Vue 3 + Vite初始化项目后，src目录下这样组织比较清晰：

客户端页面：

• 首页：轮播图、热卖商品推荐、最新文化文章
• 商品列表页：分类筛选、价格排序
• 商品详情页：商品信息、加入购物车、直接购买
• 购物车页：勾选结算、数量调整、删除
• 订单页面：订单列表按状态Tab切换、订单详情、确认收货
• 个人中心：资料修改、地址管理
• 文化文章列表页/文章详情页

管理端页面（可以用独立路由前缀/admin，也可以用单独的layout布局）：

• 仪表盘
• 商品管理
• 订单管理
• 用户管理
• 文章管理
• 分类管理

路由用Vue Router，并配合登录守卫：

javascript复制// 路由守卫：未登录跳转到登录页
router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token');
  if (to.meta.requiresAuth && !token) {
    next('/login');
  } else {
    next();
  }
});

小提示：前后端联调时最大的坑是跨域。开发阶段Vite配置server.proxy把/api代理到后端8080端口；如果部署阶段前端静态文件放进了SpringBoot的static目录，就压根不存在跨域问题。如果两者分开了，后端还需要配置CORS。最简单的CORS配置：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

4.2 Axios封装与拦截器

前端调用后端接口要统一封装Axios实例，在请求拦截器中带上登录Token，在响应拦截器中处理统一返回结果：

javascript复制// api/request.js
import axios from 'axios';
import { ElMessage } from 'element-plus';
import router from '@/router';

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
});

// 请求拦截器：带Token
request.interceptors.request.use(config => {
  const token = localStorage.getItem('token');
  if (token) {
    config.headers['satoken'] = token;
  }
  return config;
});

// 响应拦截器：统一处理错误
request.interceptors.response.use(
  response => {
    const res = response.data;
    if (res.code !== 200) {
      ElMessage.error(res.msg || '请求失败');
      // 登录过期，清除本地登录态并跳转登录页
      if (res.code === 401) {
        localStorage.removeItem('token');
        router.push('/login');
      }
      return Promise.reject(new Error(res.msg));
    }
    return res;
  },
  error => {
    ElMessage.error(error.message);
    return Promise.reject(error);
  }
);

这里要求后端必须返回统一结构的数据格式：

json复制{
  "code": 200,
  "msg": "success",
  "data": { ... }
}

后端可以用Result类封装，并配合全局异常处理器统一转换。所以代码的自查顺序是：后端Controller直接返回Result对象，发生异常时由@RestControllerAdvice兜底。

4.3 Vue打包部署进SpringBoot的全流程

把Vue打包放进SpringBoot是毕设部署的最后一公里，很多同学在这里栽跟头。完整流程这样走：

1. 在vue.config.js或Vite配置中设置base: './'（相对路径），这样打包后引用的静态资源用相对路径，方便放进SpringBoot里。
2. 执行npm run build，生成dist目录。
3. 将dist目录下的所有文件复制到SpringBoot项目的src/main/resources/static目录下。
4. Maven重新打包mvn clean package -DskipTests，生成可执行JAR。
5. java -jar target/tea-0.0.1-SNAPSHOT.jar启动，浏览器访问http://localhost:8080即可看到前端页面。

这里有个经典问题：前端路由刷新404。因为前端是单页应用，路由跳转是前端的history模式，但刷新页面时浏览器直接向后端发请求。SpringBoot默认找不到/product/123这样的Controller路由，就会返回404。解决方案是配置一个路由转发规则，把非/api的请求都转发到index.html：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/{path:[^\\.]*}")
                .setViewName("forward:/index.html");
    }
}

4.4 前后端接口参数校验规范

联调阶段最大的痛点是前端传的参数后端不校验，非法数据插入数据库，查得深了才暴露各种怪bug。

建议用Spring的@Validated注解，在DTO上定义校验规则：

java复制public class LoginDTO {
    @NotBlank(message = "用户名不能为空")
    private String username;

    @NotBlank(message = "密码不能为空")
    @Size(min = 6, max = 18, message = "密码长度为6-18位")
    private String password;
}

Controller方法参数上加@Validated，校验不通过时会自动抛出MethodArgumentNotValidException，由全局异常处理器统一返回给前端。

同时，后端接收前端传的ID等数字参数时，一定要加@Min或者null判断，否则容易出现"空指针"或者"负数ID查询"这类低级错误。这个在答辩现场演示的时候特别难看。

5. 部署与运维实战

5.1 JAR包一键部署：从本机到服务器

前后端合并后的单体JAR包是我最推荐毕设场景的部署方式。本机开发阶段用IDE跑SpringBoot + npm run dev跑前端；演示阶段用打包后的一体化JAR。

服务器部署（如果答辩需要线上演示）基本命令：

bash复制# 上传JAR包
scp target/tea-*.jar root@服务器IP:/opt/tea/

# 启动应用
cd /opt/tea
nohup java -jar tea-0.0.1-SNAPSHOT.jar \
  --spring.profiles.active=prod \
  > app.log 2>&1 &

# 查看日志
tail -f app.log

生产环境配置文件用application-prod.yml，数据库连接从本地换成远程MySQL，Redis也换成云服务。这样本机用的是application-dev.yml，互不影响。

5.2 常遇部署问题排查记录

结合我带过的学生实际踩坑情况，部署阶段高频出现的问题汇总如下：

有一个特别隐蔽但常常遇到的问题：本地MySQL的data目录权限导致无法写入。用systemctl start mysql启动MySQL失败时，先检查/var/lib/mysql的属主，如果是root权限，运行chown -R mysql:mysql /var/lib/mysql解决。

5.3 Redis缓存的使用：提升性能与展示技术深度

在答辩时提到Redis缓存是很好的技术亮点。最简单的应用场景有两处：

一是分类信息的缓存。当分类基本不变时，每次查询都打数据库不划算。可以在CategoryService里加缓存：

java复制public List<Category> getCategoryList() {
    // 先查缓存
    List<Category> list = (List<Category>) redisTemplate.opsForValue()
            .get("category:all");
    if (list != null) {
        return list;
    }
    // 缓存没有再去查库
    list = categoryMapper.selectList(null);
    // 设置过期时间为1小时，到期自动刷新
    redisTemplate.opsForValue().set("category:all", list, 1, TimeUnit.HOURS);
    return list;
}

二是商品浏览量计数。文章或商品的浏览量是高频写入，但允许最终一致性。方案是用户访问时只加在Redis的Hash结构里，每隔5分钟或者定时任务把Redis中的浏览数同步回数据库。

6. 毕设答辩要点与避坑指南

6.1 答辩时怎么讲清楚这个系统

很多同学代码写完了，答辩一紧张就讲得混乱。这里给一个非常实用的讲解思路：

• 三句话定位项目：第一句说项目背景（茶产业数字化），第二句说系统功能（电商+文化传播），第三句说技术栈（SpringBoot+Vue+MySQL）。
• 按业务链路讲：用户注册登录→浏览商品/文章→购物车→下单→管理员处理订单→数据统计。这条链路把系统核心功能串起来，逻辑清晰且层层递进。
• 主动展示技术难点：讲到下单时顺带提"这里我们用了PRODUCT表的库存原子操作解决超卖问题"，讲到权限时提"基于Sa-Token的RBAC方案"。
• 现场演示的demo准备：提前准备好测试数据（几个分类、10个商品、5篇文章、一个真实订单），演示时不要现场边输入边等数据，效率太低。

记住，答辩老师的核心疑问一般是："这个系统是你自己写的吗？""遇到的最大困难是什么？""你的系统比别人的系统好在哪里？"。所以准备时要能答出两三个自己真实做过的技术点，比如"解决了前端刷新404问题""设计了防止超卖的库存扣减""用Redis做了热门文章排行"。

6.2 常见八股式面试问法对应的回答脚本

Java后端方向的技术面试帖里，这个项目是常见的被问到项目之一。跟你项目强相关的高频问题建议提前准备：

SpringBoot自动配置原理

"你是也用了SpringBoot，它的自动配置原理你了解吗？"——这个在热搜词里出现频率极高。回答思路：启动类上的@SpringBootApplication注解包含@EnableAutoConfiguration，通过AutoConfigurationImportSelector读取META-INF/spring/spring.factories文件中配置的AutoConfiguration类，再由@ConditionalOnClass、@ConditionalOnMissingBean等条件注解判断是否生效。

为什么选择MyBatis-Plus而不是原生MyBatis？

回答：MyBatis-Plus解决了原生MyBatis在单表操作上需要手写大量重复SQL的问题，提供内置的BaseMapper封装，同时保留手写SQL的灵活性，分页插件也很成熟。

数据库如何设计来保证数据一致性？

回答：利用MySQL的InnoDB事务和行锁，下单时使用UPDATE stock WHERE stock >= n原子扣减，配合@Transactional保证订单和明细写入的一致性，取消订单时恢复库存。

怎么实现分类商品的销量排行？

回答：订单支付成功后更新商品表的sales字段，排序时直接ORDER BY sales DESC；如果商品量大，可用定时任务聚合订单表到统计表。

6.3 给同学们的几点实际操作建议

基于我带过多个类似项目的经验，给准备复现这套系统的同学几段真话：

第一，新建项目时尽量选SpringBoot 2.7.x。网上大部分教程、开源代码都是基于这个版本写的，遇到问题搜索答案时命中率高。SpringBoot 3.x虽然新，但要求JDK 17+，部分旧依赖兼容性不好，对毕设来说是徒增烦恼。

第二，数据库表结构一定要先画好再写代码。很多同学上来就开写，写一半发现字段对不齐、缺少关联，返工非常痛苦。我习惯用Navicat或者PDMan先画ER图，表字段、类型、外键都标清楚，再同步到代码。

第三，不要做过度复杂的功能。推荐算法、消息队列、分布式锁这些是很好的加分项，但如果你的基础不牢，硬要实现反而会让项目失控。毕设的核心价值是"完整、正确、可演示"，功能贪多不是好事。

第四，单元测试要在核心流程上写几个。下单流程、库存扣减、权限拦截这三个点，哪怕是简单的Integeration Test，也能让答辩老师对你的工程质量刮目相看。

第五，git一定要从第一天就用起来。每天写一点提交一点，除了防手滑误删代码之外，答辩时还能展示commit记录来证明工作量。

7. 项目后续扩展方向

代码交付之后，如果时间充裕，这个题目还可以往几个方向深挖：

• 接入第三方支付（支付宝沙箱环境、微信支付Native），在本地完成扫码支付回调，电商闭环体验立刻提升一档
• 基于SpringBoot整合ElasticSearch做全文检索，茶文化文章搜索的准确度和性能都会有明显改善
• 增加推荐系统，比如基于用户浏览记录做"相似茶叶推荐"和"喜欢这篇文章的人也喜欢"
• 微信小程序端，用原生小程序或uni-app复用后端接口，实现移动端下单
• 引入Docker容器化部署，把前后端、MySQL、Redis都写成Docker Compose编排文件，几乎零成本获得运维级部署体验，这在面试时是区分度很高的亮点

这个项目的天花板不低，从最简单的单体CRUD到复杂的微服务架构都能逐步演进。如果真心想把这份毕设的价值最大化，建议把精力集中在"把核心链路做扎实"上，比堆砌一堆肤浅的功能更有说服力。

当年我做的第一个电商系统，笨拙地手写了全部CRUD，数据库表设计得一塌糊涂，前端用的还是JSP。回头看这个题目，现在的技术栈已经简化到一个不可思议的程度。技术上省下来的力气，反而能花在真正关键的地方——把茶文化这个主题的价值做出来，把业务流程跑通跑顺。这就是我强烈推荐大家直接参考SpringBoot方案来做这个题目的原因，它给每个人的不是更少的挑战，而是更少毫无意义的重复劳动，让你把注意力留给真正有创造力的部分。