SpringBoot+Vue.js大数据可视化系统实战：从数据采集到ECharts大屏

1. 为什么是SpringBoot + Vue.js，而不是其他组合

1.1 技术选型：不是所有大数据项目都需要上Hadoop

我最近刚把一个内部代号叫 c008 的数据分析可视化系统跑通，技术栈就是题目里这套 SpringBoot + Vue.js。做之前我一度纠结，是不是上 Python + Flask + PyECharts 更省事，但真把网约车订单、旅游网站访问日志这类数据放进去之后，发现 SpringBoot + Vue.js 这套组合更贴合中小团队和课程设计的节奏：后端一次写好，前端组件化拖拽页面，ECharts 一把梭。

很多同学一听到“大数据分析”，第一反应就是 Hadoop、Spark、ClickHouse 全家桶。但实际情况是，你处理的数据量可能也就几十万到几百万行，一台 8G 内存的开发机能轻松跑完。这时候上分布式反而是给自己找麻烦。SpringBoot 本身就是一个轻量级服务框架，配合 MySQL、Redis、Elasticsearch，完全能覆盖从数据采集、清洗、存储到指标计算的完整链路。

后端用 SpringBoot，核心理由是生态太成熟了。MyBatis-Plus 操作数据库、Spring Security 或 Sa-Token 做鉴权、XXL-Job 或自带的 @Scheduled 做定时任务、HttpClient 或 Jsoup 拉取数据，几乎所有需求都能找到现成 starter。前端选 Vue.js，理由也很直白：组件化开发效率高，ECharts 和 Element Plus 都是现成的，写一个通用图表组件，后面每个页面复用就行。如果你的项目有明确的答辩、演示或交付期限，这套组合是“最稳的”。

1.2 前后端分离：大数据看板项目最合理的架构

老一代 SpringBoot 项目喜欢用 Thymeleaf 直接在服务端渲染页面，甚至还有人用 JSP。做普通后台管理系统可以，但做数据分析可视化系统就很痛苦。你想在页面上做地图拖拽、图表联动、定时刷新，如果每次交互都刷新整个页面，用户体验基本废了。

我建议从一开始就走前后端分离：SpringBoot 只提供 JSON 接口，Vue.js 独立成前端工程。这样做有几个非常实际的好处：

• 前端开发不需要启动后端，mock 数据就能先画页面；
• 后端接口可以被多个前端复用，比如 Web 端和移动端共用一套 API；
• 部署时可以后端跑 8080，前端由 Nginx 托管，互不干扰；
• 如果答辩现场要展示，前端代码可以直接扔到静态服务器上，演示成本很低。

数据库选 MySQL，做大数据分析演示完全够用。如果涉及全文检索，再引入 Elasticsearch。Redis 用来扛热点数据的缓存，比如首页的累计订单量、在线人数这类指标，没必要每次都查库。系统架构简单画一下就是：数据源（Excel、数据库、接口爬取）-> SpringBoot 定时任务清洗入库 -> MySQL/ES 存储 -> 后端接口聚合统计 -> Vue.js + ECharts 渲染图表。

1.3 这套技术站点的常见组件组合

我见过很多基于 SpringBoot + Vue.js 的毕设和公司内部系统，最后的技术栈几乎都是同一个配方：

这套组合能覆盖绝大部分数据可视化场景，而且不会因为技术太偏导致你出问题后搜不到解决方案。后面几章我会按一个真实项目的数据链路，把每一层的关键代码和踩坑点都讲一遍。

2. 数据层先行：数据怎么采、怎么存、怎么算

2.1 从网约车订单到旅游网站数据，先确定数据源

做数据分析可视化项目，最忌讳一上来就写代码画页面。你连数据长什么样都不知道，图表做出来也是假的。我这次系统的数据源分两类模拟：一类是网约车订单数据，包含订单编号、乘客上下车经纬度、里程、金额、司机ID、下单时间；另一类是旅游网站访问数据，包含用户ID、访问页面、停留时长、来源渠道、访问时间。

