企业官网建设流程全解析

简介：这是一套面向计算机专业本科生的高分毕业设计级美妆电商系统，完整覆盖课程设计、期末大作业及毕设答辩需求，解决学生缺乏可运行全栈项目参考的痛点。资源包共839个文件，含133个Java后端核心代码、76个Vue前端页面、79个GIF动效与36个PNG图标等资源，涵盖前后端源码、MySQL 5.7+数据库脚本（.sql）、论文文档（.docx）、构建脚本（.bat）及样式资源（CSS/SCSS），整体24.72MB，结构清晰、模块分离明确。已有63人学习下载，项目经导师指导并通过验收，已预置run.bat一键启动、install.bat自动建库、build.bat打包部署，附带Element UI管理后台与响应式用户前台，支持用户中心、商品分类、购物车、订单支付与后台数据统计等全流程功能，开箱即用，无需调试即可演示运行。 每年这个时候，总能看到有人抱着“基于java+springboot+vue+mysql的xx购物网站”这类毕业设计在群里喊救命。其实这类项目套路非常固定，技术栈清晰、业务场景经典，但正因为太常见，反而容易做得平庸。今天用一个美妆购物网站项目当例子，把从技术选型、数据库设计、前后端实现到论文结构、答辩准备的完整链路拆开揉碎讲一遍。这篇内容适合正在做Java全栈毕设、想要快速搭建一个能跑能演示的电商项目、或者想系统理解Spring Boot+Vue配合方式的开发者。

先说结论：Spring Boot + Vue + MySQL这套组合做电商类毕设，最大的优势是每个环节都有成熟的生态支撑。前端用Vue全家桶处理页面交互和状态管理，后端用Spring Boot封装业务接口，MySQL存业务数据，三个层面职责清晰，不容易写出那种“所有逻辑堆在一个Servlet里”的灾难代码。美妆购物这个垂直场景又天然自带商品分类、库存规格、评价体系这些电商核心元素，比单纯做“图书管理系统”或“学生管理系统”能展示的能力维度更多，评分上天然占优势。

1. 项目整体设计与思路拆解

一个电商网站要做得好用、能讲、能演示，绝不是把增删改查页面拼一起就行。从设计角度，这个项目定位要清楚：它面向的是“购物”场景，所以核心链路是“浏览商品→加入购物车→下单结算→支付→查看订单”，周边功能是“用户注册登录→个人中心→后台管理”。整个项目要有两条主线，一条给普通消费者，一条给管理员，两类角色的入口和权限必须一开始就分清楚。

1.1 为什么选Spring Boot + Vue这个组合

很多人在技术选型上纠结是JSP还是前后端分离。我的建议很直接：毕设阶段只要你有条件，就选前后端分离。

原因有三个。第一，Spring Boot天然适合做RESTful API，你用@RestController就能把后端能力暴露成接口，前端不管用什么框架都能接，这比JSP那种服务端渲染的模式在分工上清晰太多了。第二，Vue的组件化和响应式特性特别适合电商这种交互密集的场景，购物车加减数量、商品筛选、表单校验这些功能用Vue写起来行云流水，用JSP写则要手动操作一堆DOM，工作量翻倍。第三，答辩时你可以分开演示“这是后端接口”“这是前端页面调用接口”，评委一看就知道你理解了现代Web开发的分层思想，这在评分标准里属于“设计合理”那一档。

MySQL在这个组合里是业务数据的地基。电商数据有几个特点：数据量会涨、关系复杂、需要事务保证一致性。MySQL在这三方面都稳，而且网上资料多，遇到问题搜一下就有答案，这对独立完成毕设的人来说非常友好。

1.2 美妆购物网站的领域特点与功能规划

美妆和3C、图书、服饰这些品类最大的不同在于：商品属性更细、消费者更关注详情和评价、品牌和分类维度很重要。口红要分色号，护肤品要分容量、适用肤质、保质期，这些细节如果不在商品模型里预留字段，后面扩展会非常痛苦。

所以功能规划不能只做最基础的“商品+购物车+订单”。要在普通电商基础上加一个“品牌”维度，商品详情页要展示多图、规格参数、用户评价。后台管理要支持商品上下架、库存调整、订单状态流转。支付环节用支付宝沙箱环境模拟真实支付，这样答辩的时候能演示“点击支付→跳转→回跳→订单状态变更”的闭环，比单纯把订单状态手动改掉有说服力得多。

