SpringBoot+Vue+MySQL网购平台源码详解：从环境搭建到项目部署全流程

每年总有那么几波人找我，手里捧着一个“网购平台信息管理系统源码”，SpringBoot后端加Vue前端，数据库用MySQL，标题末尾还要带一句“可直接运行”，然后问我要怎么把它跑起来、怎么改、怎么在答辩的时候讲清楚。

说实话，这类项目我见得太多也太熟了。它的技术组合非常经典：SpringBoot + Vue + MySQL，基本就是当下全栈入门和课程设计里最主流的一套样板。能跑起来只是一个及格线，真正拉开差距的是你懂不懂它为什么这么拆、每一层在干嘛、遇到报错能不能两分钟定位。这篇内容我就拿这个典型的网购平台项目做例子，把后端、前端、数据库、本地运行和常见坑从头到尾拆一遍。如果你是刚拿到这类源码的学生，或者想转行全栈但对着项目不知道从哪下手，这篇应该能帮你省下好几天瞎折腾的时间。

1. 项目全景拆解：先看懂这套源码再动手

1.1 为什么是SpringBoot、Vue和MySQL这个组合

先说个扎心的事实：市面上流通的这类“信息管理系统”源码，九成以上都选了这三件套。不是巧合，而是这套组合在“能演示、能交付、能扩展”这三件事上，性价比最高。

SpringBoot解决的是后端的“快速搭建”问题。内嵌Tomcat，不用额外装服务器，一个jar包就能跑，maven管理依赖，省去一堆xml配置，对于课程设计和中小型项目来说非常够用。Vue解决的是前端“交互体验”和“前后端分离”的问题。页面组件化、路由切换、状态管理都有成熟方案，而且Vue在国内社区活跃，中文资料多，遇到问题搜起来快。MySQL解决的是“数据持久化”的问题。电商系统天生就是多表关联的场景，用户、商品、订单、购物车这些实体之间有明确关系，MySQL这种关系型数据库天然合适，而且免费、安装简单、工具箱一大堆。

这套组合决定了你要补的知识点：Java基础、Spring生态的常用注解、HTTP接口设计、SQL和表结构设计、Vue组件语法和前端工程化。说白了，把这个项目吃透，找工作时聊电商场景、聊前后端联调，你都有东西可讲。

1.2 功能模块地图：用户端和管理端各有什么

这类网购平台核心是两套端：普通用户的购物端，和管理员的运营后台。拿到源码后，别急着看代码，先看功能清单，心里有个地图。

用户端一般是这么一小套流程：

• 注册、登录，登录后保持会话状态
• 首页展示轮播图和推荐商品
• 商品按分类浏览，关键词搜索，分页展示
• 点击商品看详情，包括价格、库存、图片、描述
• 加入购物车，批量勾选下单
• 结算时要填收货地址，生成订单
• 查看自己的订单列表，能取消未支付订单
• 个人中心里改头像、改密码、管理收货地址

管理端相对粗暴一些，通常包含：

• 管理员账号登录，权限隔离
• 数据看板，就是几个统计卡片：注册用户数、商品数、订单数、销售额
• 商品管理：新增、编辑、上下架、删除，配合图片上传
• 分类管理：商品分类的增删改
• 订单管理：查看所有订单，修改订单状态，比如发货
• 用户管理：查看用户列表，禁用或启用账号

清楚这个功能范围之后，你才知道测试的时候该点什么，演示的时候该走哪条路径，也才知道哪些代码模块是核心、哪些是凑数的。

1.3 拿到源码先按这个顺序看，别上来就双击README

第一件事，别急着启动。先把压缩包解压，看顶层目录，通常分两个文件夹：一个后端工程，一个前端工程，外加一个SQL脚本文件。如果你的包连SQL脚本都没有，那说明作者默认让你用逆向工具从代码里反推出表结构，这种源码慎用。