这两类数据在网上有大量公开数据集可以下载，也可以用程序模拟生成。如果你做毕设，建议先自己造数据，量级控制在 30 万到 100 万行，既能让系统流畅运行，也能在论文里写“经过百万级数据验证”。造数据的思路很简单：写一个 Java 类，循环插入随机订单，时间字段按月分布，金额字段按正态分布生成，这样出来的图表不会难看。

如果你的系统带“数据抓取”功能，比如抓取一些旅游网站的公开榜单信息，我建议优先使用 HttpClient 或 Jsoup。注意三点：第一，抓取频率不要太快，避免给对方服务器造成压力；第二，只抓公开非敏感信息；第三，抓下来的数据要做清洗，去掉 HTML 标签、空值和重复记录。合规性永远是红线，宁可多写一点免责声明，也不要给自己留风险。

2.2 MySQL、Redis、Elasticsearch 怎么分工

很多新手会把所有数据都塞进 MySQL，等到查询慢的时候才开始头疼。我这次系统的做法是分层存储：

• MySQL 存原始订单和基础业务数据，也是系统的主数据源；
• Redis 存需要高频读取的统计结果，比如“今日订单量”“总营收”“在线司机数”；
• Elasticsearch 存需要全文检索的日志型数据，比如用户搜索关键词、页面访问明细。

有人会问：那 ClickHouse 要不要上？我的观点是，如果单表数据量超过 5000 万，且有大量多维聚合查询，再考虑 ClickHouse。否则 MySQL 加上合理索引，撑住几百万行的聚合查询完全没问题。你要做的是在系统设计时预留数据源切换的接口，而不是一开始就上重型组件。

在实际项目里，我通常把统计逻辑写在服务层，通过一个 MetricsService 统一封装。比如 “getTodayOrderCount” 先从 Redis 查，查不到就走 MySQL 聚合，再回写 Redis，设置 5 分钟过期。这样前端图表轮询的时候，大部分请求都命中缓存，后端压力非常小。

2.3 用 SpringBoot 实现最朴素的 ETL 流水线

数据分析系统的核心是 ETL：抽取、转换、加载。我在这套系统里没有引入 Flink 之类的流式计算框架，因为订单量没到那一步。只用 SpringBoot 自带能力就够：

定时任务用 @Scheduled 注解，固定每天凌晨跑一次全量统计，每 5 分钟跑一次增量统计。数据抓取任务用 HttpClient 拉取结果后，通过 Jackson 解析成 JSON，然后调用 MyBatis-Plus 的批量插入方法保存到 MySQL。转换阶段主要做三件事：字段名统一、单位统一、缺失值处理。

这里分享一个我自己常用的批量插入写法：使用 MyBatis-Plus 的saveBatch，配合rewriteBatchedStatements=true参数，插入 50 万条数据的速度能提升好几倍。JDBC 连接串末尾加上rewriteBatchedStatements=true&useServerPrepStmts=false，这是最容易忽略的优化点。

如果数据里包含中文文本，比如订单备注或用户评论，想分析情感倾向或关键词，可以用 HanLP 分词。SpringBoot 集成 HanLP 很简单，引入依赖后直接调用HanLP.segment(text)，返回词性标注结果。你可以在 ETL 阶段把分词结果存到单独的 keyword 表，这样前端做词云图的时候直接查表就行，不需要每次实时分词。

2.4 数据接口层：给前端提供“已经算好”的指标

后端给前端的数据接口，我强烈建议直接输出聚合后的结果，而不是原始明细。比如前端需要一个“每月订单趋势”折线图，后端就提供一个接口，返回值是[{month: '2024-01', count: 12345}, {month: '2024-02', count: 13456}]。前端拿到数组直接渲染，不需要做任何计算。

这样做的好处是：第一，前端代码简单，不容易出 bug；第二，后端可以做缓存，同一个聚合结果不用重复计算；第三，图表渲染性能高，数据量再大也只是查缓存。接口设计遵循 RESTful 风格，列表接口统一返回分页结构。分页我用的 MyBatis-Plus 内置分页插件，配置一个MybatisPlusInterceptor就好了。