整个项目按角色拆成两个端：

• 前台（用户端）：注册登录、商品浏览、商品搜索、商品详情、购物车管理、订单确认、支付模拟、订单查询、个人信息、收货地址管理、商品评价。
• 后台（管理端）：管理员登录、用户管理、商品管理（含图片上传）、分类管理、品牌管理、订单管理（发货/退款）、轮播图管理、数据统计。

数据统计这个模块容易被忽略但很出彩。用ECharts做几个图表展示每日订单量、商品销量排行、销售趋势，答辩时一分多钟就能讲完，但视觉冲击力很强，很多评委就吃这一套。

1.3 项目目录结构与分层设计

很多毕设项目的问题不是功能少，而是代码全堆在一个类里。Controller里面写业务、业务里面拼SQL，这种代码能跑但经不起问。标准做法是严格分层：Controller（接收请求、参数校验）→ Service（业务逻辑、事务管理）→ Mapper（数据持久化）。

后端包结构这样规划：

com.shop ├── common # 统一返回结果、异常处理、工具类 ├── config # 配置类（跨域、拦截器、文件上传等） ├── controller # 接口层 ├── entity # 实体类 ├── mapper # MyBatis-Plus的Mapper接口 ├── service # 业务接口与实现 ├── vo # 视图对象（向前端返回的封装对象） └── ShopApplication.java

前端目录结构：

src ├── api # 按模块封装的axios请求 ├── assets # 静态资源 ├── components # 通用组件（轮播图、商品卡片、分页等） ├── router # 路由配置 ├── store # Vuex状态管理 ├── views # 页面组件（首页、商品列表、购物车、订单、后台） └── utils # 工具函数（请求封装、token存取）

这种结构的好处是答辩的时候你可以直接对着目录讲：“每个页面通过API模块调用后端接口，API模块统一管理请求地址和Token携带，后端按Controller-Service-Mapper分层处理”，逻辑链条一句话说清，专业感直接拉满。

2. 核心功能模块与数据库表设计

数据库设计决定了这个项目能走多远。很多人的表设计是“够用就行”，结果做到订单环节发现缺字段、加一个功能要改三张表，越做越痛苦。电商项目有几个核心表和它们的字段设计，我直接给出经过验证的版本。

2.1 核心数据表清单与字段说明

用户表（user）：

• id（主键）、username（用户名）、password（密码，MD5或BCrypt加密）、nickname（昵称）、avatar（头像URL）、phone（手机号）、email（邮箱）、status（状态：0禁用/1正常）、create_time（注册时间）

商品表（product）：

• id、name（商品名称）、subtitle（副标题/卖点）、category_id（分类ID）、brand_id（品牌ID）、main_image（主图）、detail_images（详情图，JSON数组或逗号分隔）、price（价格，用Decimal）、stock（库存）、sales（销量）、status（上下架状态）、detail（富文本详情）、create_time

商品分类表（category）：

• id、name、parent_id（父分类ID，支持两级分类）、sort（排序）、icon（分类图标）

品牌表（brand）：

• id、name、logo、description

购物车表（cart）：

• id、user_id、product_id、quantity（数量）、checked（是否选中）、create_time

订单表（orders）：

• id、order_no（订单号，唯一）、user_id、total_price（总价）、status（订单状态：0待付款/1待发货/2待收货/3已完成/4已取消）、receiver_name（收货人）、receiver_phone、receiver_address、pay_time、ship_time、create_time

订单明细表（order_item）：

• id、order_id、product_id、product_name（快照商品名）、product_image、price（下单时价格）、quantity

收货地址表（address）：

• id、user_id、receiver_name、receiver_phone、province、city、district、detail_address、is_default

评价表（comment）：

• id、user_id、product_id、order_id、content、rating（评分1-5）、image（晒图URL）、create_time

轮播图表（banner）：

• id、image、link_url、sort、status

有一个非常重要的设计原则：订单明细里一定要存商品名称、图片、价格的快照，而不是通过product_id去关联查询。原因是商品价格和名称会变，但用户下单那一刻的信息必须永远固定。这个细节在论文里写出来，评委就知道你理解“历史数据不可变”这个电商常识。

