1. 项目全景家电销售展示平台到底在解决什么问题我在接手这个项目的时候第一感觉是这不就是电商系统吗但真把需求捋完才发现家电销售展示平台和普通电商有本质区别而且坑比想象中多得多。最容易踩的坑就是家电产品SKU逻辑复杂、价格浮动大、售后流程长如果照搬服装电商那套代码后期改到想哭。先把这个项目的核心脉络理清楚这是一个典型的前后端分离管理系统后端用SpringBoot MyBatis MySQL前端用Vue全家桶业务范围覆盖家电商品的展示、检索、购物车、下单、后台管理、数据统计等完整链路。适合的人群很明确正在做毕业设计的学生、刚入行想练手的企业级开发新人、以及需要快速搭建电商后台的创业团队。这套技术选型在国内中小型项目中占有率极高学会它基本等于拿到了 Java 后端的敲门砖。项目的业务模型可以分为两个端来看。用户端门户面向普通消费者浏览首页轮播广告、按分类查找冰箱洗衣机空调、搜索商品、查看详情、加入购物车、提交订单、在线支付项目中通常用模拟支付、查看个人订单和物流状态。管理端后台面向运营人员商品分类管理、商品上下架、库存修改、订单发货处理、用户管理、轮播图配置、销售数据统计报表。两端共用同一个数据库通过权限角色区分操作范围这是典型的中小规模电商系统架构。有人可能会问现在电商都做微服务了这个单体架构是不是过时了我不这么看。对于家电销售这种业务边界清晰、并发量可控的场景单体应用反而有巨大优势开发效率高、调试简单、部署成本低、事务处理方便。尤其是一个刚起步的销售平台没必要一上来就是 Spring Cloud 全家桶那只会把自己压垮。这个项目用单体 前后端分离完全能支撑日订单几千单的业务后期真要扩展再按订单、商品、用户拆分服务也不迟。从价值角度看这类项目最大的学习意义在于完整的业务闭环从数据库建模、接口设计、前后端联调到云服务器部署上线是一条龙走下来的。很多入门同学只会在 IDE 里跑通 Demo但对整个系统的构建流程是模糊的这个项目恰恰能把这块补上。2. 技术选型拆解SpringBoot Vue MyBatis 组合的关键考量2.1 后端生态为什么 SpringBoot 和 MyBatis 是绝配SpringBoot 在 Java 后端的地位没什么好争论的它的核心价值是自动装配 简化配置。相比传统 SSM 框架动辄几十个 XML 配置文件SpringBoot 通过起步依赖和自动配置把环境搭建的成本降了一个量级。做这个项目时我只需要引入对应的 starter框架会自动配置好内嵌 Tomcat、数据源、MyBatis SessionFactory真正要手动写的配置只有数据库连接串、Mapper 扫描路径这些基础项。而 MyBatis 在这个项目里的角色更微妙。有人喜欢用 JPA认为它开发速度快、不用写 SQL但在实际业务中家电销售平台有大量复杂的关联查询、条件拼装、动态排序比如 按价格区间 品牌 能效等级过滤并按销量排序 这种需求用 JPA 的 Criteria 或者 Query 写起来非常别扭最终还是要回到原生 SQL 的怀抱。MyBatis 正好提供了灵活性和可控性的最佳平衡SQL 自己写映射规则自己配优化空间完全掌握在开发者手里。举个例子项目里首页的推荐位商品聚合查询既要统计每个分类的商品数量又要带出销量最高的商品信息用 MyBatis 写一个多表 LEFT JOIN 聚合的自定义 SQL几十行搞定而且执行效率一目了然。JPA 也能做但生成的 SQL 往往是套娃子查询性能差一截不说出问题还不好排查。这就是为什么国内互联网公司用 MyBatis 的比例这么高。另外 MyBatis-Plus 这个增强工具在这个项目中我也强烈建议引入它内置了单表 CRUD、分页插件、条件构造器能省掉至少 30% 的重复 Mapper 代码。这个项目里涉及用户表、购物车表这种单表简单操作的直接用 MyBatis-Plus 的 BaseMapper 搞定复杂查询才手写 XML代码层次干净清晰。关于版本建议 SpringBoot 2.7.x 或 3.x 均可但要注意如果选 3.xJDK 必须 17 以上MyBatis-Plus 也要用适配新版本的3.5.3。我实际做这个项目时用的是 SpringBoot 2.7.18 MyBatis-Plus 3.5.3JDK 8这是最稳妥、网上资料最丰富的组合新手照这个配基本不会踩兼容性的坑。2.2 前端方案Vue 技术栈与 Element UI 的搭配思路前端这部分门户展示端和管理后台建议都用 Vue但组件库选择有讲究。跟后台管理端需要大量表格、表单、弹窗不同门户端的核心是商品展示、交互流畅、审美在线。两个端如果混用同一套组件库门户很容易做得像内部系统用户观感很差。我的做法是管理端使用Vue 2 Element UI这是最成熟的组合后台类的 CRUD 界面用 Element UI 的表格、树形控件、表单验证开箱即用开发效率极高。门户端则用Vue 2 自定义样式配合 Swiper 做轮播图自己写商品卡片这样视觉上更自由。当然如果你选 Vue 3对应组件库就是 Element PlusAPI 上略有差异但思路一致。这个项目原版如果是 Vue 2我建议别强行升级 Vue 3因为升级牵扯到组件库适配、路由写法、响应式原理差异对学习型项目来说性价比不高。关于状态管理和路由项目引入了 Vue Router 做前端路由axios 做 HTTP 请求状态管理用 VuexVue 2 场景。但这里要注意一个分辨点Vuex 不是必须的。在门户端全局共享数据其实就用户信息和购物车数量两项我习惯用 localStorage 事件总线解决不引入 Vuex 反而让代码更简单管理端的权限菜单和用户信息也可以靠路由守卫 localStorage 搞定。我经历过很多次团队里为了用 Vuex 而用 Vuex写了一堆 module 结果页面一刷新 state 全没了还得重新调接口纯粹是自找麻烦。这个项目建议合理选择状态管理范围别过度设计。2.3 前后端分离接口约定与联调细节前后端分离项目的核心不是技术而是约定。这个项目里我做了几件让联调顺畅的事统一返回结构。后端所有接口都返回统一的 Result 对象包含 code、message、data 三个字段。success 用 200业务异常用自定义状态码比如 401 未登录、403 无权限、500 业务错误前端 axios 响应拦截器统一处理不需要每个接口单独判断成功失败。RESTful 风格路径。资源用名词复数表示操作通过 HTTP 方法区分GET /api/products 查询列表POST /api/orders 创建订单PUT /api/products/{id} 修改商品。这个约定前后端都能一目了然。日期时间格式统一。后端在 application.yml 里全局配置日期序列化格式为yyyy-MM-dd HH:mm:ss防止 Java 的 LocalDateTime 序列化成数组格式前端接收时不用再做二次转换。这个坑我踩过很多次第一次联调时发现前端拿到的时间长这样2025-01-12T10:30:00和设计稿要求差一个 T折腾了半天才定位到是 Jackson 配置问题。分页参数统一。列表接口统一接收 current 和 size 两个参数返回结构固定为{ records, total, current, size }对应 MyBatis-Plus 的分页模型。前端做了个通用的分页组件传参和接收都按这个结构来整个系统几百个列表页面都可以复用同一套逻辑。这些约定看起来都是小事但在实际项目中前后端扯皮的时间往往比写代码还多。把约定做在前面能省掉大量沟通成本。3. 数据库设计落地从商品表到订单状态的完整建模3.1 商品与分类表家电多级类目的设计细节数据库是整个项目的地基表结构设计得好不好直接决定后续开发的体验。家电类商品和服装、图书差异很大核心特点有两个多级分类和参数维度复杂。分类表我用的是典型的自关联方式支持无限级分类。字段包括 id、name、parent_id、level、sort_order。parent_id 为 0 表示顶级分类比如大家电它的子分类是冰箱、洗衣机冰箱下面还可以有对开门冰箱、十字门冰箱。实际开发中我建议最多控制到三级因为导航菜单的展示和后台的级联选择都更友好超过三级用户操作成本会急剧上升。商品表的设计要注意几个关键字段。主表字段大概是id、category_id、name、subtitle、main_image、detail、price、original_price、stock、sales、status、create_time、update_time。这里有几个容易被忽略的点price 和 original_price 都用 DECIMAL(10,2)绝不用 DOUBLE 和 FLOAT否则前端展示时会出现 2599.9999999999995 这种精度问题毕竟是钱相关的东西精确性必须保证。main_image 存相对路径不存完整 URL。项目里我统一存/images/products/xxx.jpg这种形式前端会用 baseURL 拼接。这样做的好处是迁移服务器时不用改数据库数据只要把静态资源目录拷过去就行。sales 字段做冗余设计。每次订单完成时更新商品表的 sales 字段而不在订单表里现算。虽然牺牲了一点规范但列表页按销量排行的查询效率会大幅提升这也是电商系统的常见做法。status 控制上下架用 tinyint 类型1 代表上架0 代表下架。首页和列表查询都会带这个条件过滤防止下架商品被搜到。商品的富文本详情页参数、包装清单、售后信息用 detail 字段存 HTML 内容和 main_image 分开。Vue 前端用 v-html 渲染需要注意 XSS 风险所以后端要做 HTML 转义和过滤建议引入 jsoup 清洗不安全的标签和脚本。3.2 用户与权限管理端和门户端的账户体系设计用户表的设计上这个项目存在两类角色普通用户C 端和管理员B 端。两个角色虽然都是人但字段差异很大用户要有收货地址、登录记录管理员有角色权限。能不能共用一张表我的建议是可以共用但要靠 role 字段区分。表结构为 id、username、password、nickname、avatar、phone、email、role、status、create_time。role 用 smallint1 是普通用户2 是管理员。这样做的好处是登录接口只需要写一套逻辑通过 role 就能判断跳转门户还是后台。坏处是字段冗余比如普通用户的角色权限字段用不上。但在这个项目规模下这个设计是最务实的。密码存储必须用 BCrypt 加密这是 Spring Security 框架自带的工具类不能自己写 MD5 加盐那种土办法。BCrypt 每次加密的结果都是不同的盐值哈希就算两个用户密码相同数据库中存储的结果也不同暴力破解的代价大幅提高。项目里我在注册接口用BCryptPasswordEncoder().encode()加密登录时用.matches()做比对代码量极小安全性却完全不在一个等级。3.3 订单表链状态机设计与库存扣减方案订单相关的数据表是这个项目里最体现功力的部分。我设计了四张表购物车表、订单主表、订单明细表、收货地址表。核心逻辑集中在订单主表上。订单主表字段id、order_no、user_id、total_amount、pay_type、status、receiver_name、receiver_phone、receiver_address、remark、create_time、pay_time、ship_time、finish_time。其中order_no 的生成规则值得特意说明不直接用数据库自增 id 当订单号因为太容易被别人推算订单总量而且并发高时可能冲突。我采用时间戳(12位) 用户ID后四位 随机数(4位)的组合长度在 20 位左右既能保证唯一也能从订单号上快速反推下单时间和用户。项目里加一个唯一索引防止并发下单时订单号撞车。订单状态是这个项目的关键。我用整型 status 字段表示并定义了一套状态机转换规则状态值含义可流转到0待付款1付款、4取消1待发货2发货2待收货3确认收货3已完成无4已取消无5退款处理中3同意退款这个状态机在前后端都要有对应的映射前端根据状态值渲染不同的按钮和徽章后端在更新订单状态时要校验当前状态是否允许跳转。比如待付款订单不能直接变成已完成必须先付款、发货、收货这步校验很多人会漏掉导致订单数据混乱。库存扣减是这个项目的高危操作。最稳妥的做法是在下单时开启事务用条件更新扣库存UPDATE t_product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}通过受影响行数判断库存是否充足。受影响行数为 0 说明库存不足直接抛异常回滚事务。这种方式比先 SELECT 再 UPDATE 更安全避免并发下超卖。但下单锁库存之后还有一个问题用户下单了不付款库存一直被占着怎么办实际项目中通过定时任务扫描超过 30 分钟未付款的订单自动取消并回滚库存。这个项目里我用 Spring 的 Scheduled 注解实现每 5 分钟跑一次逻辑很简单但对业务完整性非常关键。4. 后端核心接口实线与关键代码拆解4.1 JWT 登录鉴权拦截器配合 Token 实现无状态认证这个项目的登录鉴权我采用的是 JSON Web TokenJWT方案核心优势是服务端无状态用户认证信息保存在客户端 Token 里服务端不需要记录 Session方便水平扩展。对比传统 Session Cookie 方案JWT 在前后端分离的场景下有明显的优势因为浏览器跨域时处理 Cookie 非常麻烦而放在请求头 Authorization 字段里的 Token 没有跨域限制。登录流程这样设计用户提交用户名和密码服务端验证成功后用 JWT 工具类生成一个 Token包含 userId 和 role 两个核心声明过期时间设置为 24 小时。前端登录成功后把 Token 存到 localStorage后续每次请求都在 axios 拦截器里加上Authorization: Bearer token。后端用一个拦截器统一校验白名单路径比如登录接口、注册接口、商品列表接口直接放行其余接口全部验证 Token 合法性。Token 校验通过后还需要一个关键操作把当前登录用户的 ID 保存到后端线程上下文。我使用的工具类是自定义的UserContext内部持有 ThreadLocal拦截器解析 Token 后调用UserContext.setUserId()业务代码里直接获取不用每个 Controller 方法都从参数里解析用户。这个设计能让代码干净很多也方便扩展。注意 Controller 处理完请求后在拦截器的 afterCompletion 方法里一定要调用UserContext.clear()否则线程池复用时会产生数据串号的问题这类 Bug 非常隐蔽排查起来很头痛。核心代码大致是这个样子// JWT 工具类核心方法 public String generateToken(Integer userId, Integer role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 86400000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } // 登录接口简化 PostMapping(/api/user/login) public Result login(RequestBody LoginDTO loginDTO) { User user userMapper.findByUsername(loginDTO.getUsername()); if (user null || !passwordEncoder.matches(loginDTO.getPassword(), user.getPassword())) { return Result.error(用户名或密码错误); } String token jwtUtil.generateToken(user.getId(), user.getRole()); return Result.success(new LoginResponse(token, user.getNickname(), user.getRole())); }注意 SECRET_KEY 不能写在代码里写死项目实践中我通常放在 application.yml 里通过Value注入并且要求长度至少 32 位后续部署时再通过环境变量覆盖。4.2 商品列表分页与多条件查询MyBatis 动态 SQL 的典型应用商品列表接口是用户访问最频繁的接口也是能体现 MyBatis 动态 SQL 能力的地方。需求是前端传入分类 ID、关键字、价格区间、排序方式默认综合、销量优先、价格升序降序、分页参数后端拼接查询。使用 MyBatis-Plus 的条件构造器LambdaQueryWrapper处理单表简单条件复杂排序和表关联则用 XML 里的whereif标签动态拼 SQL。实际项目里我做了一个折中方案大部分查询走条件构造器某些排序维度较多、多表关联的场景手写 XML。比如价格排序 分类过滤 销量数据关联的场景XML 就是这样的结构select idselectProductPage resultTypecom.example.pojo.vo.ProductVO SELECT p.*, c.name AS category_name FROM t_product p LEFT JOIN t_category c ON p.category_id c.id where p.status 1 if testcategoryId ! null and categoryId ! AND p.category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (p.name LIKE CONCAT(%, #{keyword}, %) OR p.subtitle LIKE CONCAT(%, #{keyword}, %)) /if if testminPrice ! null AND p.price gt; #{minPrice} /if if testmaxPrice ! null AND p.price lt; #{maxPrice} /if /where choose when testsortField sales ORDER BY p.sales DESC /when when testsortField priceAsc ORDER BY p.price ASC /when when testsortField priceDesc ORDER BY p.price DESC /when otherwise ORDER BY p.create_time DESC /otherwise /choose /select有几个细节要提醒大家。第一LIKE 查询里的%符号要放在CONCAT里拼接不要直接写%${keyword}%后者会产生 SQL 注入风险同时会把 keyword 里的特殊字符干扰为 SQL 语法。第二XML 中小于号lt;必须转义这一点最容易别忽略。第三不要给用户暴露全表查询的能力条件过滤必须到位否则随着数据量增长接口会越来越慢。关于列表接口的性能优化项目初始数据量小可能看不出差距但等商品过万条后全表 100ms 和 1000ms 的差距就会很明显。实际踩过坑以后你会发现 MySQL LIMIT 深度分页的问题是真实存在的LIMIT 10000, 10会扫描前 10000 条然后丢掉。尤其是后台翻页数特别多的时候。我采用的方案是记录上页最大 ID 的游标分页或者至少优化为 MySQL 8 的窗口函数但在这个项目中简单的 LIMIT 加索引足够应对几万条数据优化归优化但不用过度。4.3 购物车下单与库存扣减事务管理的边界问题购物车模块的逻辑比较直接加购、改数量、勾选、删除、结算。数据结构上购物车表我设计为id, user_id, product_id, quantity, checked, create_time, update_time加了一个 user_id product_id 的唯一索引防止同一用户重复加购同一商品产生多行记录。加购接口的核心逻辑是先查询是否已有记录有则数量加 1没有则插入。结算下单是整个项目中事务性最强的一个操作牵涉到订单主表插入、订单明细批量插入、购物车记录删除、库存扣减、销量更新五个动作这五个动作必须保证要么全部成功要么全部回滚。我在 Service 层的createOrder方法上加了Transactional(rollbackFor Exception.class)注解。这里要特别强调 rollbackFor 参数的设置默认情况下 Spring 事务只对 RuntimeException 回滚如果业务代码抛的是受检异常事务不会回滚这是我见过的高频 Bug 之一。下单流程代码框架Transactional(rollbackFor Exception.class) public OrderVO createOrder(Long userId, ListCartItemDTO items, AddressDTO address) { // 1. 校验收货地址 // 2. 遍历购物车项逐项查商品状态和库存计算总金额 // 3. 生成订单号插入订单主表 // 4. 插入订单明细表 // 5. 条件更新扣减库存受影响行数为0则抛异常 // 6. 删除已购买的购物车记录 // 7. 返回订单信息 }这个流程里最微妙的是第 5 步的条件更新必须放在事务里并且先扣库存后插入订单明细。如果反过来并发场景下可能出现订单明细插入了但库存扣减被回滚导致业务无法继续。将库存扣减放在同一事务里配合 WHERE stock quantity 的条件更新保证并发安全。另外项目里支付的逻辑是模拟的实际对接微信/支付宝支付时还要处理回调通知、验签、幂等等问题那是另一个深坑了。4.4 管理端商品与订单操作状态变更的校验与审计要点管理端的核心职责是运营操作其中商品管理和订单处理是重点。商品管理端运营人员要能新增商品、编辑商品、批量上下架、调整库存。批量上下架我采用的方案是接收一个 ID 数组和上下架状态值后端遍历执行 UPDATE。注意这里不能用 MyBatis-Plus 的循环查询再更新批量更新要么用updateBatchById批量提交要么在 XML 里写 foreach 循环更新。数据量不大时这个差距不明显但updateBatchById默认仍然是逐条 UPDATE真正最高效的是一条 SQL 多值更新的写法不过对于后台管理这种低频操作完全够用也更容易维护。订单管理端运营人员能看到所有订单按订单号和用户手机号搜索对待发货订单点击发货。发货操作会更新订单状态为待收货同时设置 ship_time 和物流单号前端用户就能在我的订单里看到物流信息。这里还涉及一个权限细节发货接口应该是在事务内根据订单状态条件更新UPDATE t_order SET status 2, ship_time NOW() WHERE id #{orderId} AND status 1加一个 WHERE status 1 条件防止运营人员重复点击发货导致状态覆盖保证数据一致性这个写法和前面的库存扣减是同一个道理。每个订单状态的变化最好都记录一条审计日志。这个项目里我建了一张 t_order_log 表记录订单 ID、操作人、操作类型、操作前状态、操作后状态、备注。虽然很多开发同学觉得加这张表麻烦但一旦出现客户投诉我明明付款了凭什么说没付这张表就是你的救命稻草。日志表设计成本极低业务收益却很大我的建议是类似的系统必须加。4.5 数据统计报表几行 SQL 做出可用的大屏数据项目管理端首页通常要展示核心经营数据今日订单数、今日销售额、总用户数、商品总数以及近 7 日销售趋势、分类销售额占比。这些统计接口用聚合查询就能搞定无需复杂的 BI 工具。销售趋势的思路按日期分组统计订单金额不外乎这样一条 SQL 就能拿下SELECT DATE(create_time) AS day, SUM(total_amount) AS amount FROM t_order WHERE status IN (1, 2, 3) AND create_time #{startDate} GROUP BY DATE(create_time) ORDER BY day ASC需要注意日期的生成逻辑近 7 日需要连续展示日期如果某天没有订单SQL 查出来的结果就没有这一天前端画出来的折线图就会有断点。我的解决方式是在 Java 代码里生成一个近 7 日的日期列表遍历时从查询结果 Map 中取值没有就补 0。这种代码补全缺失日期的思路很实用不光用于统计日历、排班这类业务都会遇到同样的场景。分类销售占比用 GROUP BY 分类 ID 关联商品表按订单明细表的商品分类汇总销售额。前端用 ECharts 画饼图API 数据格式固定为{ name: 分类名, value: 销售额 }的数组后端接口直接转化好结构。ECharts 的按需引入放在一个单独的 chart.js 里不要 main.js 里全量引入包体积可以小不少。5. 实操记录从零把项目跑起来需要几步5.1 本地环境准备与版本选型开始之前先把环境统一好避免低版本工具导致各种莫名其妙的异常。我实际操作环境的版本如下可以直接参考JDK 8SpringBoot 2.7.x 环境Maven 3.6.3 或更高版本MySQL 5.7 或 8.0 均可注意连接驱动差异Node.js 14Vue 2 项目开发工具IDEA 2023后端、VS Code前端这里要提示的是 MySQL 8.0 和 5.7 的驱动 class name 不同5.7 是com.mysql.jdbc.Driver或com.mysql.cj.jdbc.Driver8.0 强制使用com.mysql.cj.jdbc.Driver且 URL 需要加serverTimezoneAsia/Shanghai参数否则会报时区错误。项目里很多同学 MySQL 8 驱动配错是因为复制了一段旧代码一启动就ClassNotFoundException直接怀疑人生。5.2 数据库初始化与连接配置数据库方面项目提供了一个 init.sql 脚本包含建库建表语句和基础测试数据。执行方式很简单用 Navicat 或命令行登录 MySQL 后执行source /path/to/init.sql。需要注意的是 MySQL 默认字符集如果没设成 utf8mb4中文数据会乱码。所以建库时我建议手动指定CREATE DATABASE IF NOT EXISTS home_appliance_sales DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;接下来修改后端配置文件 application.yml。重点配置三项数据源连接串、MyBatis 配置、文件上传路径。spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/home_appliance_sales?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 mybatis-plus: mapper-locations: classpath:/mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplmap-underscore-to-camel-case这个配置必须打开否则数据库的 create_time 字段无法自动映射到 Java 实体的 createTime 属性查询出来的对象全是 null。log-impl配置为 StdOutImpl 可以把执行的 SQL 打印到控制台联调时排查 SQL 问题全靠它项目上线前再关闭。5.3 后端启动遇到端口占用与版本冲突怎么处理后端启动流程很标准IDEA 打开后端目录Maven 自动下载依赖后运行启动类。这里我遇到的最典型问题是端口被占用。SpringBoot 默认 8080如果本机有另一个服务占用了 8080启动就会报Web server failed to start。解决办法第一选择是在 application.yml 里修改server.port: 8081第二种用命令行工具查出占用进程再杀掉。项目的管理接口和门户接口共用一个端口这也是约定的一部分不需要分端口。如果是访问的人多了或者资源紧张也可以考虑加到 80 端口配合 Nginx 部署项目。Maven 依赖冲突。项目里可能同时引入了 MyBatis-Plus 和别的一些工具包依赖冲突最常见的报错是NoSuchMethodError或ClassNotFoundException而且都是在运行时才爆发。解决思路是用 IDEA 的 Maven Helper 插件查看依赖树找到冲突源再在 pom.xml 里排除。lombok 版本不兼容。编译时提示getter/setter 找不到基本是 Lombok 版本和 JDK 版本冲突。SpringBoot 2.7.x 配 Lombok 1.18.30 是比较稳的组合。5.4 前端启动跨域代理与打包配置前端项目拿到后先执行npm install安装依赖。这里最容易出现问题的是 node-sass 下载失败因为 node-sass 需要从 GitHub 拉二进制文件国内网络环境下经常超时。我在实际操作中直接把项目里的 node-sass 换成 sassdart-sass可以绕开这个坑。如果是老项目依赖 node-sass也可以设置镜像源解决。依赖安装好后看前端配置的代理。开发环境前后端分离必然会遇到跨域问题。我的项目里解决方式是使用 Vue CLI 的 devServer 代理配置在 vue.config.jsmodule.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }原理是让前端开发服务器默认 8081把 /api 开头的请求转发到后端 8080 端口浏览器感觉不到跨域的存在。这里有一个坑proxy 里 target 的地址必须写对后端端口改成 8081 了就同步改这里否则前端请求全部 404 或超时。另外changeOrigin: true必须开否则部分环境下请求头的 Host 字段不变后端一些基于 Host 的判断逻辑会出错。门户端和管理端如果是两个独立的前端应用就分别在自己的 devServer 里配置代理分别访问同一后端。后端接口路径统一以 /api 开头代理规则简单清晰不会有两个端请求路径冲突的问题。5.5 生产部署思路纯净环境下快速上线项目要在云服务器上正式部署建议按下面的思路来因为我已经踩过几轮了后端打 jar 包时执行mvn clean package -DskipTests会在 target 目录下生成一个可执行 jar。服务器上只需要安装 JDK执行java -jar home-appliance.jar即可。如果想让它在后台稳定运行用nohup命令放到后台并配合 Shell 脚本做启动、停止、重启服务器的内存分配根据实际资源来设置典型-Xms256m -Xmx512m。前端打包执行npm run build会在 dist 目录生成静态文件。部署时用 Nginx 做静态文件服务同时配置反向代理把 /api 请求转发到后端的 Java 进程。一个完整的 Nginx 关键配置如下server { listen 80; server_name _; root /usr/share/nginx/html/home-appliance; 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }注意try_files $uri $uri/ /index.html这一行Vue Router 使用 history 模式时刷新非首页路径会出现 404必须有这个配置兜底。hash 模式没有这个问题但 URL 上会带个 # 号观感差一点。实际运营如果要求美观用 history 模式部署注意补这行配置即可。如果用了文件上传功能Nginx 还要在配置里设置 client_max_body_size默认 1M 传大图会直接返回 413。6. 高频踩坑记录与排查思路这些坑值得你提前知道6.1 跨域配置重复导致的怪异问题前后端分离项目跨域几乎是必踩的坑。我曾经遇到一个特别迷惑的现象前端访问接口浏览器控制台报 CORS 错误但同一个接口用 Postman 请求完全正常。原因在于后端既加了跨域配置类又在 Spring Security 或拦截器里手动加了跨域头两套配置产生冲突请求被响应了但没有有效的跨域头。排查思路先看后端控制台是否收到这个请求收到了就说明网络通问题在后端响应头没收到的也有代理层拦截或防火墙可能在作祟。正确做法是跨域配置统一在一个地方写。如果你使用了 Spring Security推荐在 SecurityConfig 里配置 CORS如果没有就写一个 WebMvcConfigurer 的 CorsRegistry一处配置全局生效不要多处配置。6.2 Token 过期与前端路由守卫的配合问题JWT 通常设置 24 小时过期用户操作一半 Token 过期时后端接口会返回 401。如果前端不处理用户看到的现象就是页面点了没反应或直接弹出登录框。我的做法是在 axios 响应拦截器里统一判断code 为 401 时清除本地存储的 Token 和用户信息跳转到登录页并提示登录已过期请重新登录。service.interceptors.response.use( response { /* 成功处理 */ }, error { if (error.response error.response.status 401) { localStorage.clear() router.push(/login) } return Promise.reject(error) } )另外要注意多个并发请求同时收到 401 时会触发多次跳转。实际项目里我会加一个简单的标志位在弹出跳转提示前判断是否已经在跳转过程中避免重复跳转。细节虽小但体验差别很大。6.3 金额计算精度与时间显示错乱的坑前端页面在展示订单总金额时如果后端返回的是 Double 类型的数据经过 JSON 序列化和 JS 解析可能出现小数点后多位。更危险的是计算总价时框架直接 Java Double 相加多个商品价格最终结果是 2599.9999999999995 永远不等于 2600对金额判等就会出 bug。解决方法是实体类金额字段全部用 BigDecimal数据库用 DECIMAL前端展示时调用toFixed(2)函数控制精度金额计算后端彻底兜底前端只负责展示不参与金额运算。时间显示错乱的问题同样常见。前端从后端拿到的是yyyy-MM-dd HH:mm:ss格式的字符串但如果没有统一时区后端返回的时间可能是 UTC 时间前端展示会少 8 个小时。在配置里明确设置 JVM 时区在启动命令加-Duser.timezoneAsia/Shanghai或者在配置文件里设置spring.jackson.time-zone: GMT8一次性解决。6.4 图片上传与回显的路径坑商品图片上传是管理端的常用功能项目里用 MultipartFile 接收文件保存到本地磁盘指定目录再把相对路径写入数据库。但部署和开发的关键就在于本地磁盘的绝对路径一旦变化图片就会挂掉。我的做法是后端配置一个自定义上传路径属性如upload.pathD:/upload/通过 Value 注入统一返回/images/yyyyMMdd/xxx.jpg这样的带日期的相对路径容易按时间归档整理前端展示图片的 URL 由后端接口拼接提供一个上传路径到访问路径的映射比如 Nginx 把 /images 请求映射到 D:/upload 目录。有一个年久失修的验证不同环境文件保存的绝对路径不能与数据库存储的内容直接绑定。比如开发环境 D:/upload生产环境可能是 /data/upload一旦绝对路径写进数据库换环境就是一堆 404 图片。确保数据库只存相对路径服务端动态拼接访问 URL是一个比较典型的工程化习惯。6.5 高频问题排查速查表把我在多轮实操中遇到的典型问题整理成一个速查表对照排查事半功倍症状常见原因排查方法启动时报 404 找不到 Mapper XMLmapper-locations 路径配置错误检查 application.yml 中 mapper-locations 与 XML 实际目录匹配前端接口 404后端路径没有 /api 前缀或代理未配对依次查看后端 Controller 路径与前端请求路径、代理 target查询出的对象字段全为 null驼峰映射未开启打开 map-underscore-to-camel-case 配置登录成功但后续接口 401Token 未存到 localStorage 或请求头未带检查 axios 请求拦截器和登录页存储逻辑中文乱码数据库字符集或连接串未指定编码统一 utf8mb4URL 加 characterEncodingutf8上传图片前端显示 404静态资源映射缺失后端加 /images/** 映射或资源映射配置到磁盘目录打包后刷新子路由 404Nginx 缺少 try_files补上try_files $uri $uri/ /index.html;商品库存扣成负数先查库存再更新改成条件更新UPDATE ... WHERE stock #{quantity}7. 一些实操心得与扩展思路这个项目做下来我个人最大的体会是一个系统能不能稳定运行往往不在框架选型多新潮而在于细节上够不够讲究。比如数据库金额字段都用 BigDecimal、订单状态变更加 WHERE 条件控制并发、用条件更新扣库存、所有接口返回统一结构这些看似不起眼的习惯真正上线后能省下无数个处理线上事故的通宵。做项目不是写完 CRUD 就算完事要考虑用户怎么误操作、并发怎么冲击、换环境怎么不崩这才是项目经验的真正价值。最后再分享一个我在完整做一遍后越发觉得值得做的扩展方向加入系统监控。给后端接入 Spring Boot Actuator配合一个简单的健康检查接口部署到服务器上以后至少能用脚本定时探测存活状态服务挂了自动重启。数据统计部分可以继续扩展用定时任务每天凌晨统计一次前一天的销售报表把结果存入统计表报表页面查询历史数据时就完全不用跑实时聚合 SQL 了查询速度会有质的提升。如果你在此基础上想把产品做得更完整还可以继续加上多商家入驻、优惠券、积分商城、售后申请这些模块底层的用户表、订单表、商品表设计都是可以平滑扩展的。希望这篇分享能帮你把系统的整体脉络打通少走一些弯路。