企业官网建设流程全解析

近两年我做过的后台管理系统，十有八九都跑在 SpringBoot + Vue 这条技术线上，这套组合虽然谈不上稀奇，但放在"智能家居销量数据分析"这个具体业务场景里，很多细节跟常规的 CRUD 后台完全不是一回事。最近刚把一个基于 SpringBoot + Vue 的智能家居销量数据分析管理系统（项目代号 jrabo）从零到一完整落地，包括后端接口、前端页面、数据库表结构、统计分析报表、权限登录这些模块，Java + MySQL + MyBatis 一条链路走通。这篇文章就把整个设计和实现过程掰开揉碎讲一遍，从需求拆解、表结构设计、统计 SQL 写法、图表展示到部署踩坑，尽量给出一份能直接照着做的完整方案。

这套系统解决的痛点很明确：智能家居产品线长、SKU 多、渠道分散，销售数据躺在不同的 Excel 和门店台账里，月底光汇总就要折腾好几天。系统的核心价值是把订单数据统一收口，自动算出销量趋势、品类占比、地区分布、热销单品排名这些指标，让管理层打开网页就能看到今天的销售全貌，而不是等运营手工整理周报。写这篇文章之前我特意翻了一遍网上常见的相似项目，发现大部分都停留在"订单增删改查 + 简单图表"的层面，真正把统计口径和聚合查询讲透的很少，所以我这篇会重点落在数据分析和统计实现上。

如果你正在做类似的管理系统、毕业设计选题是智能家居方向、或者打算从零搭一套带数据看板的 SpringBoot 项目，这篇的内容应该能直接帮你省掉不少弯路。

1. 需求拆解：智能家居销量数据到底要分析什么

拿到"智能家居销量数据分析管理系统"这个项目时，第一件事绝对不是打开 IDEA 建工程，而是先把业务指标想清楚。很多新手上来就建表写接口，结果做完发现统计出来的数据老板根本不想看，因为指标定义错了。我做这套系统时把需求拆成了三个层次：基础数据管理、销售统计分析、系统权限维护。

1.1 核心业务指标与统计口径

智能家居这个品类跟快消品不一样，客单价高、决策周期长、渠道集中，所以分析维度要围绕时间、品类、区域、价格段四个角度展开。我在系统里最终落地的核心指标包括这几类：

• 总销量与总销售额：全渠道订单汇总，支持按日期范围筛选。
• 单品销量排行：TOP 10 热销产品，看哪个 SKU 贡献最大。
• 品类销量占比：智能锁、智能摄像头、智能照明、环境控制、影音娱乐这些大类分别卖了多少。
• 区域销量分布：按省份/城市聚合订单，找出强势市场和空白市场。
• 月度销量趋势：折线图反映一年内的销售波动，判断淡旺季。
• 客单价与订单状态分布：辅助判断渠道质量和售后服务压力。

统计口径这里有一个容易踩坑的点：销量到底是按订单创建时间统计，还是按支付完成时间统计？我调研了实际业务场景后，统一采用"支付成功且未退款"的订单作为有效销量，因为用户下单但未支付对销售分析没有意义。如果系统里涉及退款订单，也需要在 SQL 里加refund_status条件过滤，否则数据会虚高。这点在做统计之前必须先定死，不然后面所有报表都是错的。

1.2 系统角色与功能模块划分

数据分析系统不能只有分析页面，底层必须有订单、商品、用户数据支撑。我按照后台管理系统的通用套路，把功能模块拆成五大块：

• 登录与权限管理：管理员和普通操作员两种角色，管理员可管理用户和商品，普通操作员只能看数据看板和订单台账。
• 商品管理：维护智能家居产品的分类、品牌、型号、单价、上架状态。
• 订单管理：接入/录入销售订单，记录商品、数量、单价、客户信息、订单状态。
• 数据看板：销量总览卡片 + 趋势图 + 品类占比图 + 区域排名。
• 系统管理：操作日志、数据字典、个人密码修改。

菜单结构上我采用的是左侧边栏 + 顶部栏布局，Vue Router 配置动态路由，根据登录角色过滤菜单。这个做法在真实管理系统里最常见，也比把所有菜单都摆出来要专业。

1.3 项目代号 jrabo 与技术约束

标题里这个 jrabo 是项目代号，实际就是管理系统的一个命名标识，不用过度解读。技术约束非常明确：后端 SpringBoot + MyBatis，前端 Vue，数据库 MySQL。这个组合的好处我在下面单独讲，这里只提一点：既然是完整源码项目，代码的可读性和结构规范必须到位，没有人愿意看一个 Service 里堆了 300 行的烂工程。

