SpringBoot+Vue二手房价分析可视化系统全栈开发实战-嵌云网-嵌入式AI开发资源站

SpringBoot+Vue二手房价分析可视化系统全栈开发实战

要上进的柯同学·2026-09-21·阅读 21 GEO检测（免费）

SpringBootVue二手房价分析

|难度：普通|阅读约 44 分钟

二手房价分析可视化，听起来像一个常见的课程设计题目，但真正动手做下来，我发现这个项目的难度被很多人低估了。它牵扯到的不仅仅是一个SpringBoot后端加一个Vue前端，而是一条完整的数据链路：房源数据从哪来、怎么清洗、怎么存、后端怎么聚合统计、前端怎么用图表把这些数字讲成故事。我前前后后花了三周才把这套"springboot+vue的二手房价分析可视化系统"跑通，期间光是数据格式就折腾了不少时间，更别提各种前后端联调的细节。这篇文章我就从零开始，把整个设计和开发过程掰开揉碎讲清楚，给准备做类似系统或者想入门全栈实战的读者一个完整的参考。

我尽量按真实项目推进的时间线来讲，先分析需求，再定技术选型，然后是数据采集、后端接口、前端可视化，最后是踩坑总结。中间会穿插大量实际用到的代码片段和配置，方便你直接参考。

1. 这个系统到底要解决什么问题：二手房信息的"看不全"与"看不懂"

先说需求。市面上已经有安居客、贝壳这类平台，用户想查某个小区的挂牌价、成交价并不难，难的是什么呢？是横向比较和趋势判断。举个实际场景：你想在某个城市买二手房，打开平台看到的是一个个孤立的房源卡片，但这些信息是碎片化的——某个区的均价到底是多少？最近半年价格是涨是跌？哪个商圈性价比最高？这些问题平台上没有一个直观的答案。这就是二手房价分析可视化系统的核心价值：把零散的房源数据聚合起来，用统计和图表回答"整体行情怎么样"。

我当时做这个系统时，把需求拆成了四个核心模块：

数据管理：后台维护城市、区域、板块、小区以及房源的基础信息，支持对房源数据的增删改查。
价格分析：按区域、按小区维度计算平均单价、总价分布、环比涨跌幅，输出结构化的统计数据。
可视化大屏：用地图展示不同区域的房价热力分布，用折线图展示价格走势，用柱状图对比各区域均价。
用户查询：支持按区域、总价段、户型等条件筛选房源，并展示筛选结果的统计摘要。

这个定位决定了系统的技术形态：前端需要一个能承载地图和多种图表的SPA页面，后端需要提供能够高效处理聚合查询的接口。SpringBoot加Vue的组合在这里几乎是顺理成章的选择，后面我会详细说为什么。

需求分析阶段还有一件容易被忽略的事：明确数据量级。拖拽可视化类系统的性能瓶颈往往不在并发，而在单次聚合查询的数据规模。我当时设计的爬虫抓取了约两万条房源记录，MySQL存储完全没压力，但如果后续扩展到百万级，聚合查询的SQL优化思路就完全不一样了。建议开发前先想清楚自己的数据量级，这直接决定技术方案的复杂度。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 技术栈定型的理由：SpringBoot负责"算得动"，Vue负责"看得懂"

这套系统的技术选型其实很多同学问过我：为什么不用传统的JSP加jQuery？为什么不上SpringCloud微服务？答案很实在。JSP模板渲染的方式在数据可视化场景下非常吃力，图表交互、局部刷新、异步加载，每一件事都在和页面生命周期做斗争。而微服务对单机单库的毕设或个人项目来说纯属过度设计，徒增部署和调试成本。SpringBoot加Vue前后端分离，恰好落在"工程复杂度适中"和"技术栈有含金量"的平衡点上。

2.1 后端为什么选SpringBoot

SpringBoot的核心价值是约定优于配置，这对快速搭建RESTful API特别友好。我不需要像SSM时代那样写一堆XML配置，只需要依赖Spring Initializr生成工程骨架，加几个注解就能启动一个内嵌Tomcat的Web服务。实际开发中我用的关键组件如下：

组件	作用	备注
Spring Web	提供RESTful接口支持	和Vue前端通过JSON交互
MyBatis-Plus	数据库ORM	自带分页插件和条件构造器，减少SQL编写量
MySQL	持久化存储	存储房源和统计结果
Lombok	简化实体类	减少getter/setter样板代码
Validation	参数校验	后端接口入参统一校验

有人可能会问，直接用JdbcTemplate行不行？可以，但MyBatis-Plus在开发统计类聚合接口时优势很明显。比如说区域均价的查询，用LambdaQueryWrapper就能拼出WHERE条件，配合分页插件可以直接返回IPage对象，省去手写PageHelper配置的麻烦。

2.2 前端为什么选Vue

Vue在可视化项目里的核心优势是响应式数据绑定和组件化开发。图表组件（ECharts、AntV）通常都封装为Vue组件，数据和配置项通过props传入，图表实例通过ref管理，写起来非常顺手。我把前端拆成了这几个模块：

登录与权限控制模块：路由守卫拦截未登录用户。
可视化大屏模块：整合地图、折线图、柱状图、数据卡片。
房源列表模块：支持条件筛选和分页浏览。
后台管理模块：房源数据的CRUD操作。

Vue的工程化工具链也成熟，Vue CLI或Vite创建项目，Axios做HTTP请求，Vue Router管理路由，Pinia或Vuex管理全局状态。我这里用的Vue2加Vue CLI，原因很实际：ECharts的很多旧版本教程都基于Vue2，网上能搜到的踩坑案例也最多。如果你是自己写新项目，直接上Vue3加Vite也可以，组件写法差别不算大。

技术选型阶段还有一个决定要提前做：前端UI组件库。可视化大屏类项目常用的UI库包括Element UI和Ant Design Vue，我选的是Element UI。原因不是它比Ant Design Vue好，而是它的表格、表单组件和Vue2的配合文档更全，和ECharts联动的案例也多。事实证明这个选择减少了后期的联调成本。

3. 数据采集与清洗：一套可用数据是可视化系统的命根子

可视化系统的成败，八成取决于数据质量。很多同学在开发阶段用Mock数据，页面效果做完后才发现真实数据一接进来，各种格式不匹配、空值、异常值全部冒出来。我在这个项目里专门预留了一周时间处理数据问题，这一段我详细说说。

3.1 数据采集的思路与合规边界

房源数据的来源通常是公开的房产信息平台。严格来说，这些平台的数据受版权保护，所以采集行为要控制频率、控制字段范围，并且只用于个人学习研究。我的做法是写了一个Java爬虫，用HttpClient请求列表页和详情页，解析HTML中的结构化数据字段，比如小区名、区域、总价、面积、单价、户型、朝向等。

爬虫设计的关键参数：

java复制// 请求头伪装成浏览器，降低被拦截概率
httpGet.setHeader("User-Agent", "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36");
httpGet.setHeader("Referer", "https://www.example.com/");
// 请求间隔建议至少2秒，避免对目标服务器造成压力
Thread.sleep(2000 + new Random().nextInt(1500));

更稳妥的方式是找政府或研究机构公开的统计数据，但颗粒度通常到不了小区级。如果是做毕业设计，我建议优先用爬虫抓取几百条到几千条数据训练链路即可，重点在系统功能本身，不用追求数据量。

3.2 数据清洗：异常值比缺失值更危险

原始数据里有不少脏数据，比如"面积"字段出现"暂无数据"的字符串，或者个别房源挂牌价明显高于市场价（例如同一小区其他房源单价1万，它标了10万）。清洗逻辑我分了三步：

格式统一：把"暂无数据"、"面议"这类非数字字符串过滤掉，使用正则提取数字。
异常值剔除：对单价做3σ原则过滤，即超出平均值±3倍标准差的数据直接删除。
字段补全：对缺失的经纬度信息，通过调用逆地址解析接口补齐，用于地图热力图的打点。

这里要重点提醒一下异常值处理。我在第一版里只是简单地把空值填充为0，结果地图上出现了大量坐标在(0,0)的点，热力图上看起来就像在海上开了一个巨大的红色漩涡。后来改用3σ过滤，又加上了经纬度合法性校验（经度范围70-140，纬度范围15-55），这个问题才彻底解决。

3.3 数据库表结构设计

数据库设计直接影响后面统计接口的复杂度。我设计了四张核心表：

sql复制-- 区域表
CREATE TABLE region (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  city VARCHAR(50) NOT NULL,
  region_name VARCHAR(50) NOT NULL
);

-- 小区表
CREATE TABLE community (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  region_id BIGINT NOT NULL,
  community_name VARCHAR(100) NOT NULL,
  avg_price DECIMAL(10,2)
);

-- 房源表
CREATE TABLE house (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  community_id BIGINT NOT NULL,
  title VARCHAR(200),
  total_price DECIMAL(10,2) NOT NULL,
  area DECIMAL(10,2) NOT NULL,
  unit_price DECIMAL(10,2) NOT NULL,
  room_count INT,
  hall_count INT,
  orientation VARCHAR(20),
  floor VARCHAR(50),
  publish_date DATE,
  create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 价格记录表（用于走势分析，按周/月归档均价）
CREATE TABLE price_history (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  region_id BIGINT NOT NULL,
  avg_unit_price DECIMAL(10,2) NOT NULL,
  stat_date DATE NOT NULL
);

price_history这张表是我后来加的，原因很直接：如果走势图的数据每次都靠实时聚合所有房源，接口响应时间会随着数据量增长越来越慢。定时任务每天把当天各区域的平均单价算好存进去，查询走势图时只需要查这张按日期排序的表，性能会好很多。

4. 后端设计与核心接口：统计分析不是简单的SELECT AVG

后端设计上，我遵循了常见的Controller-Service-Mapper三层结构。Controller层只负责接收参数和返回结果，Service层做业务逻辑和聚合计算，Mapper层对应具体的SQL操作。这个分层在项目初期会让人觉得多此一举，但到后面加需求、调Bug时，你就能体会到它的价值——每一层都可以单独测试，不会牵一发动全身。

4.1 统一响应结构

前后端分离项目里，接口返回格式必须统一。我定义了一个Result<T>类：

java复制@Data
public class Result<T> {
    private Integer code; // 200成功，500失败
    private String message;
    private T data;

    public static <T> Result<T> ok(T data) {
        Result<T> r = new Result<>();
        r.setCode(200);
        r.setMessage("success");
        r.setData(data);
        return r;
    }
}

别看这个类简单，它避免了无数次前后端联调时"我说返回的是Java对象，你说要的是JSON"的扯皮。所有接口一律返回Result，前端Axios拦截器里统一判断code，报错时统一弹提示，代码会整洁很多。

4.2 区域均价统计接口的设计

区域均价的SQL不能简单地SELECT AVG(unit_price)，因为不同区域不同小区的房源数量差异很大，直接平均会被某个挂牌特别多的超高价小区带偏。我最终采用的是按小区均价加权平均的方案，先查每个小区的均价，再按小区数量做加权：

java复制@Override
public List<RegionPriceVO> getRegionAvgPrice() {
    // 1. 查询所有小区的均价
    List<CommunityAvgPrice> communityList = baseMapper.selectCommunityAvgPrice();
    // 2. 按区域分组聚合，计算加权均价
    Map<Long, List<CommunityAvgPrice>> regionGroups = communityList.stream()
            .collect(Collectors.groupingBy(CommunityAvgPrice::getRegionId));
    List<RegionPriceVO> result = new ArrayList<>();
    regionGroups.forEach((regionId, list) -> {
        BigDecimal avg = list.stream()
                .map(CommunityAvgPrice::getAvgPrice)
                .reduce(BigDecimal.ZERO, BigDecimal::add)
                .divide(BigDecimal.valueOf(list.size()), 2, RoundingMode.HALF_UP);
        result.add(new RegionPriceVO(regionId, avg));
    });
    return result;
}

如果你只是简单地SELECT AVG(unit_price) FROM house WHERE region_id = ?，同一区域内的房源数量不均衡会导致统计偏差，比如某个小区放盘量特别大，它的价格水平会主导整个区域均价。有一些真实的房源平台对小区均价的定义也不一样，有的用中位数，有的用加权平均，所以这里必须想清楚自己系统的口径，并在前端页面上标注清楚。

4.3 环比涨跌幅的计算

环比涨跌幅指的是本月相对上月的价格变化比例，计算公式是（本月均价 - 上月均价） / 上月均价 × 100%。这里有个细节：如果从原始房源表里分别查两个月的均价，会因为每月房源构成不同而产生误差。更合理的做法是使用price_history表，它记录的是"同一批样本范围"的统计值，跨期对比才有意义。

我的实现逻辑是这样的：

java复制public Map<String, Object> getRegionTrend(Long regionId, String startDate, String endDate) {
    // 查询时间范围内每周的价格记录
    LambdaQueryWrapper<PriceHistory> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(PriceHistory::getRegionId, regionId)
           .between(PriceHistory::getStatDate, startDate, endDate)
           .orderByAsc(PriceHistory::getStatDate);
    List<PriceHistory> historyList = priceHistoryMapper.selectList(wrapper);

    // 分别取最后一条和倒数第二条计算环比
    BigDecimal latestPrice = historyList.get(historyList.size() - 1).getAvgUnitPrice();
    BigDecimal prevPrice = historyList.get(historyList.size() - 2).getAvgUnitPrice();
    BigDecimal changeRate = latestPrice.subtract(prevPrice)
            .divide(prevPrice, 4, RoundingMode.HALF_UP)
            .multiply(BigDecimal.valueOf(100))
            .setScale(2, RoundingMode.HALF_UP);
    // ...
}

这里我用的是BigDecimal而不是double，是因为涉及到金额计算的精度要求很高。用double做除法容易出现0.000000001这样的浮点误差，虽然前端展示时看不出来，但一旦用这个值做排序或者区间判断，就会出现莫名其妙的Bug。

4.4 MyBatis-Plus分页与条件查询

房源列表接口需要支持按区域、总价区间、户型条件组合筛选，还要分页。MyBatis-Plus的分页插件配置很简单：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

然后在Service里用LambdaQueryWrapper拼接条件即可。注意，总价区间查询有一个容易出错的地方：数据库里存的是total_price，用户输入的是"总价300万以下"或者"500-800万"，不要在业务代码里多次判断边界值，而是直接用ge和le组合：

java复制LambdaQueryWrapper<House> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(StrUtil.isNotBlank(region), House::getRegionName, region);
wrapper.between(totalPriceMin != null && totalPriceMax != null,
        House::getTotalPrice, totalPriceMin, totalPriceMax);

空值判断一定要放在between的第一个参数条件里，否则用户只传了最低价没传最高价时，totalPriceMax为null，就会产生意外的SQL结果。这种Bug最隐蔽，前端传参校验通常不会拦住这种情况，必须后端做兜底。

5. Vue前端与可视化呈现：让价格走势自己说话

前端部分是这个项目最直观的成果展示。一个数据可视化系统，页面做得丑，功能再强也很难让人认可。我在Vue端的投入大约占了总开发时间的一半，重点在ECharts与地图的结合和动态图表的数据交互上。

5.1 可视化大屏的布局设计

大屏页我采用了典型的"上下左右"布局：顶部是系统标题和全局时间筛选器，左侧是房源总价分布柱状图和各区域均价排行，中间是区域房价热力地图，右侧是户型分布饼图和价格走势折线图。底部留了一条跑马灯式的实时数据滚动条，展示最新录入的几条房源信息。

布局核心代码用的是CSS Grid，比Flexbox更适合这种上下左右分区的复杂布局：

css复制.dashboard-container {
  display: grid;
  grid-template-columns: 320px 1fr 320px;
  grid-template-rows: 64px 1fr 200px;
  gap: 12px;
  padding: 12px;
  height: 100vh;
  background: #0f1c2e;
}

深色背景加亮色图表的组合在可视化大屏中非常常见，因为视觉冲击力强。但要注意配色不能太花哨，我用的主色是青色系（#00d4ff）和橙色系（#ff7f2a），背景色统一深蓝，保证图表数据的可读性优先于美观性。

5.2 ECharts地图热力图的实现

地图热力图是这套系统的视觉中心，用来展示不同区域的房价分布。ECharts的地图功能依赖GeoJSON数据，中国省份或城市的地理坐标数据需要单独引入。我在项目里用的方案是引入一个城市级别的GeoJSON文件，然后用registerMap注册：

javascript复制import * as echarts from 'echarts'
import cityGeoJson from '@/assets/geojson/city.json'

echarts.registerMap('cityMap', cityGeoJson)

热力图的series配置大致如下：

javascript复制series: [{
  type: 'map',
  map: 'cityMap',
  roam: true, // 允许缩放拖动
  label: { show: true, color: '#fff' },
  data: regionPriceList.map(item => ({
    name: item.regionName,
    value: item.avgPrice
  })),
  visualMap: {
    min: 8000,
    max: 60000,
    inRange: { color: ['#313695', '#f7fbff', '#fca50a', '#d73027'] },
    textStyle: { color: '#fff' }
  }
}]

这里有个坑非常值得一说：ECharts地图的值域映射默认不显示0值数据，但二手房均价再低也不可能低于几千，我当时设置min: 8000，结果价格在8000以下的区域直接显示为透明，调试了很久。后来还是老老实实先把所有区域的数据打印到控制台，确认最大值和最小值，再手动设置合理的min和max。

5.3 折线图与柱状图的动态数据刷新

价格走势折线图我做了"按周/按月切换"的功能，用户选择时间粒度后，前端重新请求接口并更新图表。这里体现了Vue响应式数据的好处，我只需要在chartOption这个ref里更新series数据，图表组件通过watch监听并调用setOption即可。

时间粒度的切换逻辑：

javascript复制async function loadTrendData(regionId, granularity) {
  const { data } = await axios.get('/api/region/trend', {
    params: { regionId, granularity }
  })
  trendChartOption.series[0].data = data.prices
  trendChartOption.xAxis.data = data.dates
  trendChart.refresh() // 触发子组件内的 setOption
}

ECharts在动态更新时有一个性能优化点：尽量用setOption而不是先dispose再init。频繁销毁和重建图表实例会导致页面卡顿和内存泄漏。setOption的第二个参数设为true表示不合并之前的配置，能确保新配置完整生效，但如果你同时想保留某些不更新的配置项，就不要设true，让ECharts自动合并就行。

5.4 Axios拦截器与后端接口联调

前后端分离开发中，Axios的封装直接决定了联调效率。我封装了一个request.js，统一处理baseURL、token注入和响应拦截：

javascript复制import axios from 'axios'

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
})

request.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) { config.headers.Authorization = `Bearer ${token}` }
  return config
})

request.interceptors.response.use(
  response => {
    if (response.data.code === 200) { return response.data }
    Message.error(response.data.message || '请求失败')
    return Promise.reject(new Error(response.data.message))
  },
  error => {
    Message.error(error.message || '网络异常')
    return Promise.reject(error)
  }
)

联调时还经常遇到跨域问题。SpringBoot后端的跨域配置我在WebMvcConfigurer里统一处理：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

这里有个和安全相关的细节：allowedOriginPatterns("*")加上allowCredentials(true)在SpringBoot 2.4之前的版本会报错，升级到2.4之后才兼容。如果你用的SpringBoot版本比较老，要么去掉allowCredentials，要么把origin改成明确的前端地址，否则小心遇到那个"Cors allowCredentials is not allowed with wildcard origins"的报错。

6. 我在实际开发中踩过的坑与优化心得

最后这部分不按系统模块顺序来讲，而是按我实际踩坑的时间线来复述。这些坑单独看起来都不致命，但每一个都足够浪费半天到一天的时间，而且网上能搜到的有效解决方案并不多。

6.1 爬虫环节：WaitTime比你的爬取速度更决定成败

我第一版爬虫没有设置请求间隔，一口气抓了500页，结果IP直接被目标平台封了12小时。后来我老老实实在每次请求之间加了2到3.5秒的随机等待，整个采集周期拉长到一天多，但再也没有触发反爬策略。这里我的心得是：爬虫的速度不是越快越好，而是越稳越好。学习性质的爬虫，一定要控制频率，不要给目标服务器造成压力，这也是基本的网络礼仪。

6.2 数据库慢查询：第一次没建索引，区域统计跑了两秒

房源表有2万条数据时，不加索引的区域统计SQL查询要1.5到2秒。对后端工程师来说这可能能接受，但在前端大屏页面上就是一道明显的白屏等待。我给region_name、total_price、publish_date字段加了复合索引之后，同样的查询降到了200毫秒以内。

sql复制ALTER TABLE house ADD INDEX idx_region_price (region_name, total_price);

这里想强调一个习惯：凡是出现在WHERE、JOIN、ORDER BY后面的字段，都要优先考虑加索引。很多新手在表结构设计阶段完全不考虑查询场景，等到接口写完了再回头补索引，反而容易遗漏。

6.3 Vue项目：谁说配置少？Maps和ECharts版本冲突把我坑惨了

可视化项目里，地图和图表库的版本非常敏感。我一开始用的是vue-echarts组件库，它在Vue2下通过v-chart标签直接渲染图表，看起来很省事。但问题在于vue-echarts对ECharts版本有要求，如果同时安装了其他依赖了旧版本ECharts的包，就会莫名出现"map is not defined"的报错。

我的解决办法是放弃vue-echarts，直接用原生ECharts实例封装一个通用的BaseChart组件。虽然代码多一点，但版本控制权完全在我手里，再也没有类似的玄学报错。这里给一个通用组件的简化示例：

vue复制<template>
  <div ref="chartRef" :style="{ height: height }"></div>
</template>

<script>
import * as echarts from 'echarts'
export default {
  name: 'BaseChart',
  props: {
    option: { type: Object, required: true },
    height: { type: String, default: '300px' }
  },
  data() {
    return { chart: null }
  },
  // ...
}
</script>

6.4 前后端字段命名不一致：JSON大小写问题，排查了一个晚上

后端实体类的字段我叫totalPrice，JSON序列化出来是totalPrice，但这个前端有的地方写成了total_price，有的地方用的totalPrice，导致某些表格列显示为空。Vue调试工具里能看到数据存在，表格就是不显示。花了一个晚上才发现是字段名大小写不一致的问题。

这个坑的本质是团队或自己前后端风格不统一。我现在做项目时，会先定义一个接口文档（不用Swagger，用Apifox或yapi先定义好字段名），前后端严格按照文档来，这类问题可以从源头上消灭。

6.5 大屏性能优化：图表数据量太大导致拖动卡顿

当折线图的数据点超过500个之后，拖动、缩放都会明显卡顿，尤其在地图和其他图表同时渲染时更严重。我做了两个优化：

数据降采样：在前段时间跨度较大时，后端直接按周聚合返回数据，而不是返回每一天的价格，减少渲染点数。
图表懒渲染：初始页面只渲染首屏可见的图表，其他图表等用户滚动到对应区域再初始化，减少首屏加载压力。

把这两点做完后，大屏从"能看"变得"好用"了，尤其在地图缩放时，明显比之前流畅很多。

6.6 数据定时归档：一个容易被忽略的"隐藏功能"

前面提到price_history表，我是在开发到第五天才意识到要加的。当时的场景是：我想看某区域过去两个月的价格走势，如果每次都从house表里聚合，不仅要关联community表，还要过滤发布时间，SQL写得很复杂且慢。后来我加了一个Spring定时任务：

java复制@Component
public class PriceArchiveTask {
    @Scheduled(cron = "0 0 2 * * ?") // 每天凌晨2点执行
    public void archiveDailyAvgPrice() {
        // 查询所有区域当天均价，写入price_history表
        List<RegionAvgPriceDTO> list = houseMapper.selectRegionAvgPrice();
        list.forEach(dto -> {
            PriceHistory history = new PriceHistory();
            history.setRegionId(dto.getRegionId());
            history.setAvgUnitPrice(dto.getAvgPrice());
            history.setStatDate(LocalDate.now());
            priceHistoryMapper.insert(history);
        });
    }
}

这个定时任务带来了两个额外的好处：一是历史数据的连续归档为后续的涨跌趋势预测提供了样本基础；二是当房源数据被清理或更新时，历史统计数据不会丢失。我强烈建议任何做价格分析系统的同学都加上这个表，它能让你后续扩展预测功能时事半功倍。

最后再分享一点个人体会。做这个项目之前，我以为难点在算法或者分布式这类"高深"的东西上，做完了才发现，真正考验人的是那些看似琐碎的细节：数据的可靠采集、接口字段的一致性、图表配置的视觉调优。回头来看，SpringBoot加Vue这两个技术栈本身并不复杂，真正让项目有价值的，是完整的数据分析和可视化思路，以及那些让你调了一整天才解决的坑。如果你也在做类似的项目，希望这篇总结能帮你少走一些弯路。