企业官网建设流程全解析

不说废话，直接进入正题。你看到的这个标题——"飘香水果购物网站信息管理系统源码-SpringBoot后端+Vue前端+MySQL【可直接运行】"，说的就是一套完整的前后端分离电商项目，以水果生鲜为业务场景，从用户注册登录、商品浏览、购物车、下单支付（模拟），到后台的商品管理、订单管理、分类管理，功能链条非常完整。对于正在做Java课程设计、毕业设计，或者想系统学习SpringBoot+Vue前后端分离开发的同学来说，这是一个极佳的参考项目和练手素材。

我花了一整天时间把整套源码下载、导入、配置、跑通，又顺着代码把所有关键流程捋了一遍，整理出这篇文章。下面会从项目架构、核心代码逻辑、数据库设计、本地运行步骤、常见故障排查这几个维度展开，尽量把每个环节的“为什么”也讲明白，而不只是给你一个“照着做就能跑”的教程。如果你也准备拿这套代码做二次开发、写论文或者面试讲项目，这篇内容值得仔细看。

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

1.1 为什么偏偏是SpringBoot+Vue+MySQL这个组合

先聊一个很多人忽略的问题：市面上课设项目那么多，为什么“SpringBoot + Vue + MySQL”成了绝对的主流？这套组合背后的选型逻辑，恰恰是它最值得学习的地方。

从后端看，SpringBoot把Spring那个曾经繁琐到劝退新人的配置过程大幅简化，内嵌Tomcat，一个java -jar就能起服务，配合SpringMVC做接口暴露、MyBatis-Plus做数据库操作，开发效率非常高。从招聘市场的真实情况来看，Java后端岗位几乎绕不开SpringBoot，所以拿它做课设，本身就是提前进入工业级开发节奏。

从前端看，Vue的渐进式框架设计让它对新手特别友好。你不需要一开始就掌握完整的前端工程化体系，只需要理解组件、路由、状态管理这几个核心概念，就能搭出一个像模像样的管理后台和用户商城页面。配合Element UI这样的组件库，做出来的界面不会像传统JSP项目那样停留在“能用”的水平，而是真的接近商业网站质感。

再来看MySQL，它依然是中小型项目最稳妥的数据库选型。够用、免费、资料多，出了任何问题都能在搜索引擎找到解决方案。水果商城这种业务场景，表结构不算复杂，MySQL完全能扛住，而且Navicat、Workbench这些可视化工具让建表和调试变得很直观。

1.2 果蔬商城到底“卖”的是什么功能

“水果购物网站”听起来简单，但真正拆开来看，你会发现它其实是一个麻雀虽小、五脏俱全的电商系统。前端用户端要覆盖完整的购物链路，后端管理端要覆盖完整的运营链路。

用户端核心链路是这样的：游客可以浏览商品列表、查看商品详情，一旦想下单，就必须走注册登录。登录之后可以把商品加入购物车，在购物车里修改数量或删除，确认后提交订单。订单生成后，模拟支付流程（通常直接置为已支付或引导用户点击“模拟支付”按钮），用户可以在“我的订单”里查看所有历史订单和订单状态。

管理端则是另一个视角：管理员登录后进入后台，看到仪表盘统计（用户数、订单数、销售额之类的汇总），然后可以管理商品分类、管理商品上下架与库存、处理订单（发货、完成、取消）、查看注册用户列表。有的版本还包含轮播图管理和公告管理，算是卖点加分项。

从教学角度，这套需求设计非常聪明：每一条功能都能对应到一个经典的技术知识点。比如登录对应JWT或Session会话管理，购物车对应Redis或数据库存储方案选型，订单状态变化对应枚举与状态机设计，商品搜索对应SQL模糊查询或全文索引。这意味着你做完这个项目，学到的不只是一堆“增删改查”，而是电商业务中真实存在的表设计思路和接口约定方式。

1.3 拿到源码后的第一件事：看懂目录结构

很多人下载完源码就直接双击运行，报错了再到处搜解决办法，这其实是最低效的学习路径。我的建议是，先花半小时把项目目录结构“读”一遍，搞清楚每一层是干什么的，后面出问题你才知道去哪排查。

这套项目的后端通常是标准的Maven多模块或单模块结构，核心包名类似com.piaoxiang或com.fruit。controller包放接口入口，service包放业务逻辑，mapper（或dao）包负责数据库交互，entity（或pojo、domain）包放数据库实体类，config包放配置类（跨域、拦截器、全局异常处理等），common或utils包放工具类和统一返回结果封装。前端则通常是一个Vue CLI创建的项目，src/api目录封装所有后端请求，src/router配置路由，src/views按页面划分组件，src/store管理全局状态（Vuex或Pinia）。

把这层结构弄懂了，你会发现“前后端分离开发”这个概念变得很具体：前端只负责页面渲染和交互，后端只负责数据处理和业务逻辑，两者通过JSON格式的HTTP接口通信。调试的时候，前端看Network面板确认请求是否发出、响应是什么，后端看控制台日志和SQL输出，问题出在哪一层一目了然。

1.4 为什么“可直接运行”并不是一句废话

说实话，我在拿到源码之前，对这五个字是半信半疑的。因为很多标榜“可直接运行”的源码，实际配套资料不齐全，数据库脚本缺表、前端依赖版本冲突、后端JDK版本不匹配，一个接一个的坑。但这套水果商城的完整度确实值得夸一句：压缩包内通常包含完整的后端代码、前端代码、数据库SQL脚本、以及一份部署说明文档，SQL脚本里的数据也是现成的（包括管理员账号、测试商品、测试用户）。

这背后其实反映了一个优质课设项目的标准：不是功能越多越好，而是让人能复现、能扩展、能讲清楚。我见过太多同学买源码回来，东缺一个依赖西缺一个配置，花了两天时间在配环境，最后项目没跑起来还要被导师质疑是不是自己写的。所以这次我特意花了时间把运行过程中所有可能踩的坑都试了一遍，后面的内容全部是实战记录。

2. 后端核心细节解析与实现原理

2.1 SpringBoot项目结构里的“标准答案”

这套项目的后端结构，基本可以作为SpringBoot入门项目的教科书式范例。启动类上标注@SpringBootApplication，内部组合了@Configuration、@EnableAutoConfiguration、@ComponentScan三个注解，自动配置加组件扫描让Spring容器知道去哪里找Bean。application.yml（或application.properties）里配置服务端口、数据库连接信息、MyBatis-Plus相关配置。

实体类与数据库表一一对应，例如User实体对应user表，属性使用驼峰命名法，与数据库下划线字段通过MyBatis-Plus的驼峰映射自动转换。这里特别提一下，主键ID通常会使用@TableId(type = IdType.AUTO)指定自增策略，插入数据后会自动回填主键值，这个细节在编写新增接口时很有用，比如订单创建后需要立刻拿到订单ID来生成订单详情。

Mapper层全部继承BaseMapper<T>，这是MyBatis-Plus最让人舒服的地方。你要查一个用户，不需要写selectByUsername的XML，直接selectOne(new LambdaQueryWrapper<User>().eq(User::getUsername, username))就完事了。条件构造器看起来像魔法，但本质上就是帮你动态拼接SQL，掌握LambdaQueryWrapper的eq、like、between、orderByDesc这几个方法，这个项目的所有查询你都能看懂。

Service层在接口定义方法、在实现类中用@Service注解标注。业务方法上习惯添加@Transactional(rollbackFor = Exception.class)，保证多步数据库操作要么全部成功、要么全部回滚。比如创建订单这个操作，需要先插入订单主表、再批量插入订单详情表、还要扣减商品库存，三步操作绝不能执行一半就中断，事务在这里就是必不可少的保证。

