最近一直在折腾一套智能家居销量数据分析系统前后端加起来代码量不小正好也赶上了毕设季不少人都在找这类带完整源码和文档的Java Web项目。借这个机会把整套东西从技术选型到落地实现梳理一遍把我踩过的坑、改过的代码、优化过的SQL都记录下来希望能帮到正在做类似系统的朋友。这套系统用的是目前市面上非常主流的一套组合SpringBoot2 Vue3 MyBatis-Plus MySQL8.0。业务场景是智能家居产品的销量数据分析也就是采集订单、统计销量、分析趋势、管理商品和用户最后通过图表直观呈现。文章会从整体架构、数据库设计、后端接口实现、前端页面开发一直讲到部署上线时遇到的坑和排查方法尽量做到让零基础的人也能看懂整体脉络让有经验的人能直接拿去参考。1. 项目整体设计与技术选型思路1.1 为什么偏偏选这套技术栈先说技术选型。有人可能觉得SpringBoot2已经不算新了但恰恰是因为它“不算新”才更适合做毕设和企业内部管理系统。SpringBoot2的生态极其成熟网上随便一搜就是大量现成案例遇到问题几乎都能找到解决方案。而SpringBoot3虽然出了但很多第三方库还在适配期尤其是MyBatis-Plus和SpringBoot3的兼容性早期踩坑的人不少我身边就有同学因为用SpringBoot3折腾了整整三天。所以说求稳的话SpringBoot2是比SpringBoot3更务实的选择。前端选了Vue3而不是Vue2理由也很简单。Vue3的Composition API在逻辑复用和代码组织上比Vue2的Options API清晰太多尤其是做后台管理系统这种有大量数据展示和交互操作的场景。再加上Element Plus这个组件库已经全面适配Vue3表格、表单、日期选择器、弹窗这些现成组件拿来即用开发效率非常高。MyBatis-Plus这个ORM框架一定要重点提。做数据管理系统最怕写重复的CRUD代码而MyBatis-Plus的BaseMapper接口直接内置了增删改查方法连SQL都不用写就能完成大部分数据库操作。配合条件构造器LambdaQueryWrapper动态查询条件的拼接也不再是噩梦。有人担心用了ORM会丧失对SQL的控制力但实际上MyBatis-Plus支持自定义SQL复杂统计完全可以直接写原生SQL灵活性并没有丢失。MySQL8.0作为数据库没有争议。相比5.78.0的窗口函数和通用表表达式让复杂的销量统计SQL好写了很多性能也更好。之前我用5.7写累销排行这类统计动辄就要搞临时表或者一堆子查询嵌套换成8.0直接用窗口函数就清爽了。1.2 系统的核心模块与功能边界再来看这套系统的核心模块。智能家居销量数据分析系统的业务并不复杂围绕“数据管理—数据分析”这条主线展开主要拆成这么几个模块用户模块用户的注册、登录、信息管理还有后台管理员的账号管理商品模块智能家居产品的分类管理、商品信息的增删改查、上下架状态控制订单模块前台用户购买下单后台管理员查看所有订单列表、更新订单状态销量分析模块按时间维度统计销量趋势、按商品分类统计占比、生成销量排行报表数据可视化模块用ECharts图表展示订单趋势、品类分布、热门商品排名等这里要多说一句这个系统的“数据分析”和那种动辄上亿数据的大数据项目是两码事。它的定位是面向中小规模数据量的管理系统核心是数据的可视化呈现和基本统计比如“近七天每日销售额是多少”“哪个品类的智能音箱卖得最好”“销量Top10的商品是哪些”。搞清楚这个定位数据库设计和后端接口就容易把握了不需要上大数据组件也用不着设计复杂的离线任务。1.3 项目目录结构与角色权限思路给新手提个醒刚开始搭项目的时候一定要把目录结构规划好。我见过太多人把Controller、Service、Mapper全都堆在几个包底下代码写到后面自己都找不着。这套系统的后端目录大致是这么分的controller接收前端请求不处理具体业务逻辑service业务逻辑层事务控制也在这里mapper与数据库交互的Mapper接口entity数据库实体类vo视图对象专门给前端返回定制化结构config配置类MyBatis-Plus分页、跨域等utils公共工具类common通用返回结构、统一异常处理角色权限这块我做的是比较轻量的方案普通用户登录后可以看到商城页面、下单、查看个人信息和消费记录管理员登录后进入后台管理界面操作商品、订单、用户管理和查看统计图表。权限控制没有引入Spring Security那套重量级框架而是在拦截器里校验token因为系统本身角色只有两种没必要自己给自己找麻烦。2. 数据库设计销量分析的前提是数据结构清晰2.1 核心表结构与字段说明数据库设计是这套系统的灵魂。销量分析做得好不好很大程度取决于底层数据表怎么设计。这张表结构我调整过好几版最终稳定的方案这样用户表userid、username、passwordBCrypt加密存储、nickname、avatar、phone、create_time、role。其中role字段用于区分普通用户和管理员这个设计简单但实用。智能家居商品表productid、name、category、price、stock、image、description、sales_count、status。category字段直接存分类名称比如“智能音箱”“智能门锁”“扫地机器人”不单独建分类表因为分类数量有限且不涉及多层级关系。订单表ordersid、order_no订单编号、user_id、total_amount、status、create_time、pay_time。订单状态用数字表示0表示待支付1表示已支付2表示已发货3表示已完成4表示已取消。订单项表order_itemid、order_id、product_id、product_name、product_price、quantity、subtotal。为什么要把商品名称和价格冗余存到订单项里因为商品信息是可能修改的但用户下单那一刻的商品快照必须保留否则以后统计历史数据时价格和名称都对不上。这几张表的设计算是非常常规了但真正理解冗余字段的意义需要在实际项目中体会。我一开始也犹豫过要不要冗余product_name后来发现如果下单后修改了商品名称历史订单显示出来的商品名就会和用户当时买的对不上这个体验非常糟糕。2.2 销量统计表的必要性分析除了上面这几张基础表我还加了一张销量统计表sales_analysis字段为id、statistics_date、product_id、category、sales_quantity、sales_amount。这张表是典型的“空间换时间”思路把每天每个商品的销量预先汇总存进去。为什么要单独建这张统计表直接查orders和order_item联表统计不行吗答案是行但很慢而且SQL极其复杂。比如要统计“某个月份里每个分类的销量占比”直接查询需要同时关联orders、order_item、product三张表再做分组聚合。当数据量到了几千上万条的时候这种关联聚合查询的响应时间会明显上升而且接口每次调用都要临时算一遍白白浪费资源。有了sales_analysis表按天做一次聚合统计查询的时候就只要对这个汇总表做过滤分组速度快一个量级。这也对应数据分析项目里的一个常见思路基础明细数据表 统计数据表分层设计。做这种系统的同学建议把这种维度建模思维好好体会一下。虽然我们用的不是传统数仓但这个思想是一致的。具体执行时我在后端写了一个定时任务每天凌晨统计前一天的订单数据写入sales_analysis表。这样第二天的所有报表查询都基于这张表整个数据链路的压力就大大减轻了。2.3 MySQL8.0下的SQL优化经验MySQL8.0确实给这套SQL的书写带来了不少便利。这里分享几个我在项目中直接受益的写法。第一个是窗口函数的应用。比如要计算每个商品分类下的销量排名传统写法需要自连接或者变量子查询而用了MySQL8.0的ROW_NUMBER()之后一条SQL搞定SELECT product_name, category, sales_quantity, ROW_NUMBER() OVER(PARTITION BY category ORDER BY sales_quantity DESC) AS rank_no FROM sales_analysis WHERE statistics_date BETWEEN 2024-01-01 AND 2024-01-31;第二个是日期函数。统计“近7天销量”这种需求特别常见直接用DATE_SUB和CURDATESELECT statistics_date, SUM(sales_quantity) AS total_quantity FROM sales_analysis WHERE statistics_date DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY statistics_date;第三个是索引的使用。orders表以user_id和create_time建立联合索引sales_analysis表以statistics_date和product_id建立联合索引。尤其是sales_analysis表因为这个表的所有查询几乎都带日期条件所以日期字段的索引优先级最高。索引不要贪多。有时候看某本书上推荐这索引那索引就全给表加上结果发现不仅没提速反而让插入和更新变慢了。我自己的原则是先根据查询条件设计索引run一条查询用EXPLAIN看执行计划发现全表扫描了再针对性加索引。3. 后端实现SpringBoot2 MyBatis-Plus的最佳实践3.1 MyBatis-Plus让CRUD不再是体力活后端部分最值得展开的就是MyBatis-Plus的用法。这套系统里我的Mapper层几乎只写接口连XML文件都很干净因为大部分数据库操作都用内部方法和条件构造器完成了。来看一个典型场景。前端需要查“所有订单中已支付状态的订单列表”——普通写法是在Mapper里写个selectByStatus的方法配一条SQL然后Service层调用。用了MyBatis-Plus之后是这样Override public PageOrders getOrderPage(int pageNum, int pageSize, Integer status) { PageOrders page new Page(pageNum, pageSize); LambdaQueryWrapperOrders wrapper new LambdaQueryWrapper(); wrapper.eq(Orders::getStatus, status) .orderByDesc(Orders::getCreateTime); return orderMapper.selectPage(page, wrapper); }简洁高效而且不用写一行XML。LambdaQueryWrapper的好处是类型安全字段名写错了编译期就能发现而不是跑到SQL执行时才报错。这个体验对于开发效率的提升是巨大的。再比如后台商品搜索通常要支持按名称模糊查询、按分类筛选、按价格区间过滤条件可多可少。以前的做法是拼SQL在XML里写一堆if判断现在同样是条件构造器的事情LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); if (StringUtils.hasText(name)) { wrapper.like(Product::getName, name); } if (StringUtils.hasText(category)) { wrapper.eq(Product::getCategory, category); } if (minPrice ! null) { wrapper.ge(Product::getPrice, minPrice); } if (maxPrice ! null) { wrapper.le(Product::getPrice, maxPrice); }代码一目了然。如果换XML写代码量至少翻一倍还容易出现标签没闭合或者参数类型判断出错的问题。3.2 分页查询与条件构造器实战分页查询也是后台管理系统的高频需求。MyBatis-Plus的分页插件配置起来只用两步一是添加PaginationInnerInterceptor配置类二是在Service层调用selectPage方法。配置类长这样Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这个配置类的作用是拦截SQL自动拼接Limit分页语句。没有这个配置selectPage是跑不起来的会直接抛异常。我遇到过几次这种情况都是因为忘了引导jar包或者漏掉这个配置排查半天才发现只是这种细节问题。业务层调用分页的逻辑可以是public Result getOrderList(Integer pageNum, Integer pageSize, Long userId, Integer status) { PageOrders page new Page(pageNum, pageSize); LambdaQueryWrapperOrders wrapper new LambdaQueryWrapper(); if (userId ! null) { wrapper.eq(Orders::getUserId, userId); } if (status ! null) { wrapper.eq(Orders::getStatus, status); } wrapper.orderByDesc(Orders::getCreateTime); PageOrders resultPage orderMapper.selectPage(page, wrapper); MapString, Object data new HashMap(); data.put(total, resultPage.getTotal()); data.put(records, resultPage.getRecords()); data.put(current, resultPage.getCurrent()); data.put(pages, resultPage.getPages()); return Result.success(data); }前端分页组件需要什么数据后端就返回什么数据配合起来非常省心。有些刚接触分页的人容易犯一个错误就是自己手动计算limit和offset再拼到SQL里其实完全没必要MyBatis-Plus已经把这层封装好并且开源多年了性能经过大量项目验证。3.3 统计接口的SQL写法与聚合函数应用销量统计模块是整个系统的核心接口思路基本围绕sales_analysis表展开。虽然MyBatis-Plus用起来很方便但涉及复杂统计查询时我选择直接写SQL这样对SQL的执行逻辑更可控。统计“不同分类的销量占比”时SQL如下SELECT category, SUM(sales_quantity) AS total_quantity, ROUND(SUM(sales_amount), 2) AS total_amount FROM sales_analysis WHERE statistics_date BETWEEN #{startDate} AND #{endDate} GROUP BY category ORDER BY total_quantity DESC;统计“销量趋势按天”时SELECT statistics_date, SUM(sales_quantity) AS daily_quantity, ROUND(SUM(sales_amount), 2) AS daily_amount FROM sales_analysis WHERE statistics_date BETWEEN #{startDate} AND #{endDate} GROUP BY statistics_date ORDER BY statistics_date ASC;统计“销量Top10商品”SELECT product_name, category, SUM(sales_quantity) AS total_quantity, ROUND(SUM(sales_amount), 2) AS total_amount FROM sales_analysis WHERE statistics_date BETWEEN #{startDate} AND #{endDate} GROUP BY product_id, product_name, category ORDER BY total_quantity DESC LIMIT 10;这里如果把字段全换成*或者查出来再在Java层处理效果都不如直接在SQL里聚合好。数据库擅长的事情就应该交给数据库做别把数据捞回来自己逐条计算那样既慢代码又丑。另外统计接口的返回值最好用一个专门的VO类承接不要把Map到处传不然日后维护的时候真的会看哭自己。3.4 登录鉴权与统一响应格式设计登录鉴权是一个后台管理系统逃不开的话题。这套系统我采用了JWTJSON Web Token的方案登录成功之后后端生成一个token字符串返回给前端前端每次请求在请求头里带上Authorization字段后端通过拦截器校验token的合法性并解析用户信息。生成token的核心代码大致这样public String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }拦截器校验public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { response.setStatus(401); return false; } try { Claims claims Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token.substring(7)) .getBody(); request.setAttribute(userId, Long.parseLong(claims.getSubject())); return true; } catch (Exception e) { response.setStatus(401); return false; } }统一响应格式也很重要我定义了一个Result类所有接口都返回同样的结构体public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } }这个设计虽然不复杂但能让前端组件在处理数据时保持代码的一致性不至于每个接口都要单独适配。实际开发中我看到过不少项目的前端代码被后端混乱的返回格式坑得很惨所以统一响应格式这件事尽量提早做不要等接口写多了再回头改。3.5 跨域配置与调试环境处理的注意事项前后端分离的开发模式下前端在http://localhost:5173跑后端在http://localhost:8080跑跨域问题基本是必现的。处理方式有两种一种是后端开启CORS跨域资源共享允许前端地址访问另一种是通过Nginx反向代理把前端请求转发到后端。开发阶段我用的是后端CORS方案SpringBoot里写一个配置类就好Configuration public class CorsConfig { Bean public WebMvcConfigurer corsConfigurer() { return new WebMvcConfigurer() { Override public void addCorsMappings(Registry registry) { registry.addMapping(/**) .allowedOriginPatterns(http://localhost:*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true); } }; } }注意这里的allowedOriginPatterns而不是allowedOrigins因为使用allowCredentials(true)时allowedOrigins不能直接放行所有地址否则会被浏览器拦截。跨域问题排查时还有个小细节容易被忽略浏览器预检请求OPTIONS的响应状态。如果拦截器把所有非登录接口都拦下来OPTIONS预检请求就过不了前端就会报跨域错误。解决方法是添加过滤器把OPTIONS请求直接放行。我当时排查了很久才发现这个问题一度以为是CORS配置写错了。4. 前端实现Vue3 Element Plus ECharts的完整落地4.1 Vue3开发环境搭建与环境变量配置前端部分一开始就是环境搭建。Vite作为构建工具是最优选启动速度比Webpack快上一个数量级。在PC上创建一个Vue3项目的命令npm create vuelatest过程中会问是否启用TypeScript、Router、Pinia等我按需选了Router路由和Pinia状态管理其余选了否让项目保持相对精简。等待依赖安装完成后启动项目npm install npm run dev默认跑在5173端口这就是Vite的默认配置。然后安装Element Plus和EChartsnpm install element-plus npm install echarts npm install axiosmain.js入口文件里注册Element Plusimport { createApp } from vue import App from ./App.vue import router from ./router import ElementPlus from element-plus import element-plus/dist/index.css const app createApp(App) app.use(router) app.use(ElementPlus) app.mount(#app)全局的axios实例最好单独封装一个request.js统一配置baseURL后端接口地址和请求拦截器。这些看起来简单但等前端路由、页面、组件都建好之后会有很多依赖环境变量的配置比如后端地址在开发环境是localhost生产环境是服务器IP如果一开始不做好env配置后面改起来非常痛苦。4.2 前端路由与页面骨架设计前端页面结构按照角色来划分。普通用户端包括首页展示推荐商品和轮播图商品列表按分类筛选商品详情展示价格、库存、描述支持加入购物车和直接购买购物车结算操作个人中心基本信息、订单记录管理员端后台包括控制台数据总览卡片 基础图表商品管理商品列表、新增、编辑、删除订单管理全部订单列表、状态修改用户管理用户列表、封禁/解封操作数据分析销量趋势图、分类占比饼图、销量排行柱状图路由配置里我用路由守卫来判断登录状态没登录的用户访问需要登录的页面会自动跳转到登录页管理员访问非管理端页面时也会被拦截。逻辑不算复杂但很实用。router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) } else if (to.path.startsWith(/admin) localStorage.getItem(role) ! ADMIN) { next(/) } else { next() } })4.3 订单趋势图与分类占比图的实现细节数据可视化是这套系统的门面。ECharts作为目前最主流的可视化库基本没有替代选项无论是折线图、柱状图还是饼图接入方式都统一。以“近30天销量趋势图”为例先在后端写一个接口返回日期数组和对应销量数组前端拿到数据后在组件里初始化ECharts实例import * as echarts from echarts const chartDom ref(null) let chartInstance null const initChart () { chartInstance echarts.init(chartDom.value) chartInstance.setOption({ tooltip: { trigger: axis }, xAxis: { type: category, data: dates.value }, yAxis: { type: value, name: 销量件 }, series: [ { name: 销量趋势, type: line, smooth: true, data: quantities.value } ] }) } onMounted(() { fetchTrendData().then(() { initChart() }) })还有几个细节需要特别注意第一是容器的大小。ECharts初始化时如果容器没有明确的宽高图表会出现空白或变形。我的解决方案是在容器上显式设置stylewidth: 100%; height: 400px;。第二是组件销毁时释放实例。Vue3的组合式API下可以在onBeforeUnmount中调用dispose方法onBeforeUnmount(() { if (chartInstance) { chartInstance.dispose() chartInstance null } })第三是窗口大小变化时重渲染否则图表会一直保持初始化时的大小window.addEventListener(resize, () { chartInstance chartInstance.resize() })分类占比图用饼图销量排行用柱状图这些配置我都是基于同一个图形实例的规范来组织的区别主要在于series数组里的type字段。掌握了套路之后画什么图都只是配置项的微调。4.4 日报导出功能的实现方式日报导出功能虽然不起眼但却是很多毕设评委比较感兴趣的点。需求很简单管理员可以按月导出销售统计报表格式为Excel文件。后端实现方式是我自己写了一个简单的工具类用Apache POI创建Workbook然后填充表头和数据行最后写入HttpServletResponse的输出流。核心代码public void exportMonthlyReport(String month) { ListSalesSummaryVO list salesAnalysisService.getMonthlySummary(month); Workbook workbook new XSSFWorkbook(); Sheet sheet workbook.createSheet(month 销售报表); String[] headers {日期, 分类, 销量, 销售额}; Row headerRow sheet.createRow(0); for (int i 0; i headers.length; i) { Cell cell headerRow.createCell(i); cell.setCellValue(headers[i]); } int rowNum 1; for (SalesSummaryVO vo : list) { Row row sheet.createRow(rowNum); row.createCell(0).setCellValue(vo.getStatisticsDate()); row.createCell(1).setCellValue(vo.getCategory()); row.createCell(2).setCellValue(vo.getTotalQuantity()); row.createCell(3).setCellValue(vo.getTotalAmount()); } for (int i 0; i headers.length; i) { sheet.autoSizeColumn(i); } response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet); response.setHeader(Content-Disposition, attachment; filename month _sales.xlsx); workbook.write(response.getOutputStream()); workbook.close(); }如果对Apache POI不熟可以用EasyExcel替代它是阿里的一个基于POI封装的工具库Excel导出导入非常方便API设计比直接用POI友好得多。总之导出功能本身不难关键是别为了图省事把数据直接转成CSV有些用户用Excel打开CSV时会遇到中文乱码问题体验极差。5. 部署上线与本地环境避坑指南5.1 本地开发环境搭建JDK、Maven、Node.js在写代码之前先把本地开发环境搭建好。JDK建议使用JDK8或JDK11原因之前说过了SpringBoot2对这些版本支持最好。安装JDK时要注意配置JAVA_HOME环境变量Windows也好macOS也好这一步不能省略否则命令行里java -version会报找不到命令。Maven选3.6以上版本就行。安装后记得配置阿里云镜像不然Maven下载依赖时的速度可能会让人怀疑人生。配置在Maven安装目录下的conf/settings.xml里加入mirror配置指向aliyun仓库。Node.js版本建议用16或18Node20虽然也能用但个别依赖在npm install阶段会报引擎版本警告虽然不阻塞安装但看着实在不舒服。npm install首次安装Vue项目依赖通常需要几分钟这是正常的别在中途强制CtrlC容易把node_modules弄成不完整状态到时候还得删了重装。5.2 MySQL8.0安装配置与初始账号设置MySQL8.0的安装在我之前写过的项目里已经踩过不少坑这里重点提示几个关键点第一是时区。MySQL8.0安装完之后如果连接时报“The server time zone value Öйú±ê׼ʱ¼ä is unrecognized”这个错误说明时区配置不对。可以在连接URL加上serverTimezoneAsia/Shanghai来修正spring.datasource.urljdbc:mysql://localhost:3306/smart_home_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai第二是认证插件问题。MySQL8.0默认的认证插件是caching_sha2_password而某些版本的数据库驱动连接时会报Unable to load authentication plugin这时候要么改MySQL用户的认证方式要么换用mysql-connector-java 8.0以上版本。我推荐后者直接在pom.xml里用最新版本dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependency第三是root账号密码。安装过程会让设置root密码一定记牢。开发阶段为了省事直接把root权限用上没问题但生产环境一定要单独建账号并授予最小权限。5.3 初始化数据库脚本与数据模拟数据库表结构可以通过SQL脚本初始化。把建表语句和基础数据都写在init.sql里项目README文档里附上执行说明。第一次启动项目前先执行这个脚本之后再启动SpringBoot应用就不会报表不存在的错误。有些刚接触数据库的人习惯用Navicat可视化工具建表然后手动敲几条数据进去就开始了。这样开发调试虽然快但换环境的时候怎么办所以init.sql是必须的。这份脚本里除了建表语句还要包含一些基础数据比如默认的管理员账号admin/admin123、几个测试用户、二十几条商品数据。模拟订单数据多少会影响可视化效果如果订单太少折线图会显得很稀疏饼图的占比也不好看。我写了一个临时接口专门用于批量生成模拟数据随机生成日期、商品、数量插入到基础设施的数据表里调试完感觉图表效果不错就把这个接口注释掉了等答辩演示完再删。5.4 后端接口调试技巧Swagger与Postman后端接口写完推荐用Swagger做接口文档和调试。在项目里引入springdoc-openapi依赖SpringBoot2下会自动扫描所有Controller生成接口文档页面浏览器访问/swagger-ui.html就能看到所有接口列表还支持直接发送请求做测试连Postman都省得开了。依赖很简单dependency groupIdorg.springdoc/groupId artifactIdspringdoc-openapi-ui/artifactId version1.7.0/version /dependency用Swagger的好处是前端可以按照文档提前对接联调不用等后端代码全部写完。而且Swagger自动生成的请求参数和返回值结构一目了然比对着代码联调省事太多。Postman的价值在于测试一些需要鉴权的接口。在Authorization里填好token后可以模拟前端各种真实请求场景测试边界条件。比如“查询订单列表时传入不存在的用户id会返回什么”“删除一个已被引用的商品会不会报错”这些都是在Postman里一遍遍试出来的。5.5 前端构建部署与Nginx代理配置联调结束后需要把前端项目打包成静态文件。运行npm run build打包产物在dist目录里里面是一些静态资源文件。接着把dist目录里的文件上传到服务器用Nginx做静态文件服务。Nginx的server配置大致如下server { listen 80; server_name your-server-ip; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }注意location /里的try_files配置。Vue3作为单页应用页面路由是由前端Router管理的直接刷新某个路由地址时Nginx默认会返回404try_files配置就是为了把请求重定向到index.html让前端Router接管页面跳转。后端服务部署时我习惯用以下方式启动nohup java -jar smart-home-system.jar --server.port8080 log.out 21 这样即使SSH连接断开后端服务也能继续运行。日志输出到log.out文件排查问题时直接tail这个文件即可。6. 常见问题与排查技巧实录问题排查这一块我认为是最值得写的因为实际做项目时90%的时间不是在写代码而是在解决各种奇奇怪怪的问题。下面这些是我这套系统开发过程中真实遇到并且成功解决的整理成表格方便查看。现象描述根本原因解决方案前端请求接口时跨域报错后端未配置CORS或配置有误配置CorsConfig同时放行OPTIONS预检请求登录接口一直返回401拦截器拦截了登录方式的OPTIONS请求在拦截器preHandle中对OPTIONS请求直接返回trueLocalDateTime序列化后是数组格式Java8时间类型与JSON格式不兼容在application.yml配置Jackson日期格式处理前端路由刷新页面404Nginx静态文件服务找不到对应路由location /中配置try_files $uri $uri/ /index.htmlMySQL连接报时区错误MySQL8.0默认时区与本地不一致JDBC连接串加serverTimezoneAsia/Shanghai数据库中文乱码字符集配置不对建库时指定utf8mb4连接串设置characterEncodingutf8图形图表显示空白ECharts实例在容器未渲染完成时初始化在nextTick中初始化图表确保容器有宽高删除分类后商品数据消失外键约束导致关联数据被级联删除改用逻辑删除即加delete_flag字段不物理删除6.1 Java8时间类型的序列化问题这是很多用SpringBoot的人都会遇到的一个细节。SpringBoot2默认使用Jackson做JSON序列化Java8引入了LocalDateTime类型之后Jackson不能自动处理默认会把它序列化成类似[2024, 1, 15, 10, 30, 0]这样的数组前端拿到这个数组愣住不动了根本没法用。解决方案是在application.yml里做全局配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 serialization: write-dates-as-timestamps: false这个配置的作用是让LocalDateTime统一以yyyy-MM-dd HH:mm:ss的字符串格式输出前后端衔接起来就顺畅了。6.2 事务失效的几种场景在做下单接口时我踩了一个事务相关的坑。下单逻辑涉及三步创建订单、创建订单项、扣减商品库存这三步必须在一个事务里执行任何一步失败都要回滚。但一开始我在Controller层调用了三个Service方法然后在每个Service方法上都加了Transactional注解结果发现中间出异常时数据还是写进去了。原因很简单Transactional默认只对RuntimeException生效而Controller层调用的三个Service方法分属三个不同的事务它们互不知道对方的存在所以无法保证原子性。正确做法是在Service层写一个完整的下单方法统一定义事务Transactional(rollbackFor Exception.class) public void createOrder(CreateOrderRequest request) { Orders order new Orders(); // ... 创建订单 orderMapper.insert(order); // ... 生成订单项 ListOrderItem items buildOrderItems(request, order.getId()); for (OrderItem item : items) { orderItemMapper.insert(item); // 扣减商品库存 productMapper.decreaseStock(item.getProductId(), item.getQuantity()); } }这里rollbackFor Exception.class也很重要。如果只写Transactional默认只对RuntimeException回滚一旦业务层抛出的是受检异常如IOException事务也不会回滚。实际项目中建议都显式指定rollbackFor Exception.class。6.3 图表不显示的几个排查方向前端图表不显示的排查步骤我总结为三步第一步看ECharts是否正常引入。直接在控制台打印window.echarts出来的结果是undefined就说明引入失败重新检查npm install echarts和import语句。第二步看数据格式。终端用打印响应数据的方式检查后端接口返回的结构是否与图表配置中data属性期望的格式一致。最常见的问题是我的series.data是数字数组但后端返回的是对象数组前端直接把对象传入数据属性导致显示异常。第三步看容器尺寸。如果加了样式还是空白很可能是因为容器在初始化时是display:none状态。这种情况改在nextTick里执行初始化等DOM渲染完成后再创建图表实例。6.4 前后端联调时LONG类型精度丢失这是个Java后端特别经典的问题。SpringBoot后端给前端返回数据时如果字段是Long类型且值超过JavaScript的Number类型最大安全值2^53 - 1前端拿到后会精度丢失。具体表现是数据库中的ID是17592186044416前端拿到的却是17592186044415这种百思不得其解查数据又确实存在这条记录。解决方案有两种。第一种最直接生成唯一ID时不使用数据库自增Long类型改用UUID字符串。第二种通用一些在后端把Long类型的返回值序列化为字符串。Jackson的方式是JsonSerialize(using ToStringSerializer.class) private Long id;如果项目里Long字段比较多就在application.yml中注册一个自定义的ObjectMapper实现全局配置。这里就不再展开解法细节了知道这个坑存在已经是赢了一半。7. 如何把项目改造成真正属于你自己的毕设7.1 项目基础资料的全面替换拿到这类源码的第一个问题就是如何让它看起来不像是从网上下载的。最基础的就是全局搜索替换项目的品牌信息。把代码里的“智能家居”替换成你自己的选题关键词比如“校园二手交易”或“在线图书商城”同时将页面顶部标题栏、Footer信息、登录页Logo、数据库名、项目名全部过一遍。我的操作方法是后端全局搜索原项目名批量修改生成的jar包名和应用名前端全局搜索项目标题修改index.html的title、登录页文案、管理界面菜单名称数据库建库名改成自己项目的名字连接串同步修改README文档重写从项目背景到技术选型到功能列表全部用自己的话描述一遍7.2 代码逻辑的个性化改造方向新增功能建议基础替换只能应付形式如果想让答辩更站得住脚建议做一些功能上的个性化改造。方向有很多这里给出几个低成本但效果显著的方案一新增一个“库存预警”功能。当商品库存低于某个阈值时后台管理页面出现预警提示。逻辑不复杂就是商品表加一个stock字段前端定时轮询调用一个统计接口把库存低于设定值的商品筛选出来。这个功能很容易讲清楚评委听了觉得你确实做了自己的思考。方案二把静态图表改成可交互下钻。点击饼图中“智能音箱”分类下方表格就自动展示该分类下的所有商品销售明细。这需要在前端监听ECharts的click事件然后调用对应接口代码量不大但效果很好。方案三增加一个销售目标对比分析。在销量趋势图里加一条目标销售曲线管理员可以设置月目标系统自动把实际销量与目标对比超过目标的点高亮显示。这种“实际vs目标”的对比在数据分析系统里是常见需求加进去会显得系统更完整。方案四把用户端改为小程序或移动端H5不过这个改动量大只适合时间充裕的同学。普通毕设的话推荐做前面三个小功能就够了。7.3 代码注释与独有设计说明答辩时评委一定会问项目里某些代码为什么这么写。这里不建议把代码注释写得很冗长而是建议在关键模块如事务处理、定时统计任务、数据维度表设计的代码块前写一段清晰的注释说明设计的思路和考虑因素。比如定时统计任务注释可以写“每天凌晨统计前一日订单数据并写入sales_analysis表以减少高峰期实时计算压力”。这种注释在答辩时翻出来给评委看效果远胜于临时用嘴讲。同时建议自己的README文档里单独开一个“核心设计说明”的章节把几个亮点写清楚统计表与明细表分层设计、JWT的无状态鉴权、前端ECharts数据可视化方案、定时统计任务的设计思路。这些内容是你答辩时的底气。8. 写在最后的经验收获整套系统从数据库设计到后端接口开发再到前端页面渲染完整跑通下来最大的收获其实不在代码本身而是理解了一个完整项目是怎么从零到一落地的。数据流向是什么样的前后端怎么对接权限怎么控制统计报表怎么优化这些单看教程永远体会不深亲手做一遍才会形成长时间记忆。很多人做这类系统时执着于“用多新颖的技术”比如非要SpringBoot3 JDK17或者前端非要上Pinia全家桶。我的看法是新技术自然有优点但项目能不能稳定交付才是第一位的。SpringBoot2 Vue3 MyBatis-Plus MySQL8.0这套组合的优势就是“稳”每个组件都有大量生产环境验证出问题也容易解决。再分享一个小技巧开发过程中不要怕写测试接口和模拟数据。数据量越接近真实场景越早暴露性能问题。我就是在生成了几万条模拟订单数据后才发现统计SQL的响应时间明显变慢才决定引入sales_analysis统计表的。如果一开始就只看几条测试数据根本感觉不到性能差异等答辩现场访问量一大就会出问题。希望这篇文字能给正在做类似系统的同学一些参考。系统源码和文档资料的整理已经同步到仓库中可以对照着搭建环境后一步一步实现功能。技术选型没有绝对的对错适合自己的场景、能够稳定交付的方案就是好方案。这套组合后续还可以继续扩展的地方也很多比如接入Redis做热门商品的排行榜缓存加入MQ队列处理高并发下单或者把定时统计任务改成基于离线数仓的T1处理。无论往哪个方向走底层这套SpringBoot2 Vue3 MyBatis-Plus MySQL8.0的骨架都会是你最熟悉的起点。