2.2 关键字段为什么不这样设计

价格字段必须用DECIMAL而不是FLOAT或DOUBLE。Float和Double在计算机里是二进制浮点数，算钱会有精度误差，比如0.1+0.2可能等于0.30000000000000004。DECIMAL是定点数，按十进制存储，适合金额计算。所以商品价格、订单总价全部用DECIMAL(10,2)。

库存字段要加“乐观锁”机制。在高并发下单场景下，如果两个请求同时读到库存为1，都做扣减，就可能超卖。解决方式是在商品表加一个version字段，UPDATE product SET stock = stock - 1, version = version + 1 WHERE id = ? AND version = ?。虽然毕设阶段并发量不大，但把这个机制写出来，在论文“系统设计亮点”部分又能加一分。

订单号和主键ID要分开。主键ID是自增的，不能暴露给用户，否则别人通过订单ID就能知道你有多少订单。订单号用时间戳+随机数生成，比如20250407121536000123这样的格式，保证唯一且无法猜测。

2.3 数据库初始化与测试数据准备

数据库脚本要包含建表语句和初始数据两部分。初始数据一定要充足，商品至少20条、分类至少6-8个、品牌5个以上、评价每条商品2-3条。有些人的演示站点看起来空荡荡的，就是因为只插了两条测试数据，页面渲染出来像半成品。

用Navicat或MySQL Workbench可以直接导入SQL脚本。脚本开头加DROP TABLE IF EXISTS保证可重复执行，这对后期改表结构重新导入非常方便。测试数据里的图片链接尽量用可访问的URL，如果你用本地图片，后面做演示时一旦换了电脑图片就会裂掉，非常尴尬。

3. 后端Spring Boot核心实现

后端是整个系统的“业务大脑”。这一部分我把核心环节的实现思路和关键代码都过一遍，从搭建骨架到订单闭环。

3.1 项目初始化与依赖配置

用Spring Initializr（https://start.spring.io）生成基础项目，Java版本选8或11，Spring Boot版本选2.7.x。为什么不用Spring Boot 3？因为3.x基于Jakarta EE，很多老资料、老教程不兼容，毕设阶段没必要给自己挖坑。核心依赖如下：

<dependencies> <!-- Web支持 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis-Plus，简化数据库操作 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- JWT鉴权 --> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <!-- Hutool工具包，包含各种工具类 --> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.18</version> </dependency> <!-- Lombok，减少样板代码 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

application.yml里配置MySQL连接和MyBatis-Plus：

spring: datasource: url: jdbc:mysql://localhost:3306/shop?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto

map-underscore-to-camel-case这个配置很重要，它能把数据库的create_time自动映射到Java实体的createTime字段，省去手写大量resultMap的麻烦。

3.2 统一返回结果与全局异常处理

前后端分离的项目，接口返回格式必须统一。我习惯用这样的结构：

@Data public class Result<T> { private Integer code; // 200成功，其他失败 private String message; // 提示信息 private T data; // 数据 public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

配合全局异常处理器，把业务异常和系统异常统一捕获：

@RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(BusinessException.class) public Result<?> handleBusinessException(BusinessException e) { return Result.error(e.getMessage()); } @ExceptionHandler(Exception.class) public Result<?> handleException(Exception e) { e.printStackTrace(); return Result.error("系统繁忙，请稍后重试"); } }

这样做的好处是前端只需在Axios拦截器里判断code是否为200，不用每个接口单独处理异常。答辩时还能理直气壮地说“我们做了全局异常兜底，不会把系统异常直接抛给前端”。

3.3 JWT登录鉴权与拦截器配置

用户登录后，后端生成一个JWT令牌返回给前端。前端把Token存在localStorage，每次请求时放在Header的Authorization字段里。后端通过拦截器校验Token并解析出用户信息。

Token生成工具类：

public class JwtUtils { private static final String SECRET = "your-secret-key"; private static final long EXPIRE = 7 * 24 * 60 * 60 * 1000; // 7天 public static String generateToken(Long userId, String username) { return Jwts.builder() .claim("userId", userId) .claim("username", username) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }

拦截器里校验Token：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行预检请求 if ("OPTIONS".equals(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token == null) { response.setStatus(401); return false; } try { Claims claims = JwtUtils.parseToken(token); request.setAttribute("userId", claims.get("userId")); return true; } catch (Exception e) { response.setStatus(401); return false; } } }