第二步，找到数据库脚本，先看脚本文件名和编码。一般是.sql结尾，里面包含建库、建表和初始数据。把脚本用可视化工具打开，确认里面有没有admin账号和几条演示商品。如果演示商品都没有，你登录后台之后看到的是一堆空数据，演示效果会大打折扣。

第三步，打开后端的配置文件，通常是src/main/resources下面的application.yml或application.properties，看数据库地址、账号密码、端口号这些配置是不是被改过。大部分流通源码默认是localhost和root用户，但密码往往和你的本地环境不一致，这一步通常会踩坑。

第四步，打开前端的工程文件，看package.json，确认它是Vue2还是Vue3。这里是个大分水岭：Vue2对应Element UI，Vue3对应Element Plus，安装的依赖完全不同，很多新人在这里装错依赖导致白屏。

2. 后端核心设计与业务实现：从分层架构到订单状态机

2.1 后端分层架构：一条请求是怎么被处理的

拿到SpringBoot后端工程，别被一屏幕的包名吓住。它基本逃不出四层结构：Controller、Service、Mapper、Entity，有的项目还多个DTO和VO，但万变不离其宗。

从一次“用户登录”请求来看整个链路就很清晰。前端把用户名密码POST到登录接口，Controller层接住参数，不写业务逻辑，只负责参数接收和结果返回。Service层做校验，比如查数据库、比对密码、生成Token。Mapper层写在接口上，通常继承了MyBatis-Plus的BaseMapper，你要做的就是在Service里调用它。Entity层就是数据库表在Java里的映射，字段一一对应。

这个分层的意义在于：每个类只干一件事，改代码的时候不会牵连一片。比如你想在登录成功后加一个“最后登录时间”字段，只需要改Service层，Controller不用动。开始学的时候，你可以养成一个习惯：从前端调用的每个API，顺着找Controller里的方法，再跳转到Service实现类，最后看Mapper方法对应哪条SQL，把这条链路读通，你对整个后端的理解会突飞猛进。

2.2 登录鉴权：JWT到底怎么用，为什么不用Session

大多数这种网购平台后端，不会用传统Session做登录态，而是用JWT。原因很现实：前后端分离之后，前端可能部署在另一个端口甚至另一台服务器，Session跨域处理起来很麻烦，而JWT把用户身份信息直接编码在Token里，后端不存状态，前端把Token存到localStorage，每次请求带上就行。

JWT的流程典型是这样的：用户登录成功后，后端根据userID生成一个带过期时间的Token，返回给前端，前端存起来。下一次请求，前端在请求头里加Authorization字段。后端写一个拦截器，拦截需要登录的接口，从请求头取出Token，验签和检查过期时间，解析出用户ID，然后再放行到Controller。

这个机制的配置位置一般在两处。一是JWT工具类，负责生成和解析Token；二是拦截器或者过滤器，负责拦截请求。很多新人在改JWT密钥时只改了一个地方，导致生成Token和解析Token用的密钥不一致，登录永远报401，这就是典型的“密钥没统一”。

放一段典型的JWT工具类核心逻辑给你参考：

java复制public class JwtUtil {
    private static final String SECRET = "你的自定义密钥";
    private static final long EXPIRE = 72 * 60 * 60 * 1000L; // 72小时

    public static String generateToken(Long userId, String role) {
        return JWT.create()
            .withClaim("userId", userId)
            .withClaim("role", role)
            .withExpiresAt(new Date(System.currentTimeMillis() + EXPIRE))
            .sign(Algorithm.HMAC256(SECRET));
    }

    public static DecodedJWT verify(String token) {
        return JWT.require(Algorithm.HMAC256(SECRET)).build().verify(token);
    }
}

这里有个值得注意的设计：Token里塞了userId，那Token过期之前用户被删除怎么办？很多简单项目不管这个，但对于你答辩来说，能说出“用户操作时再校验角色和状态”这种话，说明你想过权限边界。

2.3 商品、购物车、订单的典型业务逻辑