@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination = new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(500L); interceptor.addInnerInterceptor(pagination); return interceptor; }

设置maxLimit是为了防止有人通过改页码参数把全表数据拉走，后端接口安全无小事。

3. Vue.js 可视化模块：不是画个图表那么简单

3.1 大屏布局：先定栅格，再填图表

Vue.js 这套系统里，可视化大屏是最出效果的部分。大屏设计最容易犯的错是：一上来就堆积图表，结果屏幕分辨率一变化，图表全挤在一起。我的习惯是先用 Element Plus 的el-row和el-col布局，把屏幕划分为 12 列栅格，然后在每个栅格里放图表卡片。

比如最典型的数据看板布局是：顶部放标题和时间，中间放一个主地图，两侧放订单趋势和渠道占比，底部放排名列表。对应代码大致这样：

<el-row :gutter="12"> <el-col :span="6"> <TotalCard title="今日订单量" value="12,345" /> </el-col> <el-col :span="6"> <TotalCard title="今日营收" value="¥98,765" /> </el-col> <el-col :span="6"> <TotalCard title="活跃用户" value="3,210" /> </el-col> <el-col :span="6"> <TotalCard title="完单率" value="92.5%" /> </el-col> </el-row>

大屏页面如果用百分比宽度，在 1920 和 1366 分辨率下都会自适应。如果还需要更精细的适配，可以用autofit库，或者给图表外层容器设置固定宽高比，再通过 CSS transform 缩放。我个人的经验是：先保证 1920 设计稿效果好，再兼容 1366，而不是反过来。

3.2 把 ECharts 封装成通用组件

ECharts 是可视化系统的灵魂。但如果每个页面都重新写 option，代码会爆炸。我封装了一个BaseChart.vue，对外只暴露option和height两个 props，内部负责初始化、销毁、窗口自适应，以及监听 option 变化后更新图表。

<script setup> import * as echarts from 'echarts'; import { onMounted, onBeforeUnmount, ref, watch } from 'vue'; const props = defineProps({ option: { type: Object, required: true }, height: { type: String, default: '300px' } }); const chartRef = ref(null); let chart = null; onMounted(() => { chart = echarts.init(chartRef.value); chart.setOption(props.option); window.addEventListener('resize', chart.resize); }); watch(() => props.option, (val) => { chart.setOption(val, true); }, { deep: true }); onBeforeUnmount(() => { if (chart) { window.removeEventListener('resize', chart.resize); chart.dispose(); } }); </script>

这里有个细节：watch第二个参数传true，是让内部做法是整体替换 option，而不是多个 series 叠加。如果你的图表需要数据刷新，建议服务端返回完整 option 结构，前端直接替换，这样不会出现图形残留。

3.3 地图参数与多维下钻联动

数据分析系统里地图是重头戏。ECharts 地图分为三级：中国地图、省级地图、市级地图，通过registerMap注册 GeoJSON 数据。我的做法是在前端 public 目录放一份中国省份 GeoJSON 文件，然后在需要地图的页面中动态获取并注册。

地图下钻最常见的需求是：点击某个省份，右侧图表联动显示该省的订单趋势。实现思路就是给地图绑定点击事件，事件回调里拿到省份名称，调用后端的区域详情接口，更新旁边的图表组件。注意 map 组件的 name 映射需要和后端返回的省份名称完全一致，否则点击没反应。

如果后端数据里只有经纬度坐标，没有区域名称，可以使用百度或高德的逆地理编码接口。但这里有一个坑：地理编码接口有并发限制，批量转换几千个坐标会触发风控。建议在数据清洗阶段分批处理，并且把结果缓存到数据库，避免每次打开页面都调外部 API。

3.4 实时刷新：轮询、SSE 还是 WebSocket

看板类页面通常需要数据自动刷新。最简单的方案是setInterval轮询，每 5 秒请求一次统计接口。这种方式对后端压力不小，但胜在实现简单，适合数据量不大、接口响应快的系统。