注册拦截器时注意：放行登录注册接口和商品浏览接口，拦截购物车、订单、后台管理等需要登录的接口。

注意：JWT的密钥不要硬编码在代码里，可以从配置文件读取。虽然毕设项目无伤大雅，但在论文里提一句“密钥按实际生产要求应配置化”，显得你考虑过安全问题。

3.4 商品列表的分页与条件查询

商品列表页是最核心的接口之一。用户进来要能按分类、品牌、价格区间、关键词筛选，还要支持分页。使用MyBatis-Plus的Page对象和LambdaQueryWrapper：

public Page<Product> searchProducts(int pageNum, int pageSize, Long categoryId, Long brandId, String keyword, Double minPrice, Double maxPrice) { Page<Product> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Product::getStatus, 1); // 只查上架商品 if (categoryId != null) { wrapper.eq(Product::getCategoryId, categoryId); } if (brandId != null) { wrapper.eq(Product::getBrandId, brandId); } if (StrUtil.isNotBlank(keyword)) { wrapper.like(Product::getName, keyword); } if (minPrice != null) { wrapper.ge(Product::getPrice, minPrice); } if (maxPrice != null) { wrapper.le(Product::getPrice, maxPrice); } wrapper.orderByDesc(Product::getSales); // 默认按销量排序 return productMapper.selectPage(page, wrapper); }

Controller层接收参数并返回分页数据：

@GetMapping("/product/list") public Result<?> list(@RequestParam(defaultValue = "1") int pageNum, @RequestParam(defaultValue = "12") int pageSize, @RequestParam(required = false) Long categoryId, @RequestParam(required = false) Long brandId, @RequestParam(required = false) String keyword, @RequestParam(required = false) Double minPrice, @RequestParam(required = false) Double maxPrice) { Page<Product> page = productService.searchProducts(pageNum, pageSize, categoryId, brandId, keyword, minPrice, maxPrice); return Result.success(page); }

这里有个实践心得：查询接口不要只返回实体类，而应该创建一个ProductVO，把分类名、品牌名、评论数这些前端需要展示的关联字段封装进去。实体类只对应一张表，VO可以组合多张表的数据，这是前后端分离项目里很重要的设计意识。

3.5 购物车与订单核心流程

购物车的实现比较直接，按用户ID和商品ID去查记录，存在就加数量，不存在就新增。关键是下单环节，要用事务保证一致性：

