最近把之前写的一个基于SpringBoot+Vue的数码产品购物商城完整跑通了，从数据库建表到前后端联调，再到部署到云服务器，走了不少弯路。这个项目本身不算特别复杂，但因为它涵盖了一个电商系统最核心的链路——用户注册登录、商品展示与搜索、购物车、订单、模拟支付，加上数码产品本身对参数、库存、价格变化比较敏感，做起来比普通的管理系统更有意思，也更容易在面试或答辩时展开讲。
这篇文章不打算贴完整源码，那太长也没意义。我更想聊聊整个项目从设计到落地的过程中，那些真正影响进度和成败的地方。比如为什么用SpringBoot+Vue的组合，版本怎么选，商品模块的数据库怎么设计，用户认证怎么处理才不会在前后端联调时扯皮，Redis在里面到底起了什么作用，还有我在部署阶段遇到的那些坑。给正在做类似毕业设计或想自己练手商城项目的朋友一个参考。
1. 数码购物商城的技术选型：为什么最终锁定SpringBoot+Vue
1.1 为什么商城项目需要前后端分离
现在一说到商城系统，几乎默认就是前后端分离。跟传统的JSP+Servlet那套老做法相比，分离的好处不是“潮流”，而是开发节奏和后期维护确实不一样。
我这个项目里，前端负责页面渲染和用户交互，后端只提供JSON接口，两边可以同时开工。我在实际开发中深有体会：先把后端的接口定义写清楚，前端同学或用Postman调试的人就可以按着接口文档走，不用等页面套好壳再去联调。对于一个人开发的项目，分离还有个好处是，代码结构清晰，哪里出了问题一眼就能定位，不会像老式项目那样前端HTML里混着一堆Java代码。
另外，部署的时候也可以把前端打包成静态文件扔到Nginx，后端单独跑在SpringBoot的内嵌Tomcat里，互不干扰，压力分摊更合理。
1.2 SpringBoot 3.x还是2.x，版本选择背后的逻辑
搜过SpringBoot相关热搜的朋友应该都看过“springboot版本太高”这个梗。很多教程写的是2.x，但你去Spring官网一打开，默认已经是3.x了。版本不同，坑完全不一样。
SpringBoot 3.x基于Java 17，不再兼容javax.*包，而是用jakarta.*包名。这意味着不少老教程里的import javax.servlet直接报红。如果你用了某些比较老的第三方依赖，比如旧版的MyBatis、druid、pagehelper，也可能会因为字节码版本或包名兼容问题导致启动失败。
我这个项目最终选了SpringBoot 2.7.x，理由很简单：稳定，兼容性强，资料多。很多毕业设计和公司老项目都还是2.x，遇到问题搜索的时候基本都能找到答案。如果你非要用3.x，也不是不行，但要做好折腾依赖的心理准备。我的建议是：
- 如果是从零开始做项目，且不需要很新的特性，选2.7.x最稳。
- 如果喜欢新技术，愿意处理兼容问题，选3.x，但MyBatis-Plus等依赖也要选适配SpringBoot3的版本，比如MyBatis-Plus 3.5.3+。
1.3 从Maven依赖到Vue脚手架：第一天就踩的坑
我一开始建SpringBoot项目，用的是IDEA自带的Spring Initializr，选了一堆依赖，结果启动直接报错。后来发现是SpringBoot的版本和Java版本不匹配导致的编译问题。新版IDEA默认的SpringBoot版本可能比较高，如果你的本地JDK是1.8，那就必须手动把SpringBoot版本调到2.7.x，否则启动类直接起不来。
这个坑很基础，但真的很影响初学者心态。建议建项目前先检查：
- JDK版本：用
java -version看； - Maven仓库：最好配阿里云镜像，否则下载依赖能等到天荒地老；
- 打包方式：jar包即可，不需要war包，因为我们是前后端分离，不需要丢进外部Tomcat。
前端我用的Vue 2 + Element UI。有些人可能问为什么不用Vue 3+Vite？我当时是因为这套技术栈更熟悉，而且网上关于Vue 2 + SpringBoot的商城案例非常多，遇到问题容易找答案。等这个项目做熟了再升级到Vue 3也不难，核心的组件通信、路由、状态管理思路是一样的。
2. 商城核心模块设计：从商品浏览到订单支付的完整链路
2.1 商品模块：数码产品的参数、主图和库存拆分
数码产品和衣服、食品不一样，它有几个明显特点：参数复杂、价格高、更新换代快。所以商品模块在设计时不能只搞一张商品表了事。
我设计了四张核心表：
product：商品主表，存商品名称、副标题、主图、价格、品牌、分类ID、上下架状态、销量等公共字段。product_param：商品参数表，用来存数码产品的具体规格，比如手机的内存、屏幕尺寸、电池容量。之所以不把参数直接写在主表里，是因为不同类别数码产品的参数差异太大，如果用一张表硬存，要么字段不够用，要么一堆字段都是空的。product_image：商品轮播图表，一个商品存多张图片，做详情页轮播。product_category：商品分类表，支持两级分类，比如“手机通讯”下面分“智能手机”、“老人机”。
在设计的时候要额外注意价格字段。电商系统里价格一般不建议用浮点数，因为float、double在计算时会出现精度丢失，比如0.1+0.2不等于0.3。我在数据库里用的是decimal(10,2)，Java实体类里对应BigDecimal，这样在做订单金额计算时才可靠。
库存字段我单独留在主表里，叫stock。每次用户下单扣减库存时，不要用先查再更新的方式，而是直接用UPDATE语句做原子扣减：
UPDATE product SET stock = stock - #{count} WHERE id = #{productId} AND stock >= #{count}这样能避免高并发下超卖的问题，算是比较基础的防超卖手段。
2.2 购物车与订单模块：Redis缓存与数据库一致性问题
购物车我一开始是存在浏览器本地LocalStorage的，这样做的好处是后端不用单独设计购物车表，操作起来也快。但后来发现一个问题：用户换个设备登录，购物车就没了。数码产品客单价高，用户多半会电脑上看看、手机上再看看，本地存储方案显然不合适。
所以购物车最终改成了后端Redis实现。用Redis的Hash类型来存储：
- key：
cart:userId - field：商品ID
- value：商品数量
用户添加购物车时：
redisTemplate.opsForHash().put("cart:" + userId, productId.toString(), quantity.toString());查询购物车时，从Redis拿到商品ID和数量，再一次性查数据库把商品的名称、价格、图片填充进去。这样购物车的读写性能很高，也解决了多端同步问题。
但这里有个需要注意的地方：Redis里存的是商品数量，价格必须每次从数据库查，绝对不能把价格也缓存到购物车。因为数码产品价格变动太常见了，搞促销、降价、涨跌都很正常。用户下单时必须以数据库中的实时价格为准，购物车里的展示价只做参考。否则用户下单后你按缓存里的旧价格结算，要么亏本，要么被投诉。
订单模块我做了一个单独的订单表和订单明细表。订单主表存订单号、总金额、收货地址、支付状态、订单状态等；订单明细表存下单时商品ID、商品名称、图片快照、单价、数量。
为什么要有快照？因为商品信息会变，如果用户下单后商品改价了，订单里应该保留下单那一刻的价格和名称，否则以后对账、售后都会扯不清楚。这个细节很多初学项目的人会忽略，但它是正规电商系统的通用做法。
2.3 支付模拟与订单状态机设计
真实支付需要对接支付宝或微信支付，需要商户号、证书、回调地址，个人开发者不好搞定。所以这个项目里我做了个模拟支付：用户点击“去支付”，后端生成一条待支付订单，跳转到一个支付模拟页面，点击“确认支付”后，后端把订单状态改成已支付。
但状态不能只靠if-else乱改。我画了一个简单的状态流转约束，在代码里用常量或枚举来做控制：
- 待支付 -> 已支付 -> 已发货 -> 已收货 -> 已完成
- 待支付 -> 已取消
- 售后流程我这里简化了，只做到了“申请退款”那一步
每一步状态变更都通过后端接口统一校验，比如订单如果是“已完成”状态，就不能再取消；如果是“已取消”，也不能再支付。把这些校验逻辑写在Service层，可以避免前端恶意调用接口把订单状态改乱。我在实际实现时用的是Java枚举加一个状态流转Map，非法操作直接抛业务异常。
3. 后端SpringBoot落地细节：认证、缓存、搜索与接口规范
3.1 用JWT+拦截器实现登录认证，避免Session跨域烦恼
商城系统肯定会分普通用户和管理员两种角色。普通用户在前台登录，管理员在后台管理商品和订单。最开始我考虑用Session，但前后端分离后，Session会有跨域问题——前端请求的域名或端口跟后端不一样，浏览器不一定愿意带上SessionID，处理起来要么配置CORS的allowCredentials，要么依赖Cookie的作用域，一搞就很容易懵。
后来我改成了JWT方案。登录成功后，后端生成一个包含用户ID和角色信息的Token返回给前端。前端把Token存在浏览器里，之后每次请求在请求头里带上Authorization: Bearer <token>。后端写一个拦截器，从请求头解析Token，拿到用户信息再放行。
核心代码逻辑大概是这样：
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BusinessException(401, "未登录"); } Long userId = jwtUtils.parseToken(token.replace("Bearer ", "")); UserContext.set(userId); return true; }这里最关键的技巧是，拦截器里解析出的用户ID要放到一个ThreadLocal变量（我封装了一个UserContext），这样在Controller和Service层任何地方都能拿到当前登录用户，不用每个方法都传参。但要注意，接口处理完后必须调用UserContext.clear()，否则Tomcat线程池复用时会串数据。
3.2 MyBatis-Plus分页与模糊搜索，SQL别写得太随意
商城前台必备功能就是搜索和分页。数码产品尤其需要一个筛选栏，按品牌、按价格区间、按分类筛选。我用的是MyBatis-Plus的分页插件，配合LambdaQueryWrapper写条件，代码比较简洁，比如商品列表查询：
LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(StringUtils.hasText(brand), Product::getBrand, brand) .between(priceMin != null && priceMax != null, Product::getPrice, priceMin, priceMax) .like(StringUtils.hasText(keyword), Product::getName, keyword) .eq(Product::getStatus, 1);这里要提醒一下，模糊搜索用like就够了，不要用concat('%', keyword, '%')去套一层，写复杂了反而影响索引。数据量小的时候无所谓，但如果真有几十万商品，就不能这么无脑like了，得用Elasticsearch之类的搜索引擎。对于课程设计级别的项目，MyBatis-Plus的like足够应付。
分页插件配置要注册一个拦截器，这个很多人会忘记写。不写的话，分页SQL只是拼接了LIMIT但不会自动COUNT，导致返回的total一直是0。我刚开始就犯了这个错误，查询列表总页数是0，还以为是前端解析问题，查了半天发现是分页插件没注册。
3.3 Redis做热销榜和购物车缓存：序列化坑简单说
前面提到购物车用Redis存，另外我还用Redis做了一个热销商品排行榜。用户每次购买成功后，给商品的销量加1，然后把商品ID和销量存到Redis的ZSet中：
redisTemplate.opsForZSet().incrementScore("hot:products", productId, 1);首页“热销榜单”直接从ZSet倒序取前10个ID，再去数据库查详情。这样就避免了每次首页刷新都去数据库做一次ORDER BY sales DESC，数据库压力小很多。
但用RedisTemplate时，要特别注意序列化器的配置。SpringBoot默认的JdkSerializationRedisSerializer会把对象序列化成二进制，直接把Long类型的销量值存进去，在Redis客户端里看是一串乱码，而且跨语言解析很麻烦。我后来改成了GenericJackson2JsonRedisSerializer。这里不展开代码了，总之记住一件事：Redis的key建议手动拼业务前缀，value如果是简单数值或字符串就别用对象类型，能存哈希就存哈希。否则乱码和类型转换问题够你调试一整天。
4. 前端Vue实现要点：路由守卫、状态管理与组件复用
4.1 路由懒加载与守卫：怎么控制“需登录”页面
前端我用Vue Router做页面路由。商城页面分两类：一部分是公开的，比如首页、商品列表、商品详情；另一部分需要登录才能访问，比如购物车、结算页、个人中心、订单列表。
我在路由配置里给需要登录的页面加上meta: { requiresAuth: true }，然后写全局前置守卫：
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next({ path: '/login', query: { redirect: to.fullPath } }) } else { next() } })登录成功后，跳回到redirect参数指向的页面，这样用户体验比较顺。
还有一个容易忽略的地方是路由懒加载。商城页面多，如果所有组件都一股脑打进一个JS文件，首屏加载会很慢。我把每个页面都改成() => import('../views/ProductDetail.vue')这样的写法，Vue Router打包时就会自动按需分包。这个优化很简单，但对加载速度的提升非常明显。
4.2 Vuex/Pinia状态管理：购物车数量为什么放在全局
购物车图标上的小红点数量是用户一进入商城就想看到的信息。如果每个页面都去重新请求后端获取购物车数量，会显得很啰嗦，而且切换页面会有闪烁。我选择把购物车总数量放在Vuex（我用的Vue 2所以是Vuex3）里统一管理。
用户在商品详情页添加购物车成功后，直接dispatch一个addCart的Action，在Action内部调用后端接口，成功后commit一个mutation把全局购物车数量加上。这样不管是停留在当前页还是跳转到别的页面，导航栏购物车数量都能实时更新。
需要注意的是，Vuex里保存的数据刷新页面就丢了。所以在App.vue的created生命周期里，我会先请求一次“获取购物车数量”的接口，用来初始化全局状态。相比每次刷新后数量消失，这个方法要自然得多。
4.3 商品列表页的组件拆分：数码产品的筛选栏怎么做
数码商城的商品列表页，筛选栏是个典型场景。我把筛选栏拆成了独立组件ProductFilter.vue，它内部维护品牌列表、价格区间、分类等选项。用户点筛选后，组件通过$emit把筛选条件传给父组件，父组件再重新请求商品列表接口。
这里拆分组件的核心标准是：一个组件只干一件事。筛选栏只管筛选条件，商品列表只管渲染，分页器只管切换页码。拆分出来的组件既能复用，逻辑也清晰，调试的时候定位问题很轻松。
还有一个小技巧：商品卡片组件可以用props接收商品对象，通过v-for循环渲染。给每个商品卡片加一个唯一的key，用product.id而不是index，否则列表变化时Vue的diff算法容易出错，可能出现勾选框错乱、图片闪烁等问题。
另外，数码商品图片往往很多，我在前端做了一层加载优化：图片懒加载。Element UI的el-image自带懒加载属性，设置lazy即可。商品列表页图片多，不懒加载的话，首屏性能和带宽都扛不住。
5. 联调与部署阶段：那些让人抓狂的坑的完整排查记录
5.1 SpringBoot版本太高导致的依赖冲突：根因与解决
我第一次搭后端时图省事，直接用了Spring Boot 3.0.2，结果引入了MyBatis-Plus的旧版本3.4.2，启动直接报“ClassNotFoundException: javax.servlet.Filter”。这是一个非常典型的版本兼容问题。
排查过程其实不复杂：
- 第一步看报错堆栈，发现是
GenericFilterBean类加载失败； - 第二步定位到依赖树，发现Spring Boot 3.x的嵌入式Tomcat已经迁移到
jakarta.servlet，而MyBatis-Plus 3.4.2还是按javax.servlet编的； - 第三步解决，要么升级MyBatis-Plus到适配SpringBoot3的版本，要么把SpringBoot降回2.x。
我当时综合考虑后选了降级到SpringBoot 2.7.8，因为这版我熟，而且其他依赖都不用动。这种问题的根治办法其实就是在项目开始时就明确版本矩阵：JDK版本、SpringBoot版本、MyBatis-Plus版本、Vue版本，先搜一遍兼容性，再动手。不要等报错再补。
5.2 跨域问题：为什么前端调不通后端接口
前后端分离必然遇到跨域。我前端开发服务器跑在http://localhost:5173（Vite默认端口可能不同，Vue CLI默认8080），后端接口是http://localhost:8080，端口不同，浏览器默认拦截跨域请求。
我当时遇到的症状是：前端一调用登录接口，浏览器控制台报Access-Control-Allow-Origin错误，请求根本没到后端。有人可能会说那不是后端没处理跨域，其实是因为后端没返回允许跨域的响应头，浏览器把响应拦了。
解决方式我推荐用后端全局配置CORS，写一个WebMvcConfigurer配置类：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }这里有个细节：如果使用了allowCredentials(true)，那么allowedOrigins不能用*，必须用allowedOriginPatterns("*")。这是个很容易踩的坑，一不注意前端就被跨域卡住半天。
另一种思路是在前端开发配置里加代理，把/api请求代理到后端地址，这样浏览器看到的是同源请求，也能解决问题。但如果后续要部署上线，后端大概率跟前端不在同一个上下文路径，所以我还是推荐后端直接支持跨域，省心。
5.3 部署到云服务器：宝塔面板+jar包运行模式
项目开发完成之后，我把它部署到了一台2核4G的云服务器上。很多教程一上来就讲Docker部署SpringBoot，但对个人项目来说，宝塔面板+jar包的方式更直观、更好维护。
具体操作：
- 在服务器上装好JDK（版本跟本地一致，避免Class版本错误）。
- 把后端项目用Maven打成jar包：
mvn clean package -DskipTests。 - 将jar包上传到服务器，用
nohup java -jar app.jar --spring.profiles.active=prod > app.log 2>&1 &方式启动。 - 前端项目先
npm run build，把生成的dist目录上传到宝塔，创建一个静态站点指向它。 - 配置反向代理，把
/api路径代理到后端http://localhost:8080。
这一步实际上比想象中更考验细节。我第一次部署时，前端耍得很欢，前端页面也能打开，但一调用接口就404。排查了一圈发现是Nginx代理配置写错了。正确的写法大致是：
location /api/ { proxy_pass http://127.0.0.1:8080/; }注意proxy_pass末尾的斜杠很关键，如果末尾没有斜杠，/api/user/login会原样拼到后端地址后面，变成http://127.0.0.1:8080/api/user/login，而后端Controller里定义的是/user/login，自然就404了。加上末尾斜杠后，Nginx会把匹配/api/后面的部分自动拼到代理地址后面，变成http://127.0.0.1:8080/user/login。这个细节不写下来，实在太容易卡住人了。
数据库方面，本地用的MySQL 8.0，服务器上也装MySQL 8.0，字符集统一utf8mb4，避免中文乱码。上线之前记得把spring.datasource.username和password改成服务器数据库的账号，别把本地的账号密码带上去，否则连不上库直接启动失败。
6. 商品搜索与并发控制：数码商城独有的细节优化
6.1 参数搜索的数据库设计思路
数码商城跟普通书店不一样的地方，在于用户经常会用“内存12GB+256GB”“骁龙8gen2”这种参数来筛选商品。如果只靠商品标题的模糊搜索，效果很差。
我实现了一个比较轻量的方案：在product_param表中把每一类数码产品的核心参数抽取成固定键，比如手机类的“运行内存”“存储容量”“处理器品牌”，存为JSON。查询的时候先根据用户选中的参数值找到对应的商品ID集合，再用ID集合去查主表过滤分页。
比如参数表查询，可以写成：
SELECT product_id FROM product_param WHERE param_name = '运行内存' AND param_value = '12GB'复合条件再加IN和AND拼接即可。这种方案虽然不如Elasticsearch专业，但对个人项目完全够用，也比把所有参数塞在搜索框里硬拆词要准确得多。当然如果以后数据量大了，建议还是上Elasticsearch或把参数查询迁移到MongoDB。
6.2 下单防重提交的一点心得
数码产品价格高，用户很可能闲着没事多点几次“提交订单”按钮。如果不对这种请求做幂等处理，数据库里会出现多笔一模一样的订单。
我的做法是在前端做按钮loading，提交后立马禁用按钮，这是第一道防线。后端再补一道：生成一个唯一的orderToken，在用户点击提交订单前先从后端获取这个令牌，提交订单时必须携带，后端接到请求先检查Redis里有没有这个令牌，用过了就拒绝。
这个令牌的过期时间很短，我设置的是5分钟，过期作废。这是防止用户反复刷新页面或重复点击的通用做法，其实很多电商系统的幂等设计也是这个思路。
6.3 订单列表的分页加载与懒加载
订单列表页面我用了分页加“加载更多”两种方式结合。PC端用分页，移动端因为页面空间小，滚动加载更自然。滚动加载的实现也很简单：监听页面滚动到底部时，当前页码加1，请求下一页数据，追加到已有列表数组后面。
这里要注意一个性能问题：不要每次追加前都去查询一遍总条数，而是判断返回的列表长度是否小于“每页数量”，如果小于就表示没有更多数据了，隐藏加载更多按钮。这个判断逻辑比读total更实用，也减少了后端无谓的COUNT查询。
7. 实测后的性能与安全建议
说实话，一个课程设计级别的商城，性能和安全不用做到生产级，但基础的东西必须有。
7.1 接口层的参数校验不能省
很多人写接口时不校验参数，直接拿前端传来的值去查数据库，这不是好习惯。比如价格区间的priceMin如果传了负数，查询就会出问题；用户修改收货地址时，手机号如果不校验格式，后面物流都没法发。
日志级别也要合理。开发环境用DEBUG，生产环境用INFO，避免太多日志把磁盘打满。我在部署后就遇到过一次日志文件越写越大，最后还是用logback配置了按天滚动和大小切割才解决。
7.2 细节安全措施：密码和SQL注入
用户密码绝对不能明文存。我用的不是简单MD5，而是加盐的BCrypt。SpringSecurity里的BCryptPasswordEncoder很好用，加密后每次哈希值都不同，即使两个用户密码一样，存到数据库里的密文也不同，安全性比我以前用的MD5强太多。
SQL注入方面，只要全程用MyBatis-Plus的#{}而不是${}，就基本不会被注入。但如果你写自定义SQL，注意别用字符串拼接参数。
7.3 这个项目还能怎么升级
如果想把项目做得更有亮点，我建议往这几个方向扩展：
- 接入Elasticsearch做全文搜索和价格区间聚合，搜索速度和对数码参数的支持会好很多；
- 接入Alipay沙箱环境，把模拟支付换成真实的支付宝沙箱支付，流程更接近生产；
- 增加优惠券和秒杀模块，锻炼一下Redis分布式锁、消息队列削峰的能力；
- 把前端升级到Vue3 + TypeScript + Pinia，配合Vite，组件逻辑更清晰，类型约束能提前发现很多低级错误。
我对这个项目最满意的一点，是它的核心链路特别完整：用户从注册登录，到搜索商品、看详情、加购、下单、支付、看到订单状态变化，整个闭环全部跑通。做这种项目最大的收获不在于用了多牛的技术，而在于把前后端交互的细节、状态流转的逻辑、部署测试的流程完整走了一遍，这些经验是单纯看教程学不来的。
最后再分享一个实操小技巧：如果你在本地联调阶段觉得每次启动前端、后端太麻烦，可以把后端接口写好之后，直接用Postman或Apifox把主要接口全测一遍，再开始写前端页面。这样前端联调时的错误大多就是前端自己的问题，排查范围小很多。我这个项目因为一开始就养成了这个习惯，后面真正受挫的地方反而集中在部署环境，问题种类也比较单一，没有前后端互相甩锅的混乱局面。做商城项目，技术栈永远不是最大的门槛，把每个环节的真实细节处理好，才是真正让人成长的部分。