2. 技术选型回顾：SpringBoot + Vue + MySQL + MyBatis 为什么能凑成一套顺手的组合

这套技术栈现在几乎成了 Java 后台管理系统的"标配"，但熟悉不代表理解。我在这个项目里重新思考了一遍选型问题，每一个选择背后都是真实工程场景的约束。

2.1 SpringBoot 解决掉的整合痛点

如果退回十年前，搞一个 SSM 项目要做的事情包括：配置 Spring 容器、配置 SpringMVC 处理器映射、配置 MyBatis 的 SqlSessionFactory、还要配一堆 XML 扫描路径。SpringBoot 把这些约定全部收敛成了自动配置和起步依赖，我建项目时只需要引spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-j三个核心依赖，再加一个lombok减少样板代码，一个能跑起来的工程就算搭完了。

尤其要夸一下 SpringBoot 的嵌入式 Tomcat，直接把部署步骤从"装 Tomcat -> 丢 war 包 -> 启动"简化成"打 jar 包 ->java -jar启动"。对于管理系统这种内部工具，单 jar 部署是最省心的方式。我后来把前端也打包进src/main/resources/static目录，整个系统变成单个可执行文件，拷到哪都能跑。

2.2 MyBatis 在统计类 SQL 上的优势

ORM 框架的选型曾经在 MyBatis 和 JPA 之间犹豫了一下，最终 MyBatis 胜出的关键原因是：这套系统的核心价值在复杂查询，而不是实体映射。JPA 的强项是对象关系映射和仓库抽象，但遇到"按月份分组统计销售额再关联商品表取名字"这种需求，JPQL 和 Criteria API 写起来非常绕。MyBatis 的 XML 里可以直接写原生 SQL，MyBatis 3 的<foreach>、<choose>、<where>动态标签把条件组合查询做得非常灵活，统计 SQL 的调优也完全在掌控范围内。

不过 MyBatis 也有它的麻烦点，比如返回结果的映射需要多写几个resultMap，表字段下划线和 Java 属性驼峰映射需要在application.yml里开map-underscore-to-camel-case: true。这些细节我在 4.3 节会展开写。

2.3 MySQL 版本选型与关键配置

MySQL 我选的是 5.7 和 8.0 都兼容的写法，5.7 仍然有大量生产环境在用，8.0 的新特性（窗口函数、CTE）虽然好用，但考虑到部署环境不确定性，尽量用通用语法。有一个必须注意的点是MySQL 8.0 的默认认证插件是 caching_sha2_password，而一些旧版本连接驱动不兼容会报 SSL 连接错误。解决方式有两种：在连接 URL 上设置useSSL=false&allowPublicKeyRetrieval=true，或者把用户的认证插件改为mysql_native_password。我实测过，JDBC 8.0.33 版本驱动配allowPublicKeyRetrieval=true是必须加的，否则报错信息会让人摸不着头脑。

连接串我最终用的是这种格式：

jdbc:mysql://localhost:3306/smart_home_sales?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true&zeroDateTimeBehavior=convertToNull

serverTimezone=Asia/Shanghai这个参数千万别省，不然 Java 的 LocalDateTime 查到数据库会差 8 个小时，我第一次联调就栽在这个坑里，前端图表的时间轴整整偏移了半天。

3. 数据库设计：从订单表到统计宽表的一条完整链路

数据库设计决定了统计能写到什么程度。我不赞成把五张表简单堆在一起就开写，而是要先想清楚"数据从哪来、统计到哪一层、报表要什么维度"。这套系统的表结构最终有 8 张核心表：用户表、角色表、商品分类表、商品表、客户表、订单表、订单明细表、销售日汇总表，外加数据字典表。下面挑重点讲。

3.1 核心表结构与字段含义

商品分类表不做特殊处理，就存分类名称、父级 ID、排序号。重点是商品表，智能家居产品的属性差异很大，但销量分析只关心分类、型号、单价、品牌这几个字段，所以我把产品名、型号、品牌、单位、单价、状态作为核心列，不强行做大宽表。

订单主表是整张设计里最要小心的：

