企业官网建设流程全解析

SpringBoot搭一个房价展示平台，这类的选题在毕业设计和课程项目里实在太常见了，但很多人卡住的地方其实不是框架本身，而是不清楚一个"能看又能用"的全栈小系统到底要把哪些环节串起来。这次拿南京房价展示平台作为案例，把从数据建模、后端接口、前端图表到本地部署的完整链路拆开讲清楚。项目本身不大——SpringBoot + MySQL + MyBatis-Plus + Thymeleaf + ECharts，但麻雀虽小五脏俱全，它覆盖了列表检索、多条件筛选、价格趋势统计、区域聚合展示这些非常经典的功能点。对正在准备毕设、想入门Java Web开发，或者需要一个可复现项目练手的人来说，这套实现思路比单纯堆代码更有参考价值。

1. 项目整体设计：先想清楚业务边界，再谈技术栈

1.1 需求拆解：这个平台到底要给谁用

很多同学接到"房价展示平台"这个题目后，第一反应就是做一堆页面，把房源卡片铺上去，然后发现数据是假的、交互是死的、论文里没东西可写。原因在于没有先做需求拆解。

我把这套系统拆成三类使用者来考虑，整个项目结构就非常清晰了：

从用户行为看，访客访问平台的第一诉求不是"看某一套房子的照片"，而是"这片区域大概多少钱、最近涨了还是跌了"。所以系统不能只做一个房源CRUD，必须有一个"统计视角"。我最后把功能拆成两个大维度：房源检索维度（按区域、价格、面积、户型筛选）和行情统计维度（区域均价、月度趋势、环比涨跌）。这两个维度一个面向单点详情，一个面向宏观判断，恰好也是后面数据库设计和接口设计的出发点。

1.2 技术选型：为什么这套组合最适合快速落地

技术选型不是越新越好，而是要看交付周期和运行成本。SpringBoot在这个项目中几乎是唯一合理的选择，原因有三个：

第一，约定优于配置让项目骨架搭起来极快。不需要像传统SSH那样手工写一堆XML配置文件，一个带有spring-boot-starter-web依赖的Main入口类就能启动Web服务。第二，内嵌Tomcat解决了部署麻烦的问题，本地开发时一行mvn spring-boot:run就能跑起来，交付演示时打成jar包也不会因为外部容器环境不一致翻车。第三，生态齐全：MyBatis-Plus让单表CRUD几乎不需要手写SQL，Thymeleaf天然适合单体应用的模板渲染，ECharts则是前端图表的事实标准。

至于为什么不选前后端分离的Vue + SpringBoot架构？不是不能选，而是对于这个规模的项目，前后端分离会额外引入Node环境、跨域配置、接口联调成本，单人开发时反而是负担。单体架构下，后端Controller直接返回完整页面片段，数据交互用AJAX局部刷新，已经足够支撑所有交互场景，而且演示部署时只需要一个进程，稳定性高很多。我的建议是：如果目标是快速跑通、答辩演示顺畅，优先单体；如果目标是冲"前后端分离"简历亮点，那就单独规划Vue工程的构建部署流程，不要混着来。

2. 数据库设计与数据准备：房价数据的"底子"决定了功能上限

2.1 核心表结构：三张表支撑所有业务

房价展示平台的核心数据有三个：区域、房源、价格历史。我设计了三张核心表，字段上既考虑查询便利，也考虑聚合统计的需求。

第一张是区域表area_info，用来维护行政区划和板块信息。有人觉得区域直接写死在前端下拉框就行，没必要建表，但实际上价格统计、地图聚合都要按区域分组，有独立的区域表可以避免将来改区域名称时需要改动多处代码的问题。

CREATE TABLE area_info ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', area_code VARCHAR(32) NOT NULL COMMENT '区域编码', area_name VARCHAR(64) NOT NULL COMMENT '区域名称', sort_order INT DEFAULT 0 COMMENT '排序字段', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', UNIQUE KEY uk_area_code (area_code) ) COMMENT='行政区域信息表';

第二张是房源表house_info。这张表字段多，需要重点说明几个关键设计决策：