@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(Long userId, List<CartItemVO> items, Long addressId, String remark) { // 1. 校验收货地址是否属于当前用户 Address address = addressMapper.selectById(addressId); if (address == null || !address.getUserId().equals(userId)) { throw new BusinessException("收货地址不存在"); } // 2. 遍历购物车项，计算总价并检查库存 BigDecimal totalPrice = BigDecimal.ZERO; List<OrderItem> orderItems = new ArrayList<>(); for (CartItemVO item : items) { Product product = productMapper.selectById(item.getProductId()); if (product == null || product.getStatus() != 1) { throw new BusinessException("商品已下架: " + item.getProductName()); } if (product.getStock() < item.getQuantity()) { throw new BusinessException("库存不足: " + product.getName()); } totalPrice = totalPrice.add(product.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); // 创建订单明细快照 OrderItem orderItem = new OrderItem(); orderItem.setProductId(product.getId()); orderItem.setProductName(product.getName()); orderItem.setProductImage(product.getMainImage()); orderItem.setPrice(product.getPrice()); orderItem.setQuantity(item.getQuantity()); orderItems.add(orderItem); } // 3. 生成订单号并保存 String orderNo = generateOrderNo(); Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setTotalPrice(totalPrice); order.setStatus(0); // 待付款 order.setReceiverName(address.getReceiverName()); order.setReceiverPhone(address.getReceiverPhone()); order.setReceiverAddress(buildFullAddress(address)); order.setRemark(remark); orderMapper.insert(order); // 4. 插入订单明细 for (OrderItem orderItem : orderItems) { orderItem.setOrderId(order.getId()); orderItemMapper.insert(orderItem); } // 5. 扣减库存 for (CartItemVO item : items) { productMapper.deductStock(item.getProductId(), item.getQuantity()); } // 6. 清空对应购物车 for (CartItemVO item : items) { cartMapper.deleteById(item.getCartId()); } return new OrderVO(order, orderItems); }

@Transactional保证这6步要么全成功要么全回滚。如果第5步扣库存失败，前面的订单不会残留，这是电商系统最基本的完整性要求。订单号生成用yyyyMMddHHmmss + 6位随机数，保证同一秒内也不会重复。

支付环节使用支付宝沙箱。接入流程是:下载支付宝SDK → 配置APP_ID、网关地址、应用私钥、支付宝公钥 → 创建支付请求 → 前端拿到支付表单后自动提交 → 用户完成支付 → 支付宝异步通知后端 → 后端验签并更新订单状态。异步通知这个点很多教程讲不清楚，我补充一句：支付宝会以POST方式访问你配置的notify_url，你必须在回调接口里验签并用success字符串响应，否则支付宝会重复通知。写订单状态更新时还要判断“这笔订单当前是否是待付款”，避免重复更新。这个逻辑在论文里能作为“系统安全设计”来写。

4. 前端Vue核心实现

前端这个环节，决定了你的项目第一眼看起来像不像一个“产品”。很多人代码写完了但界面丑、操作卡，分数上不去就是吃亏在前端还原度不够。Vue这套东西做到“能展示”到“好用”其实没那么难，关键是细节。

4.1 Vue项目初始化与路由设计

用Vue CLI或Vite创建项目。考虑到生态兼容性，Vue 2 + Element UI的组合资料多、报错少，适合毕设；如果你熟练，Vue 3 + Element Plus也可以，但遇到问题可能要多翻英文文档。

路由设计要区分前端和后端：

const routes = [ { path: '/', component: Home, meta: { title: '首页' } }, { path: '/product/list', component: ProductList, meta: { title: '商品列表' } }, { path: '/product/detail/:id', component: ProductDetail, meta: { title: '商品详情' } }, { path: '/cart', component: Cart, meta: { title: '购物车', requiresAuth: true } }, { path: '/order/confirm', component: OrderConfirm, meta: { title: '确认订单', requiresAuth: true } }, { path: '/order/list', component: OrderList, meta: { title: '我的订单', requiresAuth: true } }, { path: '/login', component: Login, meta: { title: '登录' } }, { path: '/register', component: Register, meta: { title: '注册' } }, { path: '/admin', component: AdminLayout, meta: { title: '后台管理', requiresAdmin: true, children: [...] } } ]

路由守卫里做登录校验：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') } else if (to.meta.requiresAdmin) { const user = JSON.parse(localStorage.getItem('user') || '{}') if (user.role !== 'ADMIN') { next('/') } else { next() } } else { next() } })

用localStorage还是sessionStorage存Token，很多人纠结。我的建议是localStorage，因为用户刷新页面后还要保持登录状态。缺点是有XSS风险，但毕设项目里做好输入过滤就行，不用过度设计。

4.2 Axios请求封装与Token注入

所有请求都走同一个Axios实例，好处是拦截器逻辑只写一次：

import axios from 'axios' import router from '@/router' const request = axios.create({ baseURL: '/api', // 开发环境通过Vue CLI代理转发到后端 timeout: 10000 }) // 请求拦截器：自动携带Token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = token } return config }) // 响应拦截器：统一处理业务错误 request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { this.$message.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') localStorage.removeItem('user') router.push('/login') } return Promise.reject(error) } ) export default request

baseURL设为/api，开发环境通过Vue CLI的vue.config.js里配置代理来解决跨域问题：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }

这里解释一下为什么要用代理而不是在后端直接开CORS。生产环境下前后端通常是同一个域名或通过Nginx转发，代理能模拟这个环境。后端如果开了CORS做开发测试，上线部署时反而更容易出问题。开发期间也可以在Spring Boot里加CORS配置，但建议上线时关掉，只保留同源策略，这样更安全。

4.3 购物车与订单确认页的交互设计

购物车页面最关键的是“选中状态联动”和“数量变化联动合计金额”。在Vue 2里用Vuex管理购物车状态，或者用组件内的data加computed驱动。如果购物车数据是进入页面时从后端拉的，最简单的方案是存在组件的data里，通过计算属性实时算出总价：

computed: { checkedItems() { return this.cartList.filter(item => item.checked) }, totalPrice() { return this.checkedItems.reduce((sum, item) => { return sum + item.price * item.quantity }, 0) } }

前端展示的价格是“元”，后端计算时用“分”还是“元”要统一。我建议后端和数据库都用“元”且保留两位小数，前端展示直接读接口值。有些项目喜欢用分做运算再转元，对毕设来说反而增加出错概率。

订单确认页在页面加载时要调后端接口拿到“当前用户的购物车选中项”和“默认收货地址”，用户能切换地址、填写备注。提交订单按钮要加防重复提交逻辑，用loading状态锁住按钮，避免用户连点两次生成两笔订单。这个细节踩坑的人非常多，我见过真实项目因为没加防重复提交，用户双击一下生成了两个订单，数据直接乱了。

4.4 管理后台页面与数据可视化

后台管理页面用Vue + Element UI的后台布局组件迅速搭好。左侧菜单、右侧内容的经典布局高度适配管理类系统，不需要自己去写繁琐的样式。菜单项包括：商品管理（列表+新增/编辑弹窗+图片上传）、分类管理、品牌管理、订单管理、用户管理、轮播图管理、数据统计。每个页面都是“表格+弹窗/抽屉+分页”的模式，写一个之后其他页面照着复制改字段就行。

数据统计页推荐用ECharts。引入方式很简单：

npm install echarts

然后在组件里引入：

import * as echarts from 'echarts' mounted() { this.initCharts() }, methods: { initCharts() { const chart = echarts.init(this.$refs.salesChart) chart.setOption({ title: { text: '近7日销售额趋势' }, xAxis: { data: this.salesData.dates }, yAxis: {}, series: [{ name: '销售额', type: 'line', data: this.salesData.amounts }] }) } }

后端对应提供两个统计接口：/admin/order/statistics返回近7天每日订单数和销售额，/admin/product/top10返回销量前10的商品。SQL用GROUP BY DATE(pay_time)配合COUNT和SUM就能实现，数据量不大性能完全没问题。

图片上传功能建议用本地存储方案。后端接收MultipartFile，保存到服务器指定目录，返回访问URL：

@PostMapping("/upload") public Result<?> upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { throw new BusinessException("文件不能为空"); } String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = UUID.randomUUID().toString().replace("-", "") + suffix; String uploadDir = System.getProperty("user.dir") + "/upload/"; File dir = new File(uploadDir); if (!dir.exists()) { dir.mkdirs(); } try { file.transferTo(new File(uploadDir + fileName)); } catch (IOException e) { throw new BusinessException("上传失败"); } // 配置虚拟路径映射，使上传的图片可以通过URL访问 return Result.success("/upload/" + fileName); }

同时配置静态资源映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + System.getProperty("user.dir") + "/upload/"); } }