如果数据更新频繁且想要更优雅，推荐 Server-Sent Events（SSE），它和 WebSocket 的核心区别是 SSE 是基于 HTTP 的单向推送，后端定时推送数据到前端，前端不需要自己维护连接状态。SpringBoot 实现 SSE 非常方便，用SseEmitter配合定时任务就能做。我在系统里用 SSE 推送在线用户数和订单热度，浏览器原生EventSource就能接收，不需要额外依赖。

WebSocket 适合双向通信，比如用户在地图上框选区域，后端实时返回筛选结果。但 WebSocket 的调试成本比 SSE 高，我建议中小项目优先用轮询或 SSE，除非有明确需求再上 WebSocket。

4. 后端 API 与安全治理：接口、鉴权、跨域、XSS、文件上传

4.1 统一返回结构和全局异常处理

前后端分离项目最重要的一件事是定义统一返回体。我见过太多项目，有的接口返回{code: 0, data: null}，有的返回{success: true, message: ""}，前端联调时一堆判断。我的做法是定义Result<T>，包含code、message、data、timestamp四个字段。后端所有 controller 都返回这个对象。

全局异常处理用@RestControllerAdvice捕获业务异常、参数校验异常和系统异常。这样做的好处是前端只用判断code是否为 200，其他情况都弹错误提示，不需要每个接口单独处理异常。对于大数据分析系统，最常见的异常是SQLSyntaxErrorException和OutOfMemoryError，前者通常因为动态排序字段拼 SQL 导致，后者往往因为一次性查出全部明细。全局异常里可以额外记录错误日志，方便线上排查。

4.2 鉴权：用 Sa-Token 还是 JWT

数据分析系统一般有登录页和管理后台，接口不能裸奔。我建议在 SpringBoot 里集成 Sa-Token，理由是它比 Spring Security 轻，比手写 JWT 拦截器省事。Sa-Token 支持登录、踢人下线、权限注解，对中小项目足够。

如果坚持用 JWT，你一定要自己处理 token 过期、刷新、注销这几个痛点，写出来容易，但踩坑会很多。Sa-Token 默认把会话信息存在内存或 Redis 中，天然支持注销，前后端逻辑也简单：前端登录后拿到 token 存到 localStorage，每次请求在 axios 拦截器里带上Authorization: Bearer xxx，后端只要一个注解@SaCheckLogin就能保护接口。

需要注意的是，token 不要放到 URL 参数里，否则会出现在 Nginx 访问日志中，存在泄露风险。统一放在 header 里是标准做法。另外，对于可视化大屏页面，如果要在展厅长期展示，建议单独开一个只读的免登录接口，并且用 IP 白名单限制访问来源，而不是直接把鉴权去掉。

4.3 跨域问题：CORS 配置的三个坑

SpringBoot 后端跑 8080，Vue 前端跑 5173，联调时必遇跨域。第一个坑是：自定义 header 没在 CORS 配置里放行，导致请求发不出去；第二个坑是：允许了所有来源*，但前端在携带凭证时浏览器直接拒绝；第三个坑是：过滤器链顺序不对，导致网关层的 CORS 配置没生效。

我这套系统的解决方案是后端全局配置 CorsFilter，同时允许来源、方法、请求头都白名单化：

@Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); config.setMaxAge(3600L); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); }

注意addAllowedOriginPattern("*")和addAllowedOrigin("*")的区别：前者可以配合allowCredentials(true)使用，后者不行。如果前端用了withCredentials: true，必须用allowedOriginPatterns。

4.4 上传 PDF 时的 XSS 攻击：全局过滤器怎么处理

搜索热词里有一个很典型的场景：“springboot项目全局过滤器处理上传pdf文件时xss攻击”。很多人以为 XSS 只发生在表单输入，忽略了文件上传场景。实际上，如果允许用户上传 PDF 或者 HTML 文件，恶意用户可以上传一个包含脚本的文件，如果系统直接通过预览接口回显，脚本就可能在前端执行。

我的做法是写一个全局过滤器，拦截所有请求体中的特殊字符，统一把<script>、javascript:等危险内容转义。上传文件时，对扩展名做白名单校验，并且用随机文件名重新存储，不保留原始文件名。如果业务必须保留原始文件名，就在返回响应用户的时候先做 HTML 编码。对于上传 PDF，服务端只保存文件，不解析内容，预览走单独的只读接口，设置Content-Disposition: inline并且限制响应头X-Content-Type-Options: nosniff。

这里再提一个容易忽略的点：文件上传大小限制。SpringBoot 默认 1MB，大数据系统的报表 PDF 经常几 MB，需要设置spring.servlet.multipart.max-file-size=20MB和max-request-size=50MB。如果你想把文件存到对象存储，而不是本地磁盘，推荐集成 MinIO。MinIO 在 SpringBoot 里使用非常简单，官方提供 Java SDK，上传成功后返回一个访问 URL，项目重启后文件不丢失，比磁盘存储靠谱多了。

4.5 分页插件使用：别让 pageNum 和 pageSize 变成安全隐患

分析系统里列表页特别多，比如订单明细表、用户访问记录。我前面提到 MyBatis-Plus 分页插件，这里展开聊一下。基本用法是：

Page<UserVisit> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<UserVisit> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(UserVisit::getUserId, userId); wrapper.orderByDesc(UserVisit::getVisitTime); IPage<UserVisit> result = userVisitMapper.selectPage(page, wrapper);

分页插件会在执行前自动拦截 SQL 并拼上LIMIT，非常方便。但有两个坑：第一，排序字段如果是前端传进来的字符串，合法性和白名单校验一定要做，否则存在 SQL 注入风险；第二，深分页会变慢，比如跳到第 1000 页，MySQL 要扫描前 10000 行再丢弃，解决办法是用子查询或游标分页，这个我在后面性能章节会讲。

5. 大数据量场景下的性能优化实战

5.1 慢查询定位：先开日志，再优化

系统上线后最怕的就是图表加载转圈。我当时的订单表涨到 80 万行之后，首页趋势图接口从 100ms 变成了 2 秒。我做的第一件事不是加缓存，而是打开 MySQL 慢查询日志，看看到底慢在哪。

在 SpringBoot 的application.yml里配置 MyBatis-Plus 打印 SQL，或者把连接串加profileSQL=true。我发现慢查询基本集中在两处：一是按时间范围统计订单金额的 group by 查询，二是按城市关联维表聚合。前者问题在时间字段没加索引；后者问题在关联查询没有合适的索引。

定位慢查询的关键是看执行计划。MySQL 的EXPLAIN会告诉你查询走了全表扫描还是索引扫描，我当时的 order 表时间字段没有索引，直接sql改ALTER TABLE ... ADD INDEX idx_create_time，查询时间立刻降了一个数量级。这个步骤没法省，不要凭感觉加索引，一定要看执行计划。

5.2 索引设计与 Redis 缓存：两个性价比最高的优化

对分析型查询来说，索引设计要遵循“最左前缀”原则。比如经常用city_id和create_time一起查询，那就要建联合索引(city_id, create_time)，而不是分别建两个单列索引。这个原则看起来简单，但我见过非常多项目因为索引顺序建反，查询依然很慢。

缓存方面，我说的不是简单地用 RedisTemplate 存字符串，而是“两级缓存”思路：一级是本地 Caffeine，二级是 Redis。像“今日总营收”这种指标，1 秒内可能被大屏轮询请求好几次，每次都查 Redis 也有网络开销。用 Caffeine 做本地缓存，能命中直接把结果返回，只有本地缓存过期才查 Redis，最后才查 MySQL。SpringBoot 里引入caffeine很简单，配置一个CacheManager就可以。

对于图表数据，Redis 缓存的值建议使用 JSON 字符串而不是 Java 对象，因为前端拿到的本来就是 JSON，省去了序列化开销。同时设置合理的过期时间，趋势图可以缓存 10 分钟，实时订单数缓存 30 秒，避免数据太旧影响决策。

5.3 深分页优化：从 LIMIT 100000, 20 说起

如果你的系统里做了一张大表的分页列表，用户翻到后面几页就会明显变慢。问题出在LIMIT 100000, 20依旧要扫描前 100000 行。我处理过的最好评方案是“游标分页”：只记录上一页最后一条记录的 id，下一页查询条件加上WHERE id > lastId ORDER BY id LIMIT 20。

但游标分页不适合随机跳页，比如用户想直接跳转到第 5000 页。对于分析系统，我倾向于不提供总页数跳转，而是提供“加载更多”按钮。这样既保住用户体验，又避免了深分页性能问题。如果产品非要跳页，可以用延迟关联的写法：

SELECT * FROM order_info t JOIN (SELECT id FROM order_info ORDER BY create_time DESC LIMIT 98000, 20) tmp ON t.id = tmp.id

子查询先只查主键范围，再回表取完整数据，比直接全字段 limit 快得多。这个优化在看板列表、订单明细场景下非常实用。

5.4 异步化：统计报表不再阻塞主流程

一个数据分析系统里，有很多统计接口计算量大，但前端并不需要实时拿到结果。比如“导出月度运营报表”，用户点击按钮后，前端只需要知道“任务已提交，稍后下载”。这种场景不该用同步接口，而是把计算任务丢到线程池异步执行，返回一个任务 ID。前端轮询任务状态，完成后显示下载链接。

SpringBoot 里用@Async注解就能把方法丢进线程池，但要注意两点：第一，@Async只有在通过 Spring 代理调用时生效，同类内部调用无效；第二，默认线程池很小，需要手动配置核心线程数和队列容量，否则高峰期任务堆积。

我用的是自定义线程池，核心线程数设置为CPU核心数 * 2，队列容量 1000，拒绝策略采用CallerRunsPolicy。分析任务里如果有大量独立的统计项，还可以用CompletableFuture并行执行，比如同时查订单表、司机表、用户表，全部完成后再组装结果。实测下来，原本 4 秒的聚合接口能压到 1.2 秒左右。

5.5 一次优化对比：从 4 秒到 200ms 的过程

这个章节光讲理论不够，我说一个真实的优化记录。首页加载大屏，总共有 6 个图表接口，第一次打开时全部请求并发打到后端，MySQL 直接被拖到 CPU 100%。优化分了三步：

1. 给时间字段和城市字段加上联合索引；
2. 在网关层做接口合并，把 6 个接口合并成 1 个“大屏初始化”接口，前端一次请求拿到所有数据；
3. 对聚合结果做 Caffeine + Redis 本地内存缓存，缓存时间 5 分钟。

优化后，MySQL 的 QPS 从几百降到了几十，接口响应时间从 4 秒降到了 200ms 以内。前端打开页面几乎是秒开。这件事教育我：大数据可视化系统的瓶颈，很多时候不在“大数据”，而在“大量并发请求同一个统计结果”。缓存是性价比之王。

6. 从编码到部署：IDEA、Docker、Nginx 全流程

6.1 IDEA 创建 SpringBoot 项目与多环境配置

不少人卡在第一步：用 IDEA 新建 SpringBoot 项目。其实现在用 Spring Initializr 很无脑，选好 Spring Boot 版本，勾选 Web、MySQL、Redis 依赖，点下一步就行。但版本不要选最新，更不要选 3.0 以上的，除非你已经很熟悉 Jakarta API 的改动。我建议用 2.7.18 这个版本，资料多、组件兼容性好，是当前最稳的稳定版本。

项目创建完，第一件事就是拆分多环境配置。我不喜欢把数据库地址、Redis 密码写在代码里，所以习惯这么做：application.yml放公共配置，application-dev.yml放本地开发配置，application-prod.yml放生产配置。启动时通过spring.profiles.active=prod指定环境。

还有一个和标题热搜相关的点，就是 yml 配置里的随机端口。如果你开发时老是被端口占用逼疯，可以这样写：

server: port: ${SERVER_PORT:8080}

如果本地环境变量设置了SERVER_PORT就优先用它，否则默认 8080。IDEA 的 Run Configuration 里可以给每个启动类单独设环境变量，这样同时启动多个项目也不会端口冲突。

6.2 Vue.js 前端打包与 history 路由部署