CREATE TABLE `sales_order` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `customer_id` bigint(20) DEFAULT NULL COMMENT '客户ID', `order_date` datetime NOT NULL COMMENT '下单日期', `total_amount` decimal(10,2) NOT NULL COMMENT '订单总金额', `order_status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1待支付 2已支付 3已发货 4已完成 5已取消', `pay_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0未支付 1已支付 2已退款', `province` varchar(50) DEFAULT NULL COMMENT '省份', `city` varchar(50) DEFAULT NULL COMMENT '城市', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_order_date` (`order_date`), KEY `idx_order_status` (`order_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='销售订单表';

这里有个细节：为什么订单日期索引单独建，不建复合索引？因为多数统计都先按时间范围过滤，再用order_date做分组截取，单列索引能最大化命中。order_status的索引服务于后台订单筛选。当时也考虑过(order_date, province)复合索引，但发现区域统计的过滤频率低于时间，建了反而浪费空间。

订单明细表设计是自己关联订单表和商品表，每条明细只存商品 ID、购买数量、成交单价。产品单价可能变，所以明细里必须存一份成交单价快照，否则后续历史统计取到的价格全是商品表的当前价，报表会很怪异。

3.2 辅助统计的日汇总宽表设计

光有订单表也能统计，但一个常见问题是：当订单数据量到几十万行，每次 Dashboard 打开都要实时 group by 几千上万条记录，慢查询几乎避不开。我的做法是加一张daily_sales_summary日汇总表，每天按order_date + product_id + province维度聚合一次，把当天的销量、销售额、订单数提前算好存进去。

CREATE TABLE `daily_sales_summary` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `stat_date` date NOT NULL COMMENT '统计日期', `product_id` bigint(20) NOT NULL COMMENT '商品ID', `category_id` bigint(20) DEFAULT NULL COMMENT '分类ID', `province` varchar(50) DEFAULT NULL COMMENT '省份', `total_quantity` int(11) NOT NULL DEFAULT '0' COMMENT '销量', `total_amount` decimal(12,2) NOT NULL DEFAULT '0.00' COMMENT '销售额', `order_count` int(11) NOT NULL DEFAULT '0' COMMENT '订单数', PRIMARY KEY (`id`), KEY `idx_stat_date` (`stat_date`), KEY `idx_product` (`product_id`), KEY `idx_category` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='销售日汇总表';

这种空间换时间的思路对大多数管理系统的数据看板来说都是划算的：汇总表的记录数比订单明细少一个数量级，统计响应时间从几百毫秒压到几十毫秒。我在后台维护了一个定时任务（Spring 自带的@Scheduled），每天凌晨 2 点跑一次，把前一天的订单数据刷进汇总表。同时也提供一个手动触发按钮，免得补录的历史订单没办法及时进报表。

3.3 关于索引和字段类型的心得

几个用血换来的经验直接列出来：

• 订单号虽然不是主键，但经常被拿来精确查询，必须建唯一索引，否则订单详情接口在高并发下可能出现重复数据。
• 金额字段一律用decimal(10,2)，不要用 float/double，否则累计求和出现 588.859999 这种数字时，图表上要多难看有多难看。
• utf8mb4是唯一选择，utf8 存不了生僻字和 emoji，客户姓名偶尔会让人惊喜。
• 所有时间字段默认带 CURRENT_TIMESTAMP，省掉代码里手动 set 的麻烦。

4. 后端实战：销量统计接口与 MyBatis 动态 SQL 的实现细节

数据库设计完就可以写代码了。后端部分我把系统分成了controller / service / mapper三层，尽量保持 MyBatis 的 Mapper 接口和 XML 分离。下面重点讲三类最难写的接口：订单分页查询、统计聚合、Dashboard 看板数据。

4.1 统一返回结构与分页查询

管理系统接口我会统一包装一个 Result 对象，包含code、message、data三个字段，前端 Axios 拦截器里只认code=200才算成功。这样做的好处是异常可以在全局@RestControllerAdvice里兜住，返回格式始终一致。

分页查询我没有直接用 PageHelper，而是要了一个"官方推荐但极容易用错"的插件，差点把统计接口搞出 bug。最终我采用 MyBatis 手写分页的方式：传入 pageNum 和 pageSize，先执行count语句查总数，再执行带 LIMIT 的列表查询。代码交给了 PageInfo 自己组装。分页条件用了<where>动态标签：