电商系统的后端难点不在CRUD，而在订单这种涉及多个表的状态流转。我先说商品上下架：商品表里通常会有一个status字段，1表示上架，0表示下架。用户端查询列表的时候，SQL里必须带上状态过滤，否则后台下架的商品还在前台售卖。

购物车逻辑比较简单，通常是一张表，用户ID加商品ID唯一。这里常见的坑是加入购物车时没判断“这个商品是不是已经在购物车里了”，结果是同一个商品加了好几条记录。处理逻辑应该是：存在就数量加一，不存在才新增。

订单模块是整个系统最有含金量的部分。下单动作至少做三件事：往订单表插一条记录、往订单明细表插对应商品记录、扣减库存。这三件事必须放在同一个事务里，否则会出现库存扣了但订单没生成这种灾难现场。你可以在Service方法上看到@Transactional注解，这就是开启事务的标识。

订单状态通常用数字表示，比如0待支付、1已支付、2已发货、3已完成、4已取消。管理端改订单状态时，要注意状态只能往后走，比如已发货的订单不能直接取消。有的系统在Service层写了一大堆状态判断，看着笨，但确实是防止业务错乱最简单有效的办法。你改代码时一定要守住这条线。

2.4 MyBatis-Plus：数据访问层那些你已经用上但不一定懂的细节

MyBatis-Plus在这类项目里的普及率极高。是因为它让数据访问变成“零SQL”操作：继承了BaseMapper之后，selectById、selectList、insert、updateById这些基础方法全都有，你不再需要手写SQL。

重点说几个高频特性。分页是商品列表离不开的，但你会发现直接调用selectPage并不生效，原因是缺少分页插件配置。需要单独建一个配置类，注册一个PaginationInnerInterceptor到MyBatis-Plus里。这是新手最常见的“接口返回数据正常但分页参数无效”的元凶。

逻辑删除也是高频特征。电商系统里删除商品很少是物理删除，不然订单明细里关联的商品信息就没了。实现方式是给表加一个deleted字段，配置@TableLogic注解，这样调用deleteById时实际执行的是UPDATE。好处是不会误删数据，坑在于如果你手写SQL，一定要记得加上deleted=0的条件，否则你亲手把“已删除商品”查出来展示。

另一个实用细节是自动填充。create_time、update_time这些字段如果能自动填充，就没必要每张表手动set。实现方式是定义MetaObjectHandler，配合字段上的@TableField(fill = FieldFill.INSERT)，插入时自动填时间。这套机制让代码干净很多，面试时聊到也是加分项。

3. 前端核心设计与页面交互：从页面拼接到权限控制

3.1 Vue工程结构：先弄清这五个文件夹是干什么用的

前端工程打开后，你会有种“完全看不懂”的焦虑，因为文件实在太多了。但绝大部分Vue工程都是同一套骨架：src下面必有views、components、router、store、utils、api这几个目录。

views放的是页面级组件，一般一个路由对应一个v-file名，比如Home.vue、Login.vue、ShopCart.vue。components放的是被页面复用的局部组件，比如商品卡片、分页条、弹窗。router只有一个入口文件，在里面定义路由表，每个路由绑定哪个页面，哪些路由需要登录才能访问。store是状态管理，Vue2里一般是Vuex，Vue3里可能是Pinia，用来存全局共享的数据，比如用户信息。api或utils目录放请求封装和工具类。

你把思路转过来就顺了：一个页面文件被路由加载，页面里引入组件，组件里调用API，API拿到数据后要么存到store，要么直接渲染成页面。前端所有框架都是在干这么一件事，只是写法有差异。

这里有一个很重要的实操建议：拿到源码后先在router目录里把整个路由表读一遍。路由表像一个目录，能告诉你系统有多少个页面、哪些页面挂在哪个路径下、布局组件套了哪些子页面。读路由表比读任何需求文档都直观。

3.2 用户端页面链路：从首页到下单的完整串联

用户端页面虽然多，但核心链路就一条：首页推荐商品，点进详情，加入购物车，提交订单，查看订单状态。这条链路能走通，这个系统基本就立住了。