前端工程开发完只是第一步，部署才是重头戏。Vue.js 项目默认是 history 路由，直接扔到 Nginx 后会出现刷新页面 404 的经典问题。原因很简单：前端路由是前端自己管理的，Nginx 找不到对应的文件时，必须把请求 fallback 到 index.html，然后由前端路由接管。

Nginx 配置核心就这一段：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }

构建前端的时候注意，Vite 默认资源路径是/，如果部署在域名子路径下，需要在vite.config.js里设置base: '/your-app/'，否则 JS 和 CSS 全部 404。这是我帮别人排查过最多的问题。

接口地址不要写死。我习惯在前端用环境变量区分开发和生产环境，.env.development里写VITE_API_BASE_URL = 'http://localhost:8080/api'，.env.production里写VITE_API_BASE_URL = '/api'。生产环境由 Nginx 反代到后端接口，这样浏览器始终访问同源地址，又少了一层跨域问题。

6.3 Docker Compose 编排，一键启动前后端

部署环节我强烈推荐 Docker Compose。一个docker-compose.yml文件定义 MySQL、Redis、后端服务、前端 Nginx 四个容器，在任何一台有 Docker 的机器上都能一键启动。我这次项目的编排大致是这样：

version: '3' services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: c008_analysis volumes: - ./data/mysql:/var/lib/mysql ports: - "3306:3306" redis: image: redis:7-alpine ports: - "6379:6379" backend: build: ./backend depends_on: - mysql - redis environment: SPRING_PROFILES_ACTIVE: prod SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/c008_analysis SPRING_REDIS_HOST: redis ports: - "8080:8080" frontend: build: ./frontend ports: - "80:80"

后端 Dockerfile 就是基础 Java 镜像加java -jar。前端 Dockerfile 先npm run build，然后用 Nginx 镜像托管 dist 目录。这里有个小细节：启动后需要看日志确认后端有没有连上数据库，如果 MySQL 初始化还没完成，SpringBoot 启动会直接失败，可以在 compose 里加depends_on的同时设置 healthcheck，或者后端启动重试几次。

6.4 项目调试与常见工具折腾记录

最后聊聊热搜里那几个开发期折腾人的问题。比如“vue.js devtools 插件为什么打不开了”，我遇到过很多次，大部分情况是浏览器版本更新后插件权限设置变了，或者插件只支持本地开发环境，在线上页面会显示未授权。解决办法是到扩展程序管理页确认插件已启用，并且在浏览器地址栏输入chrome://extensions/，把“允许访问文件网址”和“允许此扩展程序读取更改历史记录”都打开。

还有“将 springboot jar 反编译成项目”，这个需求经常出现在接手老项目没有源码的场景。常用的工具是 CFR 或者 Procyon，命令行直接解压 jar，反编译 class 文件。但反编译出来的代码只能参考，注释全部丢失，泛型和 Lambda 可能还原得不准确，不要指望能直接编译回原项目。

“SpringBoot Banner 生成器”倒是很简单，我一般用在线 ASCII Art 生成一个 banner.txt，放到src/main/resources目录下，启动时就会显示个性化欢迎信息。这个纯粹是锦上添花，但答辩和分享时还挺有意思。

如果你在 IDEA 里使用 Qoder 这类 AI 插件调试 SpringBoot 应用，需要先确保插件的语言服务器和 Spring Boot 调试端口兼容。最简单的方式是安装插件的官方扩展，不要同时开多个调试工具。

结尾：一点个人体会

这套 SpringBoot + Vue.js 大数据分析与可视化系统，前后端加起来不到一万行代码，撑住了百万级数据处理、大屏展示、权限管理、文件上传这些常见需求。我的最大体会有三个：

第一，不要迷信高深架构，几十万数据量老老实实用 MySQL + Redis + 定时任务就能跑得很好；第二，前后端联调时统一接口规范比写代码本身更重要；第三，大数据可视化项目最核心的不是图表多花哨，而是数据准确、加载够快。希望这篇文章能帮你把 c008 这种项目做得比大部分人更扎实。如果你在实践里碰到别的坑，欢迎在评论区一起聊聊，毕竟这种系统的坑，真是踩过才知道。