<select id="selectOrderPage" resultType="com.jrabo.modules.order.vo.SalesOrderVO"> SELECT o.order_no, o.order_date, o.total_amount, o.province, o.city, c.customer_name, p.product_name FROM sales_order o LEFT JOIN customer c ON o.customer_id = c.id LEFT JOIN order_item oi ON oi.order_id = o.id LEFT JOIN product p ON oi.product_id = p.id <where> <if test="orderNo != null and orderNo != ''"> AND o.order_no LIKE CONCAT('%', #{orderNo}, '%') </if> <if test="province != null and province != ''"> AND o.province = #{province} </if> <if test="status != null"> AND o.order_status = #{status} </if> <if test="startDate != null"> AND o.order_date &gt;= #{startDate} </if> <if test="endDate != null"> AND o.order_date &lt; DATE_ADD(#{endDate}, INTERVAL 1 DAY) </if> </where> ORDER BY o.order_date DESC </select>

结尾日期我用< DATE_ADD(#{endDate}, INTERVAL 1 DAY)而不是<= #{endDate}，这样即使前端只传了"2025-01-15"这种日期字符串，也能把 15 号当天所有订单都查出来。这是做查询接口最容易忽略的边界问题。

4.2 统计类 SQL 的三种典型写法

统计报表接口我按复杂度分了三种实现路径，从简到繁：

第一种：简单分组求和。比如按商品统计总销量，直接用 GROUP BY：

SELECT p.id, p.product_name, SUM(oi.quantity) AS total_sales FROM order_item oi JOIN product p ON oi.product_id = p.id JOIN sales_order o ON oi.order_id = o.id WHERE o.pay_status = 1 AND o.order_status != 5 AND o.order_date BETWEEN #{startDate} AND #{endDate} GROUP BY p.id, p.product_name ORDER BY total_sales DESC LIMIT 10

注意我保留了pay_status = 1和order_status != 5两个过滤条件，这就是一开始敲定的统计口径，任何统计 SQL 都必须带上，要不然退款订单和取消订单会污染榜单。

第二种：时间维度聚合。月度趋势要的结果是['2025-01', '2025-02', ...]和对应的销售额数组，SQL 里用DATE_FORMAT(order_date, '%Y-%m')直接格式化后分组。这个字段在 MySQL 里效率足够，因为已经建了 order_date 索引，5.7 版本下完全可用。

第三种：多条件动态统计。这里用到 MyBatis 的<forEach>和<where>组合。比如区域分布统计，筛选条件可能是若干个省份、一个时间范围、多个商品分类，需要拼出 IN 条件：

<select id="selectProvinceStats" resultType="map"> SELECT s.province, SUM(s.total_quantity) AS total_quantity, SUM(s.total_amount) AS total_amount FROM daily_sales_summary s <where> <if test="startDate != null"> AND s.stat_date &gt;= #{startDate} </if> <if test="endDate != null"> AND s.stat_date &lt;= #{endDate} </if> <if test="categoryIds != null and categoryIds.size() > 0"> AND s.category_id IN <foreach collection="categoryIds" item="cid" open="(" separator="," close=")"> #{cid} </foreach> </if> </where> GROUP BY s.province ORDER BY total_amount DESC </select>

这里直接查汇总表而不是订单表，速度会快很多。用汇总表之后还主动做了聚合下推，把 group by 放在数据库里执行，没有把明细拉回 Java 再 stream 分组，这是统计接口性能的底线。

4.3 MapStruct 和 VO 转换的一些常用做法

很多从 XML 查出来的结果都是List<Map<String, Object>>，我一开始也觉得省事，但项目稍大就发现 Map 的 key 是下划线命名，前端拿到的字段跟后端 VO 不一致，接口文档没法写。这个项目里我把统计结果包装成了固定 VO，比如SalesTrendVO(name, value)、CategoryRankVO(categoryName, sales, percentage)，XML 的resultType直接嵌套 VO 类，MyBatis 自动把total_sales映射到totalSales，前提是开了驼峰映射。

4.4 MyBatis 缓存问题：改动数据后报表不更新

还有一个坑值得单独说：MyBatis 的一级缓存默认开启且作用域是 SqlSession，二级缓存我选择主动关闭。因为统计接口一旦被缓存命中，新录入的订单不会立刻反映到报表里，管理后台最怕的就是"数据看起来没更新"。我确认过application.yml里的配置：

mybatis: configuration: cache-enabled: false map-underscore-to-camel-case: true

关掉二级缓存之后，每次查询都是最新的。代价是性能会有轻微损耗，但对管理系统的数据实时性来说完全值得。如果你确实要缓存统计结果，应该用 Redis 做业务级缓存并设置过期时间，而不是依赖 MyBatis 的缓存机制，这是我在这个项目里最想强调的实践之一。

5. 前端构建：数据可视化与 ECharts 图表的落地过程

后端把接口出完，前端要负责把这些 JSON 变成老板看得懂的画面。Vue 这边我采用的是标准的 Vue 2 + Element UI 组合，不是我不想上 Vue 3，而是考虑到这个项目场景里大量现成的后台管理模板都是 Vue 2 生态，Element UI 的表格、表单、日期选择器开箱即用，团队上手成本低。如果想用 Vue 3 也是完全可行的，逻辑上没有本质差异，只是换成了 Element Plus。

5.1 工程结构与 Axios 封装

前端工程我按标准的 Vite/Webpack 结构组织，src 下分api / assets / components / router / store / views。所有请求统一走封装好的 axios 实例：

import axios from 'axios' const service = axios.create({ baseURL: '/api', timeout: 15000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('jrabo_token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { this.$message.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { this.$message.error('网络异常，请稍后重试') return Promise.reject(error) } )

baseURL 设置成/api是刻意的，配合后端在application.yml里的 context-path 配置，可以避开大部分跨域问题。具体来说有两种方案：后端加@CrossOrigin或者前端走代理。我把前端最终打包进了 SpringBoot 的 static 目录，二者同源，根本不会触发跨域。这种方式对于单体管理系统太友好了，强烈推荐。

5.2 ECharts 在销量看板中的实际应用

数据看板页我放了四个核心图表：

• 销量总览：顶部一行四个统计卡片，用Statistic组件显示今日销量、本月销售额、订单总数、客单价。
• 月度销量趋势：ECharts 折线图，X 轴是月份，Y 轴是销售额，鼠标悬浮显示具体数据。
• 品类占比：ECharts 玫瑰饼图，展示智能锁、照明、监控等品类销售占比。
• 区域销售排行：横向柱状图，前十个省份按销售额排列。

ECharts 的引入按需加载很重要，直接import * as echarts from 'echarts'会把全量图表代码打进包里，首屏体积多出小 1MB。我按官方推荐用了 TreeShaking 的方式：

import * as echarts from 'echarts/core' import { LineChart, PieChart, BarChart } from 'echarts/charts' import { TitleComponent, TooltipComponent, GridComponent, LegendComponent } from 'echarts/components' import { CanvasRenderer } from 'echarts/renderers' echarts.use([LineChart, PieChart, BarChart, TitleComponent, TooltipComponent, GridComponent, LegendComponent, CanvasRenderer])

配图表的代码里有一个容易忽略的点：接口返回的月份或区域名称与图表数据必须一一对应，我在拿到后端数组后会用 JavaScript 的map方法重新处理一遍，生成{ name: item.province, value: item.totalAmount }格式，避免后端字段和图表期望结构不一致。

5.3 权限路由与菜单动态渲染

管理系统的登录和权限我用的方案是：登录后后端返回当前用户角色和一个 token，前端根据角色 ID 生成可访问路由表，用router.addRoutes动态添加。这比把所有路由写在静态文件里更安全，用户没权限的页面即使猜出 URL 也进不去。

侧边菜单则是根据路由表递归渲染成el-menu的el-menu-item和el-submenu。这套机制在 Vue 2 里有一套特别成熟的写法，网上模板一大把，我这边结合项目微调了一下，把菜单实体和后端sys_menu表对应起来，管理员在后台操作菜单时前端刷新就能生效。

5.4 前端开发时的几个调试技巧

Vue 项目在开发阶段跨域是必经的一道坎，我在vue.config.js里配置 devServer 代理，把/api转发到http://localhost:8080，这样前端npm run serve和后端java -jar可以并行开发互不干扰。还有个小技巧：ECharts 图表在 Tab 切换或者窗口 resize 时会偶尔出现空白，需要在activated钩子里调用chart.resize()。另外就是表格分页组件，Element UI 的handleCurrentChange和handleSizeChange都要重新拉数据，切记页码从 1 开始还是从 0 开始前后端要约定好，我这里统一从 1 开始。

6. 部署上线与性能优化：一次把坑踩明白的完整链路

系统写完只是第一步，真正头疼的是部署和优化。这一节整理我在上线过程中遇到的最有价值的几个问题，以及对应的排查和解决方案。

6.1 前端打包与后端集成的两种部署姿势

我实际用了两种部署方式，各有适用场景。方式一是直接把前端dist目录里的文件复制到 SpringBoot 的src/main/resources/static下，重新打包成单个 jar。这是最省事的方式，Linux 服务器上一条nohup java -jar smart-home-sales.jar &就能跑起来，全程不依赖 Nginx。但缺点是想单独更新前端静态资源时，又得重新打包重启应用。

方式二是前端单独部署到 Nginx，后端只跑接口。Nginx 里配一条 location 规则把/api/开头的请求反代到后端端口，其他静态资源直接由 Nginx 负责。前端迭代只需要把新的 dist 文件夹丢上去 reload 即可。我个人的建议是：如果系统使用频率高且团队会频繁改前端，用方式二；如果只是自用或演示，方式一更省心。两种方式我都跑通了，没有遇到不可解决的问题。

6.2 慢查询优化：从 3 秒到 200 毫秒的一次调优

第一次把真实数据灌进去之后，Dashboard 接口慢得让我差点以为统计逻辑写错了。订单表 20 万行，订单明细 80 万行，按月份分组的销售趋势接口跑了近 3 秒。用EXPLAIN分析发现 group by 走了全表扫描，因为订单明细表 order_item 上的 order_id 索引虽然能定位订单，但date_format这种函数导致 order_date 索引失效。

优化的组合拳做了三件事：

• 把按月统计改造为直接查询daily_sales_summary，避免实时 join 大表。
• 在汇总表上建(stat_date, category_id, province)的复合索引，让统计查询直接走覆盖索引。
• GROUP BY 的字段数量和 SELECT 字段尽量一致，避免 MySQL 做额外的 filesort。

调整后接口耗时降到了 200 毫秒以内，效果立竿见影。如果数据量继续涨到千万级，下一步就该考虑分区表或者引入 ClickHouse 了，但那是后话。

6.3 上线后遇到的几个 MySQL 和 SpringBoot 问题

这个清单几乎每个做 SpringBoot 项目的人都会遇到，我直接抄出来供参考：

其中 GROUP BY 报错特别常见，我遇到的是按月统计时 select 里写了DATE_FORMAT(order_date, '%Y-%m')而 group by 里也写了一遍这个表达式，看似一致，但 MySQL 严格模式下仍然可能报错。最稳妥的做法是先单独查出原始字段，再在应用层格式化分组键，或者在 SQL 里用别名并保持 group by 也引用相同表达式。

6.4 给项目加一层简单的操作日志

管理系统上线后，老板最常问的问题是"谁动了数据"。我没有引入重型审计框架，而是用 Spring AOP + 自定义注解实现了一个轻量操作日志功能。核心思路是定义一个@Log注解，标记在 Controller 方法上，AOP 切面在方法执行后把用户 ID、操作模块、操作类型、请求参数、响应状态写入 sys_operation_log 表。这个功能写起来不到 100 行代码，但对系统的可维护性提升非常大，也适合作为项目的一个亮点写进设计说明里。

7. 写在最后：这套系统还能往哪些方向延伸

项目交付之后我自己回头审视了一遍，这套"SpringBoot + Vue + MySQL + MyBatis"的组合做智能家居销量数据分析管理系统，核心优势在于简单、可控、容易复现。对于学生项目、企业内部工具、中小团队的自研数据后台，它都是非常可靠的底盘。不过如果你想把这套系统再往上推一个台阶，我建议在三个方向上做增量扩展。

第一是接入更多数据源。目前的订单数据主要靠手动录入或者简单导入 Excel，后续可以对接电商平台的开放接口，让订单自动同步进系统，再配合消息队列做异步清洗，数据时效性会好很多。第二是引入 Redis 做统计结果的缓存，把 Dashboard 的响应时间进一步压到百毫秒内，同时支持更多并发用户访问。第三是补充一套更完善的报表导出功能，比如把月度趋势、单品排行、区域分布直接导出成 PDF 或 Excel，管理层不用登录系统也能通过邮件接收周报。

我在实际跑这个项目时最深的一点体会是：做一个管理系统，最大的成本永远是需求分析和数据口径对齐，而不是代码本身。技术选型只要遵循"团队熟、生态全、性能够"三个原则就不会出大错，真正决定系统价值的，是你能不能把业务指标定义清楚、把统计结果做准。希望这篇的拆解过程能帮你少走几个弯路，具体实现时有卡壳的地方，对照着数据库脚本和核心 SQL 再捋一遍，基本就能把整个链路串起来了。