注意：上传文件必须校验大小和后缀名，防止拖入恶意文件。Spring Boot的spring.servlet.multipart.max-file-size默认是1MB，如果要比这个更大的图片，需要显式配置。建议设为5MB，对应商品详情图足够用了。

5. 论文结构与答辩准备要点

论文是高分毕业设计里不能忽视的另一半。很多人代码做完了，论文却凑字数、逻辑混乱，最后评分直接被拖垮。其实论文有非常清晰的套路，按照“系统分析—系统设计—系统实现—系统测试”这条主线来写，基本不会出错。

5.1 论文章节框架与写作重点

推荐章节结构：

1. 绪论（约2000字）：研究背景和意义（电商发展趋势、美妆线上消费需求）、国内外研究现状（国内外电商平台的发展、Spring Boot/Vue技术发展）、主要研究内容。

2. 相关技术介绍（约2500字）：Spring Boot框架、Vue框架、MySQL数据库、MyBatis-Plus、JWT、ECharts。每个技术点写300-400字，介绍是什么、优点、为什么选用。

3. 系统分析（约3000字）：可行性分析（技术、经济、操作）、需求分析（功能性需求、非功能性需求）、用例分析。非功能性需求一定要包括安全性（用户密码加密、数据校验）、性能（页面响应时间）、易用性（界面友好）。