• 单价和总价都要单独存储。总价方便用户按预算筛选，单价则用于区域均价计算，两者如果只存一个，后面的展示和统计都会别扭。
• 面积用DECIMAL(8,2)，不用FLOAT或DOUBLE，因为浮点类型在比较运算中容易产生精度问题，房价这种敏感数据经不起0.1的误差。
• 区域编码和单价建组合索引(area_code, unit_price)。这个组合索引对"某个区域内按价格排序/统计"是显著的性能优化，几百条数据时感觉不出来，但如果导入了几万条真实房源数据，有没有这个索引差别会很明显。

CREATE TABLE house_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', house_code VARCHAR(32) NOT NULL COMMENT '房源编号', house_name VARCHAR(128) NOT NULL COMMENT '小区/楼盘名称', area_code VARCHAR(32) NOT NULL COMMENT '所属区域编码', layout_room TINYINT DEFAULT 0 COMMENT '室', layout_hall TINYINT DEFAULT 0 COMMENT '厅', layout_toilet TINYINT DEFAULT 0 COMMENT '卫', building_area DECIMAL(8,2) NOT NULL COMMENT '建筑面积(㎡)', total_price DECIMAL(12,2) NOT NULL COMMENT '总价(万元)', unit_price DECIMAL(10,2) NOT NULL COMMENT '单价(元/㎡)', floor_info VARCHAR(32) COMMENT '楼层信息', orientation VARCHAR(16) COMMENT '朝向', building_year VARCHAR(8) COMMENT '建成年份', listing_date DATE COMMENT '挂牌日期', source_name VARCHAR(64) COMMENT '数据来源标识', status TINYINT DEFAULT 1 COMMENT '状态 1在售 0下架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_area (area_code), KEY idx_area_unit (area_code, unit_price) ) COMMENT='房源基础信息表';

第三张是价格历史表price_history。这张表用来存放"区域月度均价"这类统计结果，而不是每次前端展示趋势图时再去对house_info做全量聚合。这是很多人容易忽略的点：统计数据要提前算好存下来，不要依赖运行时聚合。原因很简单：房价趋势是历史视图，当月的房源数据下架或者新增后，历史均价不应该跟着变，否则图表每个月回看都会对不上。

CREATE TABLE price_history ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', area_code VARCHAR(32) NOT NULL COMMENT '区域编码', stat_month CHAR(7) NOT NULL COMMENT '统计月份 YYYY-MM', avg_unit_price DECIMAL(10,2) COMMENT '平均挂牌单价(元/㎡)', listing_count INT COMMENT '在售挂牌套数', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_area_month (area_code, stat_month) ) COMMENT='月度价格统计表';

2.2 数据从哪来：采集、清洗与入库实操

数据是整个项目最容易"翻车"的环节。很多同学一开始雄心勃勃想写爬虫抓几万条真实房源，结果反爬机制、验证码、页面改版，数据还没抓完心态先崩了。我的建议是示范项目以公开可复制的数据为主，量级控制在两三千条，既能撑起图表效果，又不至于让数据库初始化脚本过大。

我用的是三种数据来源的组合：一是公开房产平台的列表页结构化信息，二是手动整理的标准CSV文件，三是项目里内置的初始化SQL脚本。抓取公开页面时，务必要控制抓取频率，并且只用于学习演示，不要涉及任何账号类、加密类接口，也不要长期高频访问给对方服务器造成压力。

数据清洗环节有两个高频坑：

坑一：价格字段的单位不统一。有的平台显示"3.5万/㎡"，有的显示"350万总价"，还有的显示"3,500,000元"。入库前必须统一换算，我建议在写入数据库之前就把数据标准化为：单价单位是元/㎡，总价单位是万元。这个换算用Python脚本批量做是最高效的，核心逻辑也很简单：

import csv with open('raw_houses.csv', 'r', encoding='utf-8') as f: reader = csv.DictReader(f) for row in reader: # 示例：把 "3.5万/㎡" 转为 35000.0 unit_price_text = row['unit_price'].replace('万/㎡', '').strip() unit_price = float(unit_price_text) * 10000 # 总价单位从"万元"统一为数值 total_price_text = row['total_price'].replace('万', '').strip() total_price = float(total_price_text) ...

坑二：房源重复和缺失值。同一个小区同一套房源可能在平台上有两条记录，需要根据小区名 + 户型 + 面积做去重；面积、总价缺失的房源，处理策略是直接剔除，而不是用平均数填充，因为房价数据不是平滑序列，填充值会污染统计结果。