首页组件一般包含顶部导航、轮播图、分类导航、商品列表。轮播图数据在后台通过接口管理，改动图片后刷新首页就能看到。商品列表往下滚动通常触发分页加载，你可以在接口请求参数里看到pageNum和pageSize两个字段。

商品详情页是信息密度最大的页面：主图、价格、标题、库存、销量、详情描述，另外还有一个“加入购物车”按钮和“立即购买”按钮。点击加入购物车时，前端会把商品ID和数量POST到后端。购买按钮则可能跳过购物车，直接跳转到创建订单的页面。

购物车页面上，每个商品项可以勾选、修改数量、删除。结算按钮只处理勾选了的商品。这里前端逻辑要做得严谨，因为如果前端把未勾选的商品也传给了后端，结果是用户没选的东西也被下单了。

订单结算页要有地址选择或新增地址的入口，提交后跳转到订单列表页。订单列表页根据状态显示标签，比如待支付、已发货、已完成。整体走下来，你会发现前端页面之间全是通过路由跳转和参数传递串起来的，把这条链路讲清楚，是项目演示时的核心脚本。

3.3 管理端功能拆解：商品管理、订单处理和统计看板

管理端通常和用户端的登录分开，或者复用同一套登录机制但靠用户角色来区分页面。打开路由表时，你会看到管理端路由普遍带一个requiresAdmin之类的meta标记，作用是在前端路由守卫里做角色校验，不是管理员就不让进。

管理端的核心页面有三个。第一个是数据看板，页面顶部是几个统计卡片，下面常有图表展示订单趋势或商品分类占比。这里的数据来自后端聚合接口，你可以顺着接口看它SQL怎么写，通常是GROUP BY加COUNT，值得你学习。

第二个是商品管理页，表格里展示商品缩略图、名称、价格、库存、状态，操作列有上架、下架、编辑、删除按钮。编辑或新增时会弹出一个表单页，里面包含商品所有信息录入，提交时走新增或更新接口。

第三个是订单管理页，默认展示全部订单，管理员可以按订单状态选项卡筛选。点详情可以看到订单的商品明细和收货地址，操作方法一般是发货，也就是把状态从已支付改成已发货。这个页面最适合演示你的系统“管理”能力，答辩时一定要熟练操作一遍。

3.4 Axios封装与路由守卫：前端安全的两道门

前端不能替代后端做安全校验，但必要的拦截和跳转能让使用体验好很多。几乎所有这类项目的utils目录里都会有一个封装好的axios实例。

封装的目的是统一处理三件事：请求时自动带上Token，响应时统一解包数据，出错时统一跳转。Token从localStorage里取出来，加到请求头Authorization字段。响应拦截器里如果发现HTTP状态码是401，就直接清掉本地Token并跳回登录页，避免用户看到一堆莫名其妙的报错。

路由守卫是另一道逻辑闸门。每个路由可以配置meta信息，比如requiresAuth表示需要登录，requiresAdmin表示需要管理员角色。在router.beforeEach回调里读一下本地状态，没登录就去登录页，普通用户访问管理端就踢回首页。

一个典型的路由守卫长这样：

js复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.meta.requiresAuth && !token) {
    next('/login')
  } else if (to.meta.requiresAdmin && localStorage.getItem('role') !== '1') {
    next('/')
  } else {
    next()
  }
})

这个机制的关键点是：它只是用户体验层面的保护，真正该拦截的还是后端接口。你在答辩时如果能主动说出“前端守卫只是防君子不防小人，最终校验在后端拦截器”，给人的感觉会完全不一样。

4. 数据库设计与建模思路：电商系统的地基

4.1 核心表结构与字段设计

打开SQL脚本，你应该能看到至少五六张表：用户表、分类表、商品表、购物车表、订单表、订单明细表，稍微完善一点的还有轮播图表、收货地址表、用户操作日志表。