4. 系统设计（约4000字）：总体架构设计（前后端分离结构图）、功能模块设计（每个模块的流程图或文字说明）、数据库设计（E-R图、数据表清单与关键字段说明）。

5. 系统实现（约6000字）：每个模块的实现过程，代码+截图配合。商品模块、购物车模块、订单模块、后台管理模块各写1500字左右，代码要有注释解释关键逻辑。

6. 系统测试（约2500字）：测试环境、功能测试用例表（输入、预期输出、实际结果）、性能测试（用JMeter做个简单压测）、测试结论。

7. 总结与展望（约1000字）：总结项目做了什么、学习到了什么、系统还有哪些不足、后续怎么改进。

图表在论文里非常重要。E-R图用PowerDesigner或draw.io画，架构图、时序图、流程图也要有，一个图顶一千字。很多同学不知道流程图画起来很费时间，这里可以用PlantUML快速生成，文本描述绘图逻辑，比手拖图形快得多。

功能测试用例表一定要做，这是论文里最好写但最容易被忽视的部分。建一张表：用例编号、测试模块、前置条件、操作步骤、预期结果、实际结果、是否通过，每个模块写5-8条用例，论文篇幅和严谨性同时拉满。

5.2 答辩常见问题与应对思路

答辩时老师大概率会盯着你的项目问技术细节，这里列几个高频问题和应对思路：

Q1：为什么选Spring Boot不用SSM？ 回答思路：Spring Boot简化了SSM中大量的XML配置，内嵌Tomcat，配合自动配置和Starter机制能快速搭建项目。但底层还是Spring MVC和MyBatis，所以本质上是SSM的升级简化版。

Q2：前端页面是怎么跟后端通信的？ 回答思路：先用Vue的Axios发起HTTP请求，经过代理转发到后端Controller，Controller接收参数后调用Service层处理业务，Mapper层操作数据库，结果再一层层返回给前端渲染。中间用统一返回对象Result封装，用JWT Token做身份认证。

Q3：数据库表是怎么设计的，哪些表之间有外键关联？ 回答思路：围绕用户、商品、购物车、订单、评论五类核心实体设计。订单和订单明细是一对多关系，订单表存收货人信息快照，订单明细存商品信息快照，这样订单数据不受商品修改影响。外键约束建议在应用层维护而不用数据库外键，避免删除商品时出现外键报错。

Q4：系统有哪些安全性考虑？ 回答思路：用户密码用BCrypt加密存储；登录后用JWT Token配合拦截器保护接口；商品下单用事务保证数据一致性；管理端和用户端权限分离，通过角色字段控制访问。

Q5：如果并发量大，系统有哪些瓶颈，怎么优化？ 回答思路：库存扣减可以用乐观锁；热门商品加Redis缓存；数据库查询优化加索引；前端加CDN静态资源缓存。即使你项目里没有全部实现，把优化方向说出来，老师就知道你理解系统扩展方向。

5.3 演示环境的准备与答辩演示技巧

答辩现场最怕的就是“环境出问题”。提前做三件事：

第一，导出完整的SQL脚本，在另一台电脑重新导入一次，确认脚本没有依赖本地配置。第二，准备一个“一键启动说明”，把后端启动命令、前端启动命令、数据库导入顺序写成文档。第三，录一份操作演示视频作为保底方案，万一现场网络不好或者环境炸了，直接放视频也能完成演示。

演示时按这条主线走：注册账号 → 首页浏览商品 → 搜索/筛选 → 查看商品详情 → 加入购物车 → 去结算 → 选择地址 → 模拟支付 → 查看订单 → 管理端登录 → 管理订单发货。这条链路覆盖了项目所有核心功能，大概8分钟能讲完，节奏紧凑、逻辑清晰。不要在演示时花大量时间展示不痛不痒的操作，比如改头像、个人资料，评委关注的是核心业务闭环。

6. 常见问题与排查技巧实录

做这类项目，有一个算一个，都会踩到下面几个坑。我把高频问题和排查思路整理成速查表，碰到直接对号入座。

6.1 环境配置类问题速查

6.2 业务逻辑Bug排查实录

订单状态不更新，是我做项目时碰到最多的一个问题。典型现象是：用户支付成功，支付宝也提示扣款了，但系统里订单状态还是“待付款”。排查思路分三步：

第一步看支付宝异步通知有没有到达后端。在notify_url接口第一行打日志，如果没日志，说明异步通知地址不对或者支付宝没发过来。注意notify_url必须是外网能访问的地址，本地开发可以用内网穿透工具（如ngrok）把本地端口暴露到公网，或者在支付宝沙箱的“开发设置”里使用支付宝提供的模拟通知工具。

第二步看验签是否通过。支付宝SDK的AlipaySignature.rsaCheckV1需要正确的支付宝公钥，很多人把应用公钥和支付宝公钥搞混了。密钥配置错了验签就会失败，系统会一直收不到成功回调。

第三步看状态更新逻辑。回调处理里要判断当前订单状态，如果已经是“已支付”就不重复处理。如果这步没判断，用户重复支付时可能出现状态被覆盖成旧值的问题。

库存扣成了负数也是一个高频问题。虽然毕设项目并发量低，但如果在管理员后台测试时连续下单，或者自己写脚本多次调用下单接口，就很容易复现。解决方式是SQL扣减时加remaining_stock >= quantity条件：

UPDATE product SET stock = stock - #{quantity}, sales = sales + #{quantity} WHERE id = #{productId} AND stock >= #{quantity}

受影响行数为0说明库存不足，业务层抛出异常并回滚。这个方案比先查库存再更新更可靠，因为“查和改”之间理论上会被其他请求插队。

6.3 部署上线的经验总结

毕设做完后如果需要部署到服务器上，有几件事按顺序做：

后端打jar包前先在application.yml里把数据库连接改为服务器上的MySQL地址，然后执行mvn clean package -DskipTests。打出来的jar包用java -jar xxx.jar启动，注意服务器防火墙要放行8080端口。

前端执行npm run build，生成dist目录。把dist目录里的静态文件复制到Nginx的html目录下，配置Nginx把/api路径代理到后端服务：

server { listen 80; server_name your-domain.com; location / { root /usr/share/nginx/html; index index.html; } location /api { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

部署时容易忽略MySQL字符集。建库时用CREATE DATABASE shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;，原因很简单：utf8mb4支持emoji表情和所有特殊字符，如果商品名或者评价里带了特殊符号，utf8会直接报错。这是线上环境踩过的最经典的坑之一。

另外，部署到服务器后，前端要改成访问服务器域名而不是http://localhost:8080。如果不想改代码，可以在Nginx里把/api代理配好，前端保持baseURL: '/api'不变，这样前后端代码都不用动，部署成本最低。

7. 写在最后的一点个人经验

做了这么多类似项目，最大的感受是：成功的关键不在某个技术点的难度，而在整体节奏和细节把控。系统规划好功能模块再动手，数据库表设计冗余度高一点，前后端接口约定尽量提前定死，项目推进就会非常顺。

尤其要提醒的是，这类毕设项目一定要亲手把代码一行行敲出来，不要直接拿网上的源码交差。答辩时老师随便深挖一个问题，比如“你订单模块的事务是怎么加的”“Token失效了怎么办”“商品下架后购物车里的数据怎么处理”，如果代码不是你写的，几句话就会露馅。

时间分配上，建议按“数据库设计1周 → 后端接口2周 → 前端页面2周 → 联调测试1周 → 论文写作2周”的节奏来排。数据库设计阶段多花点时间，后面能省出三倍的返工时间。如果中途卡住了，优先查官方文档和Stack Overflow，中文博客作为参考，但很多博客代码年久失修，实测下来问题不少。

这个项目后续还可以扩展的方向有很多：加Spring Security做更细粒度的权限控制、引入Redis做商品缓存和购物车、用RabbitMQ处理订单超时关单、接入微信小程序端。做完基础版之后往这些方向延伸，哪怕只是实现一个“订单超时未支付自动关闭”的定时任务，都能让项目在答辩里脱颖而出。

我始终觉得，毕设项目不是用来“表演”的，而是让评委相信你真的能独立完成一个完整的软件系统。每一步都能讲清楚“为什么这样设计”，比堆砌一百个花哨功能更重要。

本文还有配套的精品资源，点击获取