2.2 登录认证与拦截器的实现思路

看这套代码时，登录认证的设计非常值得仔细研究，因为它直接反映了对HTTP无状态特性的理解。传统JSP项目用Session保存登录态，但前后端分离项目里，更常见的方案是Token机制（JWT或自定义Token）。前端登录成功后把Token存到localStorage，之后每次请求都在请求头里带上Authorization: token值，后端通过拦截器统一验证。

具体到代码，后端通常会定义一个LoginInterceptor实现HandlerInterceptor接口，在preHandle方法里从请求头取出Token，调用工具类解析，如果解析失败直接返回401状态码和统一JSON提示，如果成功就把用户信息放入ThreadLocal或request属性中，方便Controller层直接获取当前登录用户。然后在WebMvcConfigurer实现类中注册拦截器，并通过addPathPatterns和excludePathPatterns精细控制哪些路径需要登录、哪些路径放行（比如登录接口、注册接口、商品列表接口）。

这种设计的学习价值在于，它把“认证”从每个业务接口中抽离出来，变成了横切关注点。你不必在每个需要登录的接口里写一遍Token验证代码，而是通过配置统一搞定，后面要加新的需登录接口，只需在拦截器路径配置里加一行。

2.3 统一返回结果与全局异常处理的必要性

如果你在前后端联调时见过那种“明明后端报错了，前端却只拿到一串看不懂的堆栈信息”的情况，就会明白统一返回结果封装有多重要。这套项目的Controller层方法返回值，一般不直接返回实体类，而是返回Result<T>这类统一封装对象，里面通常包含三个字段：code（状态码，如200成功、500失败）、msg（提示信息）、data（业务数据）。

配合全局异常处理，代码优雅程度能上一个台阶。定义一个类标注@RestControllerAdvice，里面写多个@ExceptionHandler方法，分别处理业务异常、参数校验异常、空指针异常等。Controller层就不用大量try-catch包裹业务逻辑了，像throw new ServiceException("库存不足")这样抛出异常后，会被全局处理器捕获并转换成标准JSON返回给前端，前端根据code值弹出对应的提示消息。

这个小设计看着不起眼，但在课程答辩时是很好的加分点，因为它体现的是对“接口设计规范”的理解，而不是只会写增删改查。我在代码里注意到它对参数校验也有处理，实体类字段上使用@NotBlank、@NotNull等校验注解，Controller参数前加@Validated触发校验，校验失败的信息会被全局异常处理器捕获并返给前端，一整套流程串得很完整。

2.4 从实际需求理解购物车与订单的核心逻辑

购物车和订单，是整套系统业务逻辑密度最高的两块，值得逐行理解。

购物车的实现方案通常有两种：一种用Redis缓存，性能好但需要额外配置Redis；另一种存在数据库表中，使用cart表关联用户ID和商品ID，增加数量字段。这套代码考虑到“可直接运行”的需求，很务实地选择了数据库存储方案，毕竟对大多数课设场景，数据量不大，数据库方案完全够用且更容易让评委看懂。加入购物车时先查一下用户是否已添加过同一商品，如果已存在则数量加一，否则新增一条记录，这个逻辑避免重复数据很关键。

订单这块更有意思。下单时会生成订单编号，常见格式是时间戳加随机数或日期加用户ID的组合，比如20250104153000123456，这样能保证唯一性，也可以直接用数据库自增ID。一次下单可能包含多个不同商品，所以设计上拆成order主表和order_item子表，主表记录订单总金额、订单状态、收货信息、下单时间，子表记录每个商品的快照信息：商品名称、单价、数量、小计金额。把商品快照存进子表是电商系统的经典做法，因为商品价格和名称后续可能变化，但订单一旦生成，就必须忠实记录下单那一刻的信息。

订单状态通常用数字表示：0待支付、1已支付待发货、2已发货、3已完成、4已取消。用户在用户端可以取消待支付订单，管理员在管理端可以发货、完成订单。这种状态流转如果用if-else硬写，后期维护会非常痛苦，但课设阶段通常采用常量或枚举定义状态值，然后在Service层写更新状态的逻辑，理解起来会清晰很多。

3. 数据库设计与SQL脚本分析

3.1 核心表结构梳理

拿到SQL脚本后，我建议你先不要急着执行，而是用Navicat或Workbench打开看一遍表结构，从上到下理清楚这几十个字段之间的关系。这个项目的数据表数量一般在6到8张左右，核心无非这几张：user、category、product、cart、order、order_item，有的版本还有banner（轮播图）和address（收货地址）。

user表是用户基础信息表，包含username、password（通常是MD5加密存储）、nickname、avatar、phone、email、role（区分管理员和普通用户）、status（是否禁用）、create_time。这里有个安全意识要说一下：密码加密是课设项目中容易被忽略但答辩时可能被追问的点，MD5虽然不算安全，但比明文存储强很多，如果你学有余力可以改用BCrypt加盐加密，完全兼容这套项目的登录流程改造。

product商品表的字段设计很典型：product_name、product_subtitle（副标题）、category_id（关联分类表）、price（折扣价）、original_price（原价）、stock（库存）、sales（销量）、main_image（商品主图）、detail（富文本详情）、status（上下架状态）。关联分类表比直接在商品表里保存分类名称要规范得多，这样如果分类改名，只需要改分类表，不需要批量更新商品数据。

order订单表和order_item订单明细表上文已经提过，最关键的是它们之间的外键关联通过order_id字段关联，但数据库中未必一定建立物理外键。很多生产级别项目故意不建物理外键，而是在代码层面维护一致性，这样既保证了一定的灵活性，也避免了对性能的影响。课设阶段建不建外键都能讲出道理，关键是你得能回答上来为什么这么设计。

3.2 测试数据里的小心思

打开SQL文件的INSERT语句，你会发现里面的测试数据非常有讲究。管理员账号通常是admin/admin123，普通用户可能是user/123456，商品数据覆盖了水果商城的各个品类：苹果、香蕉、橙子、榴莲、车厘子、西瓜等，价格和库存都设置得比较合理，部分商品甚至配有真实的商品图片URL。

这些种子数据看着简单，但其实是从“能跑”到“好看”的关键一步。想象一下，如果你登录后台看到的是一片空白，很难判断是功能坏了还是真的没数据。而有了这些现成数据，前端页面一打开就是琳琅满目的商品列表，购物车和订单也能立刻演示起来，整个系统的演示效果立刻上一个台阶。

如果你打算在这个项目基础上做二次开发，我强烈建议你自己把种子数据替换一遍，改成你论文里需要的商品类别和名称。很多同学答辩翻车就是因为在演示时被老师发现商品名字还是源码默认的，一眼就露馅。替换数据不需要改代码，只要改SQL脚本里的INSERT语句，重新导入即可。

3.3 索引设计与SQL性能观察

虽然课设阶段数据量不大，很难出现性能问题，但在关键字段上建索引依然是值得做的好习惯，也方便你答辩时被问到优化问题时作答。user表的username字段应该建唯一索引，因为登录时要根据用户名查询；product表的category_id字段建普通索引，因为商品列表页要按分类筛选；order表的user_id字段建索引，因为用户查询“我的订单”场景很常见。

另一个值得看的小点，是日志中打印的SQL语句。SpringBoot配合MyBatis-Plus，在application.yml里设置mybatis-plus.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl后，控制台会打印每条执行的SQL。运行项目后，你可以在控制台观察到分页查询、条件查询这些SQL是怎么动态生成的。下次启用前端页面、触发一个商品搜索，再回头看控制台输出的SQL，你就对“持久层”有了很直观的感知。

4. 前端Vue工程与页面交互流程

4.1 前端目录结构与组件设计

Vue前端这块，一眼看过去是标准Vue CLI搭建的工程结构。node_modules存放依赖包，public放静态资源如index.html和网站Logo，src下面是核心源码。src/main.js是入口文件，负责创建Vue实例、挂载路由和状态管理、引入全局样式；src/App.vue是根组件，通常只放一个<router-view />，所有页面内容都根据路由动态渲染。

src/router/index.js文件里配置了所有页面路由，并设置了路由守卫。这个路由守卫是实现“登录后才能访问”的关键：router.beforeEach((to, from, next) => { ... })，在跳转前检查localStorage里是否存在Token，如果没有就跳转到登录页并带上redirect参数，方便登录成功后跳回原页面。如果你发现“明明登录了，但刷新页面后还是被踢回登录页”，大概率就是路由守卫那里的读取逻辑有问题，例如没有从localStorage读取或Token字段名不一致。

src/api目录下的文件是对Axios请求的二次封装，通常会创建一个request.js，设置baseURL（例如http://localhost:8080）、超时时间、请求拦截器（附加Token请求头）、响应拦截器（统一处理code非200的情况，例如登录失效时跳转登录页）。每个业务模块再单独建文件，如user.js放登录注册接口，product.js放商品列表和详情接口，order.js放下单和订单查询接口。这种按模块组织API的方式，是Vue项目中非常推荐的工程化实践，后续维护接口时不需要在几十个页面里搜索请求代码。

4.2 用户端核心页面拆解

用户端页面通常包括首页、商品分类页、商品详情页、购物车页、结算页、订单列表页、个人中心页。

首页往往是“门面担当”，设计上会花最多心思：顶部导航栏（Logo、搜索框、购物车入口、用户信息）、轮播图banner、商品分类快捷入口、热销商品列表。数据请求通常在created生命周期钩子里发起，调用API函数，把响应数据存到data或Vuex中，模板部分通过v-for循环渲染商品卡片。

商品详情页是一个动态路由页面，路由配置类似path: '/product/:id'，组件内通过this.$route.params.id获取商品ID，再调用商品详情接口。页面核心信息是主图、标题、价格、库存、购买数量选择器、加入购物车和立即购买按钮。加入购物车成功后通常用this.$message.success弹窗提示，这个交互反馈很重要，没有的话用户点按钮会以为没反应。

购物车页和结算页是交互密集型页面。购物车列表有勾选框控制选中商品，页面底部实时计算总价，全选、单选、数量加减、删除商品，每一个操作都会触发重新计算。结算页一般让用户选择收货地址、确认商品清单、填写备注，最后点“提交订单”按钮，前端就把要买的商品数据通过POST请求发给后端，成功后跳转到订单列表或支付模拟页。这套交互流程在“前端展示与用户操作反馈”这部分是很典型的案例，值得逐行阅读源码理解数据的流向。

4.3 管理后台权限控制与菜单渲染逻辑

管理后台是另一套独立的路由和页面布局。通常路径带/admin前缀，菜单项包括仪表盘、用户管理、商品管理、分类管理、订单管理等。

权限控制方面，前端路由会区分用户端路由和管理端路由，前端在路由守卫里检查当前登录用户的role字段，如果非管理员则不能进入任何/admin开头的页面。后端配合这个逻辑，管理员接口在拦截器或注解层面校验权限，双重防护。这里的思路非常清晰：前端限制只是为了用户体验，真正的安全性必须由后端保证，因为API是可以被直接调用的。

后台商品管理页面是一个典型的“表格+表单弹窗”组合：页面顶部是搜索栏（支持按商品名称关键词搜索），中间是el-table展示商品列表，最后一列是操作按钮（编辑、上下架、删除）。点击“新增商品”按钮则弹出一个el-dialog表单，里面各表单组件分别对应商品表的各个字段，上传图片组件会先把图片上传到服务器（或直接填图片地址），提交时把整个表单数据POST给后端。

4.4 Axios封装与跨域调试经验

在前面提到request.js是Axios二次封装的核心，这里展开说一个实际开发中一定会遇到的痛点：跨域问题。前端开发服务器一般是http://localhost:8081（或8080），后端是http://localhost:8080，虽然端口只差一位，但浏览器的同源策略会直接拦住请求。

解决跨域的方式主要有两种：第一种是后端开启CORS，在SpringBoot中通过WebMvcConfigurer添加CorsRegistry，允许指定来源或所有来源访问；第二种是前端通过Vue CLI的devServer.proxy配置代理，把前端的/api请求转发到http://localhost:8080，这样浏览器的请求看起来是同源的，就不会报跨域错误。

这套项目使用的是哪种方式不重要，重要的是你要理解：如果你启动后能看到页面但所有数据都是空的，打开F12的Console看到诸如Access-Control-Allow-Origin的错误，那十有八九就是跨域没配好。我在后面的常见问题部分还会展开写排查步骤。

5. 本地运行完整实操指南

5.1 环境准备：JDK、Maven、Node、MySQL版本怎么选

再三强调，环境版本是“可直接运行”的第一道门槛。根据这套项目的技术栈，我对推荐版本做了一个整理，跟着来可以少踩很多坑。

具体到这套源码，如果它是基于SpringBoot 2.4左右版本写的，JDK 8完全没问题，MySQL 5.7和8.0都能连。但如果源码基于SpringBoot 3.x，那就必须用JDK 17以上，MySQL驱动也要换新的。拿到项目后先打开pom.xml看一眼spring-boot-starter-parent的版本号，再确定JDK版本。

Node版本不要太新，我试过用Node 18配Vue CLI 4会报OpenSSL错误（经典的ERR_OSSL_EVP_UNSUPPORTED），解决方案是升级Vue CLI或降低Node版本。为了避免这种问题，建议直接Node 16稳妥起步。

5.2 初始化数据库：SQL脚本导入与账号配置

第一步，把源码包里sql或db目录下的SQL文件（通常叫fruit_shop.sql或piaoxiang.sql）用Navicat或命令行导入。打开Navicat，新建连接，输入MySQL的用户名密码（默认root/root或root/123456，具体看源码文档），右键新建数据库，名称建议与脚本内的库名保持一致，比如piaoxiang_fruit，字符集选utf8mb4，排序规则选utf8mb4_general_ci或utf8mb4_unicode_ci。

选中新创建的数据库，右键“运行SQL文件”，选择那个sql文件，执行完成后刷新表列表，如果看到那七八张表，说明导入成功。这时候建议先双击每张表看一看数据，确认不是空表。

第二步，修改后端数据库连接配置。在application.yml里找到这一段，改成你自己的账号和密码：

spring: datasource: url: jdbc:mysql://localhost:3306/piaoxiang_fruit?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver

关于连接串，有几个参数值得说明：useUnicode=true&characterEncoding=utf-8解决中文乱码；useSSL=false避免MySQL 8.0的SSL警告；serverTimezone=Asia/Shanghai解决时区报错，MySQL 8.0如果没配时区就会报The server time zone value的异常。

5.3 启动后端：从Maven导入到控制台运行

后端启动的常规操作是用IDEA打开后端文件夹，等待Maven自动下载依赖。这一步可能比较耗时，取决于网速和Maven仓库配置。我第一次导入时等了将近十分钟，如果你的网络不太顺畅，强烈建议在IDEA的Maven配置里设置阿里云镜像：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

依赖下载完成后，在IDEA右侧Maven面板执行clean和install，然后找到启动类，比如FruitShopApplication.java，右键“Run”。看到Console里出现Started FruitShopApplication in x.xxx seconds和Tomcat started on port(s): 8080字样，说明后端启动成功。

这时可以先用浏览器或Postman测试一个接口，例如访问http://localhost:8080/api/product/list（具体路径以源码为准），返回JSON数据就说明后端没问题。控制台如果打印出了SQL语句，说明数据库连接和MyBatis-Plus配置都是通的。

5.4 启动前端：npm依赖安装与页面访问

前端启动相对容易踩坑，主要坑在依赖安装这一步。打开终端，进入前端目录，先执行依赖安装命令。由于默认npm源在国内速度较慢，建议先切换成淘宝镜像：

npm config set registry https://registry.npmmirror.com npm install

npm install执行时间取决于依赖数量和机器性能，有时候会因网络问题中断，重试即可。如果执行过程中报node-sass相关的错，那基本就是Node版本不对，建议改用Node 16，或者把依赖里的node-sass替换成sass再重新安装。

依赖安装完成后，执行启动命令：

npm run serve

看到App running at: Local: http://localhost:8081/说明启动成功，浏览器访问这个地址，就能看到商城首页了。如果你的后端端口是8080，前端是8081，那么此前配置的跨域或代理设置就派上了用场。正常访问后，用SQL脚本里的管理员账号登录后台，用普通用户账号登录用户端，把购物、下单、发货全流程走一遍，这个项目就算真正“跑通”了。

5.5 线上部署的思路与注意点（加分项）

课设如果能做到本地运行，通常已经满足基本要求，但如果想拿高分，可以顺便提一句如何部署到云服务器。打包后端时，在项目根目录执行mvn clean package -DskipTests，会生成一个jar包；前端执行npm run build，会把所有静态文件打包到dist目录，这个目录可以直接交给Nginx托管。Nginx配置里的proxy_pass负责把/api开头的请求转发到后端端口，再配合一个域名和HTTPS证书，就是一个标准的线上前后端分离部署方案。

部署这种话题在答辩时很容易延展，但如果你只是课设，不建议实际操作，因为服务器还要额外花钱，而且部署过程本身坑也不少。知道原理、能说出关键步骤就够了。

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

6.1 前端页面能打开，但所有数据都是空的

这个问题的出现频率非常高，几乎每个第一次启动前后端分离项目的同学都会遇到。排查思路要按顺序走：第一步，打开浏览器F12开发者工具，切到Network标签栏，刷新页面，看请求列表里有没有红色状态（4xx或5xx）。第二步，看请求是不是打到后端正确端口了，如果你后端在8080，但请求显示的是8081，那肯定是代理或baseURL配置不对。第三步，看响应内容，如果提示CORS跨域错误，说明后端没有开启跨域支持；如果响应404，说明路径不对；如果响应500，要看后端控制台的错误日志。

这里有一种情况特别迷惑：后端启动成功了，但数据库没导入或有改动导致SQL查询报错，前端会拿到500状态码，但页面上一片空白，看不到任何错误提示。所以我一般建议“先测后端，再连前端”，确保http://localhost:8080/api/product/list能直接返回数据后，再去排查前端。

6.2 后端报错：端口被占用怎么办

SpringBoot默认端口是8080，如果你本机已经运行了其他占用8080的服务，比如另一个Java进程、Tomcat、或某些中间件，那启动时就会看到Port 8080 was already in use的报错。解决办法有两种：一是找到占用进程并结束它；二是直接改端口，在application.yml里设置server.port: 8088，改了之后记得前端代理或axios的baseURL也要同步修改。

在Windows下查找端口占用，推荐使用一行命令解决：

netstat -ano | findstr :8080

找到占用8080端口的进程PID后，再执行：

taskkill /PID 对应PID /F

在Mac或Linux下是lsof -i :8080找到PID，再用kill -9 对应PID杀掉。

6.3 数据库连接失败，提示Access denied或Unknown database

这类报错基本都指向两个文件：application.yml里的数据库账号密码，以及SQL导入时创建的库名。Access denied for user 'root'@'localhost'说明用户名或密码不对，去确认你的MySQL安装时设置的root密码，这里有一个小坑：很多同学安装MySQL时随手设的密码，过了一周自己都忘了，建议用Navicat测试连接能通之后再启动项目。

Unknown database 'xxx'说明配置里的库名和实际导入的库名不一致。要么把SQL重新导入到配置指定的库名里，要么把配置改成实际库名，两者对齐即可。

另一个数据库相关但更隐蔽的是Public Key Retrieval is not allowed，这是MySQL 8.0的认证机制导致的问题，在连接串后面加allowPublicKeyRetrieval=true即可解决。

6.4 npm install成功但npm run serve报错

依赖安装了仍然启动失败，大多是版本兼容问题。最典型的是前面提到的ERR_OSSL_EVP_UNSUPPORTED，原因是新版Node（17以上）不再支持旧版Webpack使用的md4哈希算法。解决方案有三选一：

• 推荐：把Node版本降到16.x或14.x，用nvm管理Node版本最方便。
• 在package.json的scripts里把"serve": "vue-cli-service serve"改成"serve": "set NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service serve"，Windows下有效。
• 升级Vue CLI和相关依赖，但升级可能引发其他连锁问题，不太推荐课设阶段折腾。

另一个高频报错是Module not found: Error: Can't resolve 'xxx'，通常是某个依赖没有安装成功，删除node_modules目录和package-lock.json文件后重新npm install，再启动基本就能恢复。

6.5 订单提交总是不成功，看了日志才知道原因

我在测试这套项目时遇到过一种情况：用户端下单时报错“库存不足”，但前端明明显示商品是有库存的。查了后端日志才发现，商品在数据库里的实际库存字段值是0，前端页面显示的数据是缓存的或者卖家忘了更新库存。这个问题的根源不是代码bug，而是业务数据问题，但也说明前端显示和后端校验之间存在时间差。

类似这种和业务状态相关的问题，在排查时一定要学会看后端日志。SpringBoot的日志里会打印异常堆栈和SQL语句，很多问题的答案其实都写在堆栈里。比如某个字段为空报空指针、某条SQL执行失败报SQL语法错误，都能通过日志里的信息直接定位到具体代码行。遇到报错不要急，先把异常信息完整复制下来，搜索一下关键报错字段，十有八九能找到解决方案。

写在最后的个人体会

这套“飘香水果购物网站”源码，我前前后后跑了三遍，第一遍按部就班走通，第二遍断点调试了核心接口，第三遍把前端页面和后端代码对照着读完。整体感受是：它不是一个花哨炫技的项目，但它的“标准”和“完整”恰恰就是最大的优点。对于准备找Java开发实习或参加校招的同学来说，在简历上写“熟悉前后端分离开发流程，能够独立完成电商系统模块设计与实现”，如果背后没有一套真正跑通的项目撑着，面试官一问细节就会露馅。

我的建议是，拿到源码跑通之后，一定要自己动手改几个地方。比如给商品表加一个“产地”字段，让前端页面能展示产地标签；比如给订单列表加一个按时间筛选的功能；比如把登录从简单的token改成带过期时间的token。这些改动都能让你真正理解这套代码的来龙去脉。等到答辩或面试时，你能讲清楚的不只是“我用了SpringBoot和Vue”，而是“为什么订单表要拆成主表和明细表”“为什么购物车不在前端存而是存后端数据库”“为什么前端路由守卫不能替代后端权限校验”，这才是一套源码带给你最值钱的东西。

最后再分享一个小技巧：如果你打算拿这套代码参加课程设计答辩，提前把管理员后台上传的商品主图换成本地图片，不要在答辩现场依赖外部图片链接。很多公开授课或演示翻车都发生在网络不好、图片全部加载失败的时候，这种细节平时看不出来，关键时刻却是致命的。