SpringBoot+Vue做手机销售网站，属于Java Web毕设里非常经典的前后端分离项目。说句实在话，这类项目在GitHub和码云上一抓一大把，但大多数学生下载下来之后根本跑不起来——不是缺这个配置就是少那个依赖，更别提把数据库脚本导进去之后一堆外键报错。我前前后后帮人排查过几十个这种项目，今天就把一个能真正跑通的完整方案拆开揉碎了讲清楚。
这个项目涉及的核心内容有这么几块：SpringBoot后端接口、Vue前端页面、MySQL数据库脚本、接口文档。对于做毕设的学生来说，你需要的不只是一个能点来点去的Demo，而是一套能讲清楚"为什么这么设计"的完整逻辑。我这篇文章就按照实际开发顺序来拆解，包含技术选型、数据库设计、接口实现、前后端联调、部署上线，以及那些最容易让你在答辩时翻车的隐藏坑。
1. 先搞清楚手机销售网站到底需要哪些功能模块
很多同学拿到题目就懵了，手机销售网站，那不就是个商品列表加购物车吗？真这么做下去，到答辩的时候你会发现根本没东西可讲。一个合格的手机销售网站，在毕设层面至少要覆盖前台展示和后台管理两个大方向，功能拆解下来大概是这样的。
前台用户端主要面向普通消费者。用户注册登录是基础，然后就是手机商品的浏览和筛选。这里有个关键点，手机和普通商品不一样，它有品牌、操作系统（Android还是iOS）、运行内存、存储容量、屏幕尺寸、电池容量这些细分属性。所以搜索筛选功能不能只做一个简单的关键字匹配，而是要支持多维度的组合筛选，比如同时按"华为"和"8GB运存"来过滤。
购物车和订单系统是交易闭环的核心。用户把手机加入购物车之后，要能修改数量、删除商品、计算总价，提交订单时还得填写收货地址。这里牵扯出一个毕设里很关键的考察点：库存扣减。很多同学用的是先下单再减库存，甚至干脆不处理，这在高并发场景下会有超卖风险。毕设做单体应用，可以用数据库的行级锁或者乐观锁来处理，但关键是你得能把这个逻辑讲清楚。
后台管理端则是给管理员用的。商品的增删改查是必须的，包括手机的名称、价格、库存、图片、详细介绍这些字段。另外品牌管理和分类管理可以单独做一张表，方便前台按品牌筛选。订单管理要能查看所有订单列表、修改订单状态（待付款、待发货、已发货、已完成、已取消）。用户管理一般就是查看用户列表和启用禁用账号。
这里我建议加一个数据可视化看板，虽然会增加工作量，但这是答辩时的加分项。用ECharts做几个图表放在首页——比如按月统计销售额的折线图、各品牌手机销量占比的饼图、库存不足预警的列表。这能直接证明你对业务数据的理解，而且实现起来也不复杂，就是查几张表做聚合统计。
需要注意的是，功能模块的划分最好在文档和数据库设计阶段就定下来，不要边写代码边加功能。我见过太多同学后面改表结构改到崩溃，因为前端页面、后端接口、数据库字段三处是关联的，牵一发而动全身。
2. 技术选型不是越新越好，关键看稳定和匹配
先说说后端。SpringBoot的版本这里有个容易踩的坑。很多学生下载项目的时候习惯去Maven仓库拉最新版，比如SpringBoot 3.x，结果发现JDK版本要17以上，之前写的代码里很多写法要调整，还有一些老版本的依赖不兼容，直接原地爆炸。
毕设项目，我强烈建议用SpringBoot 2.7.x系列。这个版本非常成熟，网上资料最多，遇到问题搜一下基本都能找到解决方案。它默认兼容JDK 8，而大多数学校机房和企业里用的还是JDK 8，你在答辩演示的时候环境不会出问题。如果已经下载的Demo是SpringBoot 3.x，优先考虑整体替换回2.7.x，而不是去适配新版本。
持久层框架，推荐MyBatis-Plus而不是原生MyBatis。我们做毕设，主要是把精力放在业务逻辑上，MyBatis-Plus的通用Mapper能自动帮我们生成单表的增删改查SQL，避免写大量重复的XML文件。它提供的分页插件也比较好用，Web层配合前端的分页组件，代码量少一大截。
前端这块，Vue版本选择也讲究。Vue 2和Element UI的搭配是最成熟稳妥的，组件全，坑少，网上的案例也多。Vue 3搭配Element Plus也可以，API更现代，但如果你对Vue还不熟，建议用Vue 2。另外，前端构建工具、状态管理这些，如果时间紧张可以选轻量方案，用Vuex，组件通信传参处理简单需求就够了。
前端UI框架，Element UI算是最常用的。表格、表单、弹窗、分页这些核心组件都有，而且美观度在后台管理系统中足够用了。如果是自己做前台用户界面，手机销售这类面向消费者的页面，Element UI风格会显得稍微偏后台，但毕设阶段完全可以接受。你可以在确认功能完整的前提下，想着把视觉优化一下，比如设计和交互做得更有质感一些。
最后说数据库。MySQL 5.7或者8.0都可以，如果你是学习用途，建议8.0，反正市面上绝大多数项目都支持。有一点要提醒：MySQL 8.0默认的认证插件是caching_sha2_password，有些旧版本的数据库连接工具连接不上，但我们在SpringBoot里用的mysql-connector-java驱动，8.0以上的版本已经兼容了，所以问题不大。连接数据库的时候注意时区配置，在JDBC连接地址后面加上serverTimezone=Asia/Shanghai，不然会有8小时时差问题。
3. 数据库表设计直接决定开发效率和答辩分数
手机销售网站的数据库表说复杂也复杂，说简单也简单，但有几个设计原则你最好遵守，这决定了后面写代码的时候是顺手还是别扭。
核心表就这些：用户表（sys_user）、手机商品表（phone）、品牌表（brand）、购物车表（cart）、订单表（orders）、订单明细表（order_item）、轮播图表（banner）、收货地址表（address）。
先看用户表，核心字段是用户名、密码、昵称、手机号、头像、角色标识。角色这里需要多说一句，虽然我们不搞复杂的权限框架，但管理员和普通用户肯定要区分。可以用role字段，值为1表示管理员，值为0表示普通用户。这样前端登录后可以根据角色决定显示哪些菜单，后端也可以在拦截器里根据角色做接口访问限制。还有密码存储，千万不要明文存放。比较简单的做法是用MD5加盐，或者用Spring Security的BCryptPasswordEncoder。如果项目里没接Security，自己写MD5加盐工具类也行，但答辩的时候要能说出这样做的理由。
手机商品表是业务的重心。字段包括手机名称、品牌ID、价格、原价、库存、销量、主图URL、详情图URL列表、操作系统、运行内存、存储容量、屏幕尺寸、电池容量、处理器型号、上市时间、上下架状态。注意品牌ID是外键关联品牌表的，这样你按品牌筛选的时候直接查这个字段就行。价格字段推荐用DECIMAL(10, 2)类型，不要用FLOAT或DOUBLE，不然会出现浮点数精度问题。
订单表要设计好状态字段。用一个status字段存储订单状态，后台管理系统里常见的状态机是：0待付款，1待发货，2待收货，3已完成，4已取消。前端根据状态码显示对应的按钮。订单表和订单明细表是一对多的关系，一个订单里有多个商品条目。设计订单明细表时，除了商品名称和数量，最好把下单那一刻的商品快照价格也存下来，因为商品价格后来可能会改，历史订单要保留下单时的价格。
购物车表比较简单，字段是用户ID、商品ID、商品数量，加上创建和更新时间就行了。一个用户往购物车添加商品时，如果这个商品已经在购物车里了，就直接把数量加一而不是新增一条记录。
轮播图表主要记录图片URL、跳转链接、排序权重，前台首页展示时按权重排序。
还有一个常见问题需要提醒：到底要不要设置外键约束。很多教程项目为了演示方便都加外键，但实际开发中大型项目基本都取消物理外键，只在逻辑上保持关联。毕设的话，建表脚本里保留外键是可以的，答辩时说是为了数据一致性，但如果你应用层代码写得不好，很容易因为外键约束导致删除操作失败。稳妥的方案是建议你放弃物理外键，在SQL层面通过索引和关联查询来保证逻辑正确。MySQL执行脚本时，记得把DROP TABLE IF EXISTS放在每个建表语句前面，这样脚本重复执行不会报错。
4. 后端接口不是写完就行，你要懂这几个核心设计
接口设计这块，我不想把所有接口名单列一遍，那没意义。我只讲几个最容易出问题、也最能在答辩时体现出你水平的地方。
先说接口规范。既然是前后端分离，统一返回格式是必须的。建议定义一个Result类，包含code、message、data三个字段。接口成功时code为200，失败时code为500，未登录时code为401，无权限时code为403。前端拿到响应后，只要判断code是否为200，为200就正常渲染数据，否则弹出message提示。这个规范从始至终要保持一致，否则前后端联调的时候会非常痛苦。
用户登录鉴权是重点。毕设项目可以做基于Token的认证，简单方案是登录成功后生成一个UUID作为Token，存到Redis里，设置过期时间，返回给前端。前端每次请求都在Header里带上token字段，后端写一个拦截器，在业务代码执行前校验Token，校验通过就放行，不通过就返回401。这么做的好处是能够横向扩展，Session存在服务器内存里的话会有很多麻烦。当然，如果你不想引入Redis，用JWT也可以，把用户信息加密放到Token里，后端用密钥解密验证。
商品列表接口的设计要讲究一点。手机销售网站的前台页面一般有两种展示模式：一种是搜索加分类筛选，另一种是上下拉无限加载。接口其实可以统一成一个，通过请求参数来控制。建议参数有：page（页码）、limit（每页条数）、keyword（关键字搜索）、brandId（品牌筛选）、osType（操作系统筛选）、minPrice和maxPrice（价格区间）、sortBy（排序字段，可以是价格、销量、上架时间）。后端用MyBatis-Plus的分页插件处理，条件构造器动态拼接SQL条件。这个接口写明白之后，前台的搜索、筛选功能基本就全通了。
订单提交这块，一定要处理事务。一个完整的下单流程，要往订单表插记录，往订单明细表批量插记录，要扣减商品库存，要清空购物车里对应的商品。任何一步失败，那么整体的操作就应该回滚，这叫要么全部成功，要么全部失败。在SpringBoot里，只需要在Service层方法上加@Transactional注解就行。还有一个小问题：下单时要锁定库存，减少并发超卖，可以在事务里对商品行加SELECT ... FOR UPDATE锁，前提是事务里要包含查询库存和更新库存两步骤。
支付功能要看你的时间预算。如果只是想顺利毕业，做一个模拟支付接口就够了。用户在付款页面点确认支付，后端直接把订单状态从待付款改成待发货，在前端提示支付成功。如果你想做得精致点，可以在订单表加一个支付时间字段，模拟一下回调逻辑。千万不要为了追求真实支付功能去对接支付宝、微信支付的沙箱环境，那会占用你大量时间，而且答辩考察的重点也不在支付对接上。
这里分享一个我帮学生改代码时常见的低级错误：很多同学在写查询列表接口时，没有处理参数为空的情况。比如brandId没传，你可以对条件构造器的条件进行非空判断，让它加到查询条件里去。MyBatis-Plus条件构造器里用
StringUtils.hasText()或者判断对象不为空后再eq关联。
5. 前后端联调时那些让你怀疑人生的细节
前后端分离的项目，联调阶段是最折磨人的。前端在本地跑dev服务器，后端跑在8080端口，跨域问题第一个跳出来。
解决跨域有几种办法，推荐用SpringBoot的全局CORS配置。写一个配置类，实现WebMvcConfigurer接口，重写addCorsMappings方法，设置允许的跨域来源、请求头和方法。要注意的是，如果前端请求带了Token之类自定义Header，allowedHeaders里要写上。设置SpringBoot应用启动的端口和上下文路径，需要在前端代理配置文件里同步改，vue.config.js里配置devServer的代理转发，这样前端请求/api开头的地址，就会被代理到后端的localhost:8080/api上。
前后端接口字段对不上也是联调时的一大坑。前端要的是createTime，你后端返回的却是create_time。这个问题在MyBatis里尤其容易出现。使用MyBatis-Plus时，全局配置里开启驼峰命名映射，那么数据库的create_time字段就能自动映射为实体的createTime属性。前端拿到的是规范的驼峰字段，就不会对不上了。
调试接口时，我推荐两个工具。一个是Postman，后端自己测接口的时候用；另一个是浏览器的开发者工具Network面板，前端联调时看请求和响应数据。学会看请求的URL、Header、Request Payload和响应体，大部分接口问题能定位到原因。
分页这块在前后端联调时也容易出差错。前端组件传的pageNum和pageSize，后端接口的参数名必须一致才能接收到。干脆统一一下：前端传page和limit，后端就按page和limit来接收。返回的数据结构也要约定好，建议是{records: [...], total: 100, current: 1, size: 10}，前端拿到records渲染列表，拿到total算总页数。
6. 我的建议：从下载源码到成功跑通的完整步骤
如果你手里已经有一套SpringBoot+Vue的手机销售网站源码，但就是跑不起来，我建议你按顺序做，不要乱试。
第一步，检查JDK版本。项目和你的本地环境版本匹配，否则编译报一堆奇怪的错误。使用Maven的，项目导入IDE后，更新一下Maven配置，把依赖下载完整。
第二步，配置数据库。打开application.yml（或properties文件），检查数据源配置。确认MySQL的账号密码、端口号对不对。然后用Navicat或命令行执行SQL脚本，执行完确认核心表已经创建出来了。
第三步，改Redis配置。如果项目用了Redis，确认本地装了Redis，服务启动了。SpringBoot连接Redis的配置在配置文件里，默认是localhost:6379，密码为空。如果你本地没装Redis而项目里又必须用，可以临时修改代码把缓存相关功能去掉，但不建议这么做，因为会牵连登录鉴权逻辑。
第四步，启动SpringBoot后端。查看控制台有没有报错信息，是否出现Started Application in x.xxx seconds，说明启动成功。此时打开浏览器访问localhost:8080效果看情况，如果接口路径配置合理可以测试接口。
第五步，启动Vue前端。进入前端目录，执行npm install安装依赖，这个过程可能比较久，耐心等待。安装完成后再执行npm run serve。这里有个比较常见的坑是npm install过程中报node-sass安装失败。新版项目一般用dart-sass，问题不大。如果你遇到的是node-sass，上网搜一下对应版本的兼容性，或者让Node版本降级。
第六步，登录验证。前端启动后，打开浏览器看到登录页就对了。用管理员的账号密码登录进去，看看能不能打开后台管理页面，商品管理能否正常增删改查，数据能渲染出来，就说明整个链路是通的。
7. 部署上线的正确姿势和那些隐藏的系统配置
很多学校毕设要求最后要能演示，本地跑通可能还不够，有的老师会要求部署到服务器上。这里介绍一个最稳妥、最省事的方式：用宝塔面板部署。
买一台云服务器，装好宝塔面板之后，我们需要做这些事：安装MySQL和Redis（如果项目用了），安装Nginx，安装JDK和Maven。然后借助宝塔面板上传项目代码，或者直接在服务器上用Git拉取代码。
后端的部署，使用Maven打包成可执行的JAR文件。在项目根目录执行mvn clean package -DskipTests，它会在target目录下生成一个JAR包。在宝塔的网站管理里添加一个Java项目，上传JAR包，把启动命令配好。启动命令里也可以指定端口，或者直接用配置文件里的server.port。后端部署成功之后，服务器的防火墙或安全组要把对应的端口放行，否则外部访问不到。
前端的部署，需要先构建静态文件。在Vue项目目录执行npm run build，生成dist目录。把dist目录里的文件上传到Nginx的站点根目录。然后在Nginx的配置里设置反向代理：当用户访问/api路径时，将请求转发到后端服务器的地址。记住，前端部署在80端口，后端跑在8080，如果不配置反向代理，前端页面里所有请求都会404，但这不影响本地的8080端口访问，所以本地与部署是有差异的。
数据库的初始化与迁移，生产环境执行一遍SQL脚本，脚本是能重复执行的，但要注意初始化数据的幂等性。如果有用到Redis，注意给Redis设置密码或用访问控制，否则会有安全风险。
部署过程确实繁琐，但完成后把访问地址发给老师，打开就能看到我们的项目，这会给老师留下好的印象。很多同学到了答辩前才开始部署，结果手忙脚乱。我建议至少提前一周把服务器环境搭好，先本地跑通，再试着部署一遍，时间充裕很多。
8. 接口文档怎么写才能加分
接口文档这也是毕设的验收材料之一，很多同学随便列个表格就交了，其实这块做得好很能加分。
我的建议是用Swagger生成在线接口文档。SpringBoot集成Swagger非常简单，加几个依赖，在启动类上加@EnableOpenApi注解，再在Controller的接口上加上@Api和@ApiOperation注解描述方法和参数。启动项目之后，访问localhost:8080/swagger-ui/index.html就能看到清晰的接口列表。每个接口的请求方式、请求参数、响应结构都能实时调试。这比手写一份几十页的Word文档要直观得多，而且改动代码后文档会自动同步更新。
如果你不想引入Swagger，那至少要做一个规范的Markdown文档。按照模块来划分：用户模块、商品模块、购物车模块、订单模块、统计分析模块。每个接口列清楚URL、请求方式、请求参数表格（名字、类型、是否必填、说明）、返回结果示例。注意写清楚返回结果的JSON示例，前端同事照着写代码。
这里分享一个我常见的文档坑：接口文档里所有参数都写了必填，但实际后端代码里有些参数允许为空。前端严格按照文档传参时发现，有些筛选条件不需要或者可选，容易产生误解。写文档的时候要把每个参数的校验逻辑写清楚，比如"该参数可选，不传则查询全部品牌"。这样前后端沟通起来省很多事。
9. 最终检查和答辩前的准备，别在最后一步翻车
检查代码规范。Controller层的接口参数统一用自定义的请求对象去接收，不要直接散落一堆RequestParam参数在方法签名上。Service层负责业务逻辑，Controller层尽量只做参数接收和结果返回。Repository层承接ORM操作。这样的三层架构，答辩的时候画一张架构图，基本就清晰展示了项目的设计能力。
重新梳理项目的核心流程和关键点。答辩前准备一个项目技术亮点清单，重点能讲清楚：项目采用前后端分离架构，后端使用SpringBoot，数据库采用MySQL；登录鉴权使用Token机制，保证接口安全；订单模块用事务机制保证数据一致性；商品查询支持多维度筛选和分页；使用数据可视化图表展示销售数据。每一点都能展开讲一两分钟，已经非常充足了，比背代码更能展示你的思考。
再检查一遍项目里有没有硬编码的问题。数据库连接密码、Redis密码不要明文出现在代码里，最好放到配置文件里，甚至可以考虑用环境变量。如果你用的是从网上下载的Demo，注意修改包名和项目名，不要直接拿别人的包名去答辩，老师一查就露馅。
最后，建议把项目从零搭建过程中踩过的坑整理成一份简短的开发日志。这不需要给老师看，但答辩时如果被追问"项目里遇到过什么问题"，你就能从自己的经历里挑出来。这种真实经验比背出来的答案更打动老师，也是我当年通过答辩的重要心得。
手机销售网站这个题目本身不算难，难的是你有没有把一个完整项目做深做透。技术不在多，在于你能否把每个环节的逻辑讲清楚。你把这个项目的数据库设计、接口规范、权限方案、事务一致性这几个问题搞明白了，答辩的时候就能掌握主动权。