清洗完之后，我推荐用Spring Boot项目里的CommandLineRunner写一个简单的数据导入接口，通过MultipartFile接收CSV并逐行写入数据库，这样后台管理页面可以直接上传数据文件，比手动执行SQL脚本要直观得多。这个导入接口虽然代码简单，但在后来的演示环节非常加分——评委看到的是一个"可维护数据"的平台，而不是一个写死了数据的静态页面。

3. 后端核心接口与动态SQL：检索、统计和图表数据的组装

3.1 多条件筛选为什么不拼字符串

房源列表页最核心的接口是"筛选查询"，过滤条件包括区域、价格区间、面积区间、户型、关键字。新手最容易写出来的是这种代码：先构造一个WHERE 1=1的字符串，然后一个个if把条件拼上去，最后用String.format拼接SQL。这个方案在小数据量下确实能跑，但可读性和可维护性都很差，而且容易出SQL注入风险。

我用MyBatis-Plus的LambdaQueryWrapper来做动态条件，既安全又优雅。核心Service层代码如下：

public PageResult<HouseInfoVO> pageQuery(HouseQueryDTO query) { LambdaQueryWrapper<HouseInfo> wrapper = new LambdaQueryWrapper<>(); // 区域筛选 if (StringUtils.hasText(query.getAreaCode())) { wrapper.eq(HouseInfo::getAreaCode, query.getAreaCode()); } // 价格区间筛选：单位是元/㎡ if (query.getMinPrice() != null) { wrapper.ge(HouseInfo::getUnitPrice, query.getMinPrice()); } if (query.getMaxPrice() != null) { wrapper.le(HouseInfo::getUnitPrice, query.getMaxPrice()); } // 面积区间筛选 if (query.getMinArea() != null) { wrapper.ge(HouseInfo::getBuildingArea, query.getMinArea()); } if (query.getMaxArea() != null) { wrapper.le(HouseInfo::getBuildingArea, query.getMaxArea()); } // 户型 if (query.getLayoutRoom() != null && query.getLayoutRoom() > 0) { wrapper.eq(HouseInfo::getLayoutRoom, query.getLayoutRoom()); } // 关键字模糊搜索小区名 if (StringUtils.hasText(query.getKeyword())) { wrapper.and(w -> w.like(HouseInfo::getHouseName, query.getKeyword()) .or().like(HouseInfo::getAreaCode, query.getKeyword())); } // 上架状态的房源默认只查 status=1 wrapper.eq(HouseInfo::getStatus, 1); wrapper.orderByDesc(HouseInfo::getListingDate); // MyBatis-Plus 分页插件 Page<HouseInfo> page = houseInfoMapper.selectPage( new Page<>(query.getPageNum(), query.getPageSize()), wrapper); // ... 实体转VO，返回分页结果 }

为什么用LambdaQueryWrapper而不是普通QueryWrapper？因为Lambda方式通过方法引用拿到字段名，编译期就能避免"列名拼写错误"这类低级问题，重构实体字段时也不会因为字符串没更新而报错。这个细节在答辩时可以主动提一句，说明你有工程意识而不是只会粘贴代码。

3.2 月度均价与环比涨跌：窗口函数是更优雅的解法

价格趋势统计是另一个核心接口。前端趋势图需要两个数据序列：一是某区域近12个月的均价曲线，二是每个月相比上个月的涨跌幅。如果你用的是MySQL 8.0，LAG()窗口函数可以非常简洁地算出环比值，不需要在Java代码里做循环遍历。

WITH price_trend AS ( SELECT stat_month, avg_unit_price, LAG(avg_unit_price, 1) OVER (ORDER BY stat_month) AS prev_month_price FROM price_history WHERE area_code = #{areaCode} AND stat_month >= #{startMonth} AND stat_month <= #{endMonth} ) SELECT stat_month, avg_unit_price, prev_month_price, CASE WHEN prev_month_price IS NULL THEN null ELSE ROUND((avg_unit_price - prev_month_price) / prev_month_price * 100, 2) END AS change_rate FROM price_trend ORDER BY stat_month;

这段SQL里LAG(avg_unit_price, 1)的意思是取"按月份排序后上一行的平均单价"，然后当前的均价减去它再除以上个月的均价，得到的就是环比涨跌幅。注意CASE WHEN prev_month_price IS NULL的处理，第一个月没有历史数据，涨跌幅应该是null而不是0，前端拿到null可以不渲染涨跌标签，更符合业务语义。

如果项目用的MySQL版本不支持窗口函数（比如5.7），也可以退而求其次在Java里通过循环Map计算，但数据量大了以后效率明显下降。所以我强烈建议直接用MySQL 8.0，初始化和开发成本都不高，却能给SQL加分不少。

3.3 统一返回结构与图表数据组装

接口返回给前端的数据，我设计了一个统一的ResultVO<T>结构：

public class ResultVO<T> { private Integer code; // 200成功，500失败 private String message; // 提示信息 private T data; // 业务数据 }

所有Controller接口都返回这个结构，好处是前后端交互约定统一，前端可以通过code快速判断请求状态，配合全局异常处理器，错误信息也能很规整地返回给调用方。

图表数据组装则是另外一个关键点。ECharts折线图需要的是{ months: [], prices: [], changes: [] }这样的数据结构，而地图需要的是[{name:'区域名称', value: 均价}]。我建议在Service层就把数据组装成这种"面向视图"的结构，而不是把数据库的实体对象直接扔给前端。这样即便将来换前端框架，后端返回结构不需要大改。组装代码大致如下：

Map<String, Object> chartData = new HashMap<>(); chartData.put("months", trendList.stream().map(TrendVO::getMonth).collect(Collectors.toList())); chartData.put("prices", trendList.stream().map(TrendVO::getAvgPrice).collect(Collectors.toList())); chartData.put("changes", trendList.stream().map(TrendVO::getChangeRate).collect(Collectors.toList()));

这个步骤看起来简单，但很多人做完查询接口直接return list，前端拿到一堆对象后还得自己做数据抽取，增加了前端复杂度的同时，也让后端接口失去了"复用性"。接口的设计思想是：一个接口对应一个前端视图的数据需求，而不是对数据库表的机械映射。

4. 前端页面与可视化实现：把数据变成看得懂的图表

4.1 页面结构与模板复用

前端我采用Thymeleaf模板引擎，核心页面拆成四个：

• index.html：首页总览，展示区域均价排行、最近挂牌房源、市场概览数字卡片。
• list.html：房源列表页，左侧是筛选区，右侧是房源卡片加地图小窗。
• detail.html：房源详情页，展示基础字段和该小区/区域的价格走势。
• statistics.html：统计页，放区域均价柱状图、价格趋势折线图、挂牌量分布饼图。

Thymeleaf最实用的一个特点是模板片段复用。导航栏、页脚、图表初始化等公共部分，我放在fragments/common.html里，通过th:replace引入，避免每个页面复制粘贴一大段HTML。比如导航栏：

<nav th:fragment="mainNav" class="main-nav"> <a th:href="@{/}">首页</a> <a th:href="@{/house/list}">房源列表</a> <a th:href="@{/statistics}">市场统计</a> </nav>

再来一个页面引入：

<div th:replace="~{fragments/common :: mainNav}"></div>

这样改导航不用每个页面单独动，代码量减少，后期维护省心很多。

4.2 地图聚合展示：ECharts地图的正确打开方式

统计页最有视觉冲击力的部分是行政区均价地图。ECharts加载地图需要GeoJSON数据，这里就涉及一个很关键的坑：绝对不要在生产页面上实时拉取外部的GeoJSON文件，一方面外部链接可能随时失效，另一方面跨域请求在部署环境里是非常容易翻车的。我的方案是把南京行政区GeoJSON文件下载到项目的static/geo/目录下，用AJAX从本地加载。

$.getJSON('/geo/nanjing.json', function (geoJson) { echarts.registerMap('nanjing', geoJson); var myChart = echarts.init(document.getElementById('mapBox')); myChart.setOption({ tooltip: { trigger: 'item', formatter: function (params) { return params.name + '<br/>挂牌均价：' + (params.value || 0) + ' 元/㎡'; } }, visualMap: { min: 15000, max: 60000, text: ['高', '低'], inRange: { color: ['#e8f3ff', '#1874d0'] } }, series: [{ type: 'map', map: 'nanjing', label: { show: true, fontSize: 12 }, data: areaAvgData // [{name:'示例区A', value:32000}, ...] }] }); });

使用本地GeoJSON加载地图，色阶由visualMap控制，颜色渐变直观反映不同区域的均价高低。这里我不展开具体哪个区的数值，因为示例数据用占位区域名（示例区A、示例区B）演示完全够用，实际换成真实GeoJSON和区域编码映射即可。

4.3 筛选联动与异步刷新：不刷新页面的交互细节

房源列表页的交互核心是"筛选条件改变 -> 局部刷新列表和统计图"。这个交互不需要提交整个表单，用AJAX请求后端接口，替换列表容器内容就行。需要注意几个实现细节：

• 点击筛选按钮时开启loading遮罩。因为查询接口可能会慢，如果不做loading提示，用户会以为页面卡死。
• 下拉框选择区域后，可选联动更新地图高亮。比如用户在左侧选择"示例区A"，右侧地图自动高亮该区域并放大展示。
• 价格区间建议用双滑块，例如使用layui或原生input[type=range]组件，比手动输入数字更加顺畅，演示时体验会好很多。

筛选联动代码的骨架如下：

$('#filterForm').on('change', '.condition-item', function () { var params = $('#filterForm').serialize(); $.ajax({ url: '/house/page', type: 'GET', data: params, success: function (res) { $('#houseListContainer').html(res); // 更新地图统计 refreshMap(params); }, error: function () { layer.msg('查询失败，请稍后重试'); } }); });

注意一点：AJAX返回的是Thymeleaf渲染好的HTML片段还是JSON数据？在单体架构下，我推荐返回HTML片段（用Thymeleaf的fragment模板），这样前端不需要写大量的DOM拼接逻辑，列表结构变动时只需改后端模板。JSON适用于ECharts这类图表数据源，两者结合使用，各有分工。

5. 本地部署与调试全流程：从空环境到跑通全栈

5.1 开发环境版本矩阵：别让版本不一致坑了

这类项目交付或自用时，环境版本不匹配是最常见的启动失败原因。我给自己定了一个相对稳定的版本组合：

如果你本机是JDK17，用SpringBoot2.7也没问题，但如果是SpringBoot3.x，那Java版本、MyBatis-Plus的starter坐标都要跟着变，不要混用。

导入项目到IDEA时，推荐直接用Maven的Reimport重新加载依赖。第一次加载如果网络不好，~/.m2/repository下的依赖下载会卡住，解决办法是更换Maven国内镜像源，或直接把别人的完整repository目录覆盖过去（团队开发时常见做法）。

5.2 配置文件里的关键细节

application.yml是整个项目的"命门"。最核心的数据源配置如下：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/house_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: "123456" hikari: minimum-idle: 5 maximum-pool-size: 20 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: status logic-delete-value: 0 logic-not-delete-value: 1

这里几个参数必须解释清楚，否则出错了都不知道为什么：

• serverTimezone=Asia/Shanghai：MySQL 8.0的驱动会读取服务器时区，不设置容易在插入时间字段时报错或者显示时间相差8小时。
• allowPublicKeyRetrieval=true：MySQL 8.0使用caching_sha2_password认证插件，首次连接时需要允许获取服务器的公钥，否则会遇到Public Key Retrieval is not allowed的异常。
• logic-delete-field是MyBatis-Plus的逻辑删除配置，删除房源时实际执行的是UPDATE status=0，既保留历史数据，又不会让已下架房源出现在查询结果中。

如果启动时发现SQL执行日志没有打印，那就是log-impl没有配置成StdOutImpl，默认情况下MyBatis-Plus是不打印SQL的，这对于调试很不友好。建议开发阶段强行打开SQL日志，排查问题时效率高一个量级。

5.3 启动排错实录：三个每天都有人踩的坑

我把实际调试过程中遇到的三个最高频问题整理出来：

问题一：启动时端口被占用。SpringBoot内嵌Tomcat默认的8080端口很容易被一些本地服务占用。排查命令Windows下用netstat -ano | findstr 8080，Linux/Mac用lsof -i :8080，然后根据PID杀掉对应进程，或者直接改server.port为8081。我个人的经验是：如果只是临时演示，改端口最快；如果是长期开发，先查清是哪个进程占用了端口，不要盲目杀进程。

问题二：数据库连接失败，报Unable to connect to the database。常见原因是MySQL服务没启动，或者密码和配置文件不一致。还有一个隐蔽点：新建的数据库字符集不是utf8mb4，初始化脚本里有中文注释时会报字符集错误。解决方法是建库时显式指定字符集：CREATE DATABASE house_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;。

问题三：页面能打开但样式全部"散架"。这种通常是Thymeleaf模板里的静态资源路径写错了。如果在Controller里把/house/list映射到list.html，而页面里的CSS引用写的是href="css/style.css"这种相对路径，刷新时浏览器会请求/house/css/style.css，自然就404了。解决方法是所有静态资源引用都加上th:href="@{/css/style.css}"，让Thymeleaf自动加上应用的上下文路径。

6. 高频问题排查与文档整理：让项目收尾不掉链子

6.1 高频问题速查表：先定位再动手

为了节省自己和后来者的排查时间，我把运行过程中最常见的问题整理成速查表，遇到问题先对号入座，再深入研究：

6.2 万字论文/文档怎么组织：结构比字数更重要

这个标题里特别提到"论文文档1万字以上"，确实，房价展示平台这类系统型项目，文档内容如果只靠堆截图，答辩时很容易被追问"这里为什么这么设计"时接不上话。我的建议是把文档按下面这个结构来组织，既能保证逻辑严密，又能自然凑够页数：

• 第一章 绪论：项目背景与意义、国内外研究现状、主要工作。这章容易写空，关键是把"为什么要做一个区域房价展示平台"说清楚，比如信息公开、市场参考、数据可视化价值等。
• 第二章 关键技术介绍：SpringBoot、MyBatis-Plus、ECharts、MySQL。不要写成技术官网介绍，要结合本项目的使用场景说明，比如"选用ECharts是因为它提供了开箱即用的地图联动配置"。
• 第三章 需求分析：功能性需求（查看房源、筛选、统计、管理）和非功能性需求（性能、易用性、安全性）。
• 第四章 系统设计：总体架构图、功能模块图、数据库ER图、表结构设计说明。数据库设计是这章的重点，把字段含义、索引设计理由讲透。
• 第五章 系统实现：按模块展示核心代码片段，并配合截图说明实现效果。这章是"字数担当"，但不要在代码块上浪费时间，贴最核心的接口实现和前端图表配置即可。
• 第六章 系统测试：功能测试用例表、测试结果、性能测试（至少说明并发请求下的响应情况）。
• 第七章 总结与展望：总结项目不足，比如数据实时性不足、缺少用户量大的性能验证，加上后续改进方向。

写文档的重心要放在"设计理由"上，而不是"功能描述"。这个思维方式的差别，直接决定了答辩时你是被动背稿子还是能主动应对追问。

6.3 交付部署的几个小技巧

项目交付或演示时，有几个细节能让整个过程顺畅很多：

• 打包时确认数据库初始化脚本可重复执行。建议在SQL脚本里加DROP TABLE IF EXISTS再建表，这样不管哪台机器执行都不会因为残留表而报错。
• 用jar包方式部署时，外部配置文件优先。把application.yml放在jar包同级的config/目录下，SpringBoot启动时会优先读取外部配置，这样演示现场临时改数据库密码就不用重新打包。
• 准备一个启动说明.txt。里面写清楚依赖环境版本、数据库初始化步骤、可执行命令，而不是只在答辩现场临时翻IDE的操作截图。这个文档在答辩评委会问"同学你这个项目怎么部署"时非常加分。

打包命令很简单，mvn clean package -DskipTests，打出来的jar包就是可以单独执行的产物：

java -jar house-platform.jar

如果想让演示环境更干净，还可以加上--server.port=8081这样的启动参数来覆盖默认配置。

写在最后的几点体会

这个项目整理到后期，我最大的感悟是：房价展示平台这类系统，技术含量并不在于某个高深算法，而在于一整套"从数据到界面"的工程链条是否能顺畅运转。数据采集把不规范的字段清洗干净、数据库设计让聚合统计查询快、后端接口让前端拿到的结构刚刚好、前端图表用最少的代码展示最直观的信息——每一环单拎出来都不难，难的是所有环节做决策时都有前后一致的逻辑。

如果让我给准备复现这个项目的人一个建议，那就是先花半天时间把数据模型想清楚，再动手写代码。很多人失败是因为一开始就急着写Controller，结果因为表结构反复调整，代码推翻重来。还有一点，我建议至少准备一套"干净"的演示数据，数量和分类都要覆盖所有筛选条件，这样演示时点哪个条件都有反馈，不会有角落是空白状态，这个体验细节很影响答辩效果。记得自己先把所有筛选组合都点一遍，确认没有500错误，再坐进答辩教室。