这几张表的设计有很强的共通性。用户表必须设计username、password、phone，密码字段之所以是255长度，是因为存的是BCrypt加密后的哈希串，加密后长度远超明文密码。商品表核心字段是title、price、stock、cover、status，价格字段用DECIMAL（10，2），不用float或double，因为浮点类型在订单金额计算上会有精度问题。

订单表必须設計order_no订单号，这个字段是唯一键，业务上一单一个编号。状态字段status用TINYINT即可，配合注释说明每个数字的含义。金额字段total_amount用DECIMAL，存的是所有商品总价，通常不含运费或运费为零。订单明细表则记录订单里每个商品的快照，包括当时的单价、购买数量，因为商品价格后来可能改价，但订单不该被影响。

示意一下用户表和订单表的建表语句，网上绝大多数这类源码都长这样，你可以对照自己的工程看：

sql复制CREATE TABLE `t_user` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `username` VARCHAR(50) NOT NULL,
  `password` VARCHAR(255) NOT NULL,
  `nickname` VARCHAR(50) DEFAULT '',
  `phone` VARCHAR(20) DEFAULT '',
  `role` TINYINT DEFAULT 0 COMMENT '0-普通用户 1-管理员',
  `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `t_order` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `order_no` VARCHAR(32) NOT NULL,
  `user_id` INT NOT NULL,
  `total_amount` DECIMAL(10,2) NOT NULL,
  `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0-待支付 1-已支付 2-已发货 3-已完成 4-已取消',
  `address` VARCHAR(255) NOT NULL,
  `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

4.2 表之间的关系与外键取舍

这几张表的关系很清晰：用户对订单是一对多，商品对订单明细是一对多，订单对订单明细是一对多，分类对商品是一对多。你在建表脚本里不一定看得到外键约束，大多源码只用逻辑关联，也就是在子表里存父表的主键ID，查询时靠JOIN或联表查询把信息拼起来。

不建物理外键是有原因的，外键约束会影响插入和删除性能，而且订单这种核心表一旦被外键锁住，后续做逻辑删除会很别扭。但这不等于没有关系，你在SQL里依然要通过user_id去关联用户表查出用户名，通过order_id去关联订单明细查出商品快照。

理解这种逻辑关联对改代码很重要。比如要显示“某个用户的订单列表”，实际SQL是：订单表按user_id过滤，再关联订单明细表取商品标题和数量。如果你能在数据库工具里把这几张表手动关联起来，画出线图，这个系统在你眼里就没有秘密。

4.3 初始化数据：admin账号和演示数据从哪来

这类项目之所以说“可直接运行”，SQL脚本里通常已经准备好了初始化数据：一个管理员账号、一个测试用户账号、几条商品分类、若干条商品记录、一两条轮播图数据。

这里有个必须留意的点：SQL脚本里的密码字段往往是一个固定的BCrypt哈希串，对应的是123456。如果你直接在数据库里改字段值，比如把admin的密码改成明文123456，登录是绝对不成功的。别问我为什么知道，这个坑我见过太多次。需要改密码的正确做法是，用一些在线工具或后端提供的注册接口生成对应的加密哈希，再替换到数据库里。

初始数据的意义在于让你启动完毕之后立刻有东西可点。如果启动后发现列表空荡荡，检查一下SQL脚本到底有没有INSERT语句，以及是否在导入数据库时选对了目标库。

5. 本地运行全流程实录：从JDK到启动两大端

5.1 环境准备清单：版本不对，后面全白搭

“可直接运行”这句话能信一半，另一半要看你的环境对不对。Java后端最常见的版本陷阱是JDK版本和SpringBoot版本不匹配，SpringBoot 2.x通常要求JDK8或11，SpringBoot 3.x要求JDK17及以上。前端方面，Vue2的老工程用Node 14或16比较稳，Vue3新工程用Node 16以上。MySQL建议5.7或8.0，两者在连接驱动上有些差异。

我推荐一个不容易出错的基础组合：JDK11、Maven3.6+、Node14、MySQL8.0、IDEA或Eclipse。你可以先查看源码里的pom.xml，看spring-boot-starter-parent的版本号，如果是2.7.x就用JDK11，如果是3.x就用JDK17，这是最稳妥的对应规则。

有个检测技巧：打开命令行，分别敲java -version、node -v、mvn -v、mysql --version，一次性看清所有版本。全部确认后再开始配置，否则你会陷入“明明按教程走但就是报错”的泥潭。

5.2 后端启动步骤：配置、导依赖、跑起来

第一步，用IDEA打开后端工程，IDEA会自动识别pom.xml并开始下载依赖。如果网络不好导致依赖下载缓慢，可以换Maven镜像源，把settings.xml里配置为国内仓库地址。这一步如果卡住，别开着项目傻等，优先换镜像。

第二步，修改配置文件。新建数据库，执行SQL脚本，然后把application.yml里的数据库地址和密码改成你自己的。同时确认server.port端口，默认8080，如果这个端口被占用，后面会细说怎么处理。如果你用了Redis，比如登录验证码功能，那还得本地安装Redis并启动服务。

第三步，启动入口类。找到带有@SpringBootApplication注解的Java类，右键运行。看到类似“Started Application in X seconds”的日志，说明后端启动成功。现在可以先用浏览器访问一下http://localhost:8080，如果返回错误页面或404是正常的，因为后端接口路径一般都有/api前缀。

这里有个小经验：启动后先别急着测页面，直接在浏览器访问一个不登录也能访问的接口，比如商品列表接口，看返回JSON是否正常。JSON正常说明数据库连接、MyBatis映射都没问题，再往下排查前端就有的放矢了。

5.3 前端启动步骤：npm install是第一个大坎

前端启动的思路是：先安装依赖，再改接口地址，最后启动开发服务器。

打开前端工程所在的目录，命令行执行npm install。这一步会安装package.json里列出的所有依赖，老项目的依赖多到可能要装几分钟。常见的失败原因是网络问题，解决方案是把npm镜像切到国内源，执行npm config set registry https://registry.npmmirror.com，然后重试。

依赖装完后，找到前端项目里的接口配置文件，通常在src/utils/request.js或src/api目录下的某个js文件里，里面会有一个baseURL地址。如果你用开发模式跑前后端联调，baseURL一般配成/api，并且借助vue.config.js里的devServer代理转发到后端。

接着在工程根目录执行npm run serve。启动成功后会打印一个本地访问地址，通常是http://localhost:3000。此时访问这个地址，前端页面就能出来了。注意：vue.config.js里的代理配置，是解决前端8080访问后端8080时跨域问题的关键，别漏掉。

一段典型的代理配置如下：

js复制module.exports = {
  devServer: {
    port: 3000,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
}

配置好之后，前端请求以/api开头的接口，都会被开发服务器转发到后端8080端口，浏览器里就不存在跨域问题了。

5.4 端到端验证：把一条购买链路完整走通

两个端都启动后，别急着说“跑通了”，一定要走一遍核心流程才算数。先用管理员账号登录后台，确认统计页有数据，里面能看到刚导入的演示商品的数字。然后退出登录，换普通用户注册一个账号，或者用脚本里预置的测试用户登录。

走一遍流程：在首页点开一个商品，加入购物车，进购物车勾选并结算，填地址，提交订单。回到订单列表看到订单状态是待支付。再切回管理员后台，找到这个订单，点发货，刷新用户端订单列表，状态变更为已发货。完成这整个回路，前后端所有关键代码都被你验证过了。

我在实际演示中还喜欢加一步：把某个商品下架，回到用户端刷新列表，确认这个商品不再出现在前台。这一步虽然简单，但对证明“系统管理能力”很有效果，答辩时用得上。

6. 常见问题与排查技巧实录：让人头疼的坑都在这里

6.1 端口占用：后端起不来，先找谁占用了8080

后端启动时报错“Port 8080 was already in use”，这说明有另一个程序占用了8080端口，常见是之前启动失败的残留进程，或别的开发工具。

排查方法：命令行执行netstat -ano | findstr 8080，查到占用端口的进程PID，再执行taskkill /PID xxx /F强杀。如果你不想杀进程，也可以直接改application.yml里的server.port，比如改成8081，但记得前端的代理target也要同步改，否则代理转发到8080找不到后端。

还有一种更隐蔽的情况：你改了端口，但前端代理没改，导致前端页面能打开，但所有请求都报500或网络错误。排查这类问题的通用姿势是：打开浏览器F12看Network面板，看请求到底发到哪个地址，返回值是什么。看到请求地址才谈得上定位问题。

6.2 跨域问题的本质与三种解法

前端页面能打开，但登录时报错或接口请求失败，浏览器报“CORS”或“blocked by CORS policy”，这是前后端分离最常见的坑。本质是浏览器安全策略：前端例子在3000端口，后端在8080端口，两者不认为是同一个站点，于是浏览器拦截了跨端口请求。

解法有三条。第一条是开发阶段用vue.config.js的devServer代理，这是最推荐的，因为浏览器感知到的始终是同源请求。第二条是后端加CORS配置类，在响应头里放Access-Control-Allow-Origin，适合快速验证但不适合生产。第三条是用Nginx做反向代理，把前端请求转发到后端，这是生产环境标准做法。

遇到跨域，先想清楚你在哪个阶段：开发阶段优先代理，联调阶段检查代理路径和后端接口前缀是否一致，部署阶段交给Nginx。记住这个顺序，能少走很多弯路。

6.3 数据库连接失败：时区、密码和驱动

后端启动时报“Cannot create PoolableConnectionException”，或者“Communications link failure”，十有八九是数据库连接配置出了问题。先确认三件事：MySQL服务启动了没有；账号密码对不对；数据库名存不存在。

另一个高频问题是时区。报错里出现“The server time zone value”，说明连接串里没指定时区。解决办法是在url后面加参数serverTimezone=Asia/Shanghai，同时加上useUnicode=true和characterEncoding=utf8，这样既能解决时间差8小时的问题，也能避免中文乱码。

MySQL8和MySQL5的驱动类名也不同。MySQL8的driver-class-name是com.mysql.cj.jdbc.Driver，MySQL5则用com.mysql.jdbc.Driver。如果你的驱动版本和MySQL版本不匹配，会出现“Public Key Retrieval is not allowed”这类奇怪错误，追加allowPublicKeyRetrieval=true参数即可。

6.4 前端依赖装不上：慢、失败、版本冲突

npm install最常见的三个问题是：下载慢、安装报错、装完后启动报一堆语法错误。

下载慢好解决，切镜像源。安装报错要看具体信息，90%的报错都是网络原因或权限原因，Windows下用管理员身份打开命令提示符，能解决很多奇怪的权限问题。

最阴间的坑是版本冲突：package.json里要求的是Element UI版本，但npm装成了另外一个大版本，或者Node版本过高导致某些依赖编译失败。我的经验是：老项目尽量用Node14，装依赖时不要轻易执行npm update，也不要手动npm install某个最新版本，保持和源码一致的版本树才是稳的。如果启动后页面白屏且控制台报错，先看包版本，再看main.js里组件注册是否完整。

6.5 高频报错速查表：按图索骥五分钟定位

这张表是我反复排查这类项目的经验汇总。遇到问题时按“现象->原因->处理”的顺序走，比乱试一万次都有效。

最后说点实在的。这种“SpringBoot+Vue+MySQL”的网购平台系统，圈里很多人说它烂大街，但我一直觉得它是练全栈整合能力最好的样板。你不需要纠结项目本身新不新，关键是把它的每一层读透，再动点手改成自己的东西。比如给商品模块加个搜索历史、给订单加个取消理由、把后台统计改成图表，这些改动都不复杂，但能让你的项目答辩从“我复制了一个系统”变成“我理解了一个系统”。这个项目我前后接触过太多版本，最深的体会是：跑通只是起点，能说清楚每一段代码为什么这么写，才是真正让你在学习和求职时站稳脚跟的东西。