企业官网建设流程全解析

简介：这是一套基于Java的房屋租赁系统完整项目源码，面向计算机相关专业做毕业设计、课程设计或期末大作业的学生，以及需要Java项目实战练习的学习者。项目采用SpringBoot框架搭配Vue前端与MySQL数据库，B/S结构，开发工具为IDEA和Navicat，经过严格调试可直接运行，无任何bug。压缩包共1752个文件，约42.01MB，涵盖130个java源文件、129个class编译文件、96个vue组件、90个html页面、88个css样式、306个js脚本，以及sql数据库脚本、yml配置、md说明和docx文档等，源码、运行说明与数据库一应俱全。系统管理员端包含用户管理、房屋信息管理、预约看房管理、在线签约管理和系统管理；用户端提供登录注册、房屋信息浏览、房屋资讯浏览、交流论坛和个人中心五大模块，功能闭环完整。目前已有1586人学习下载，适合直接作为毕设提交或二次开发参考，帮助快速掌握在线租房平台的业务逻辑与前后端实现思路。

1. 房屋租赁系统跑不起来：从“数据库连不上”到“页面一片空白”的排查起点

你从压缩包里解压出一套房屋租赁源码，照着运行说明一步步操作，结果要么是数据库连接直接报错，要么是项目启动了但浏览器打开一片空白，要么是登录进去之后房源列表加载不出来。这类问题在课程设计、毕业设计场景里太常见了——代码本身没问题，卡住你的往往是环境配置、数据库导入顺序、依赖版本这三件事。这套源码经过调试可运行，但“可运行”的前提是你的本地环境和它匹配。我见过太多人在这三步上反复翻车：数据库密码没改、SQL 文件导入不完整、JDK 版本对不上。这篇笔记按故障现象拆开讲，每个报错都给出定位路径和可抄作业的解决命令，新手能照着跑通，熟手能看到排查思路和预防手段。

2. 数据库连不上：三种典型报错与逐层排查顺序

2.1 Access denied for user：账号密码与权限的坑

这是最高频的报错，没有之一。启动项目时控制台直接抛出：

java.sql.SQLException: Access denied for user 'root'@'localhost' (using password: YES)

看到这个报错，先别急着改代码。它的含义很明确：数据库拒绝了这次连接请求，原因无非三个——用户名不对、密码不对、或者该用户没有从当前主机连接的权限。

第一步，确认配置文件里的连接信息。房屋租赁源码通常会在application.properties或application.yml里写数据库配置。打开文件，找到类似下面的段落：

# 数据库连接配置 spring.datasource.url=jdbc:mysql://localhost:3306/house_rental?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai spring.datasource.username=root spring.datasource.password=123456 spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

这里username和password必须和你本地 MySQL 的实际账号一致。很多人解压后直接启动，根本没注意到配置文件里写的是别人的密码。

第二步，用命令行验证账号是否真的能登录。不要凭记忆，直接敲：

# 用配置文件里的账号密码尝试登录 mysql -u root -p123456 -h localhost -P 3306 # 如果提示 Access denied，换成本地确认可用的密码再试 mysql -u root -p

如果命令行都登不进去，那问题在 MySQL 本身，不在项目代码。常见情况是：你本地 MySQL 的 root 密码和你以为的不一样，或者 root 用户只允许localhost连接而配置文件里写的是127.0.0.1。

第三步，检查用户权限。登录 MySQL 后执行：

-- 查看当前用户能从哪些主机连接 SELECT user, host FROM mysql.user WHERE user = 'root'; -- 如果 host 列只有 localhost，而你需要从 127.0.0.1 连接，补一条授权 CREATE USER 'root'@'127.0.0.1' IDENTIFIED BY '123456'; GRANT ALL PRIVILEGES ON house_rental.* TO 'root'@'127.0.0.1'; FLUSH PRIVILEGES;

host字段决定了允许从哪个地址连接。localhost和127.0.0.1在 MySQL 里是两个不同的 host 值，这一点经常被忽略。FLUSH PRIVILEGES是让权限变更立即生效，不加的话有时候要重启 MySQL 才起作用。

提示：改完配置后不要只重启项目，先把 MySQL 服务确认在运行状态。systemctl status mysql或net start mysql看一眼，服务没起来的话，后面所有排查都是白费。

2.2 Communications link failure：连接超时与端口占用

第二个高频报错长这样：

com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure The last packet sent successfully to the server was 0 milliseconds ago.

这个报错和上一个有本质区别：Access denied是“找到了数据库但被拒绝”，Communications link failure是“根本没找到数据库”。排查方向完全不同。

先确认 MySQL 服务是否在监听端口。在命令行执行：

# Linux/macOS 查看 3306 端口监听状态 netstat -tlnp | grep 3306 # Windows 查看端口占用 netstat -ano | findstr 3306

如果输出为空，说明 MySQL 没启动或者没监听 3306。启动服务：

# Linux sudo systemctl start mysql # macOS 用 brew 安装的情况 brew services start mysql # Windows 在服务管理器里启动 MySQL 服务，或者命令行 net start mysql

如果端口被其他程序占用，你会看到netstat输出里有别的进程 PID 占着 3306。这种情况要么停掉那个程序，要么改 MySQL 端口，要么改项目连接配置。我一般建议改 MySQL 端口，因为改项目配置容易漏掉其他地方：

# 编辑 MySQL 配置文件，把端口改成 3307 # Linux 通常在 /etc/mysql/mysql.conf.d/mysqld.cnf # Windows 在 MySQL 安装目录下的 my.ini [mysqld] port=3307

改完之后项目配置文件里的 URL 也要同步改：

spring.datasource.url=jdbc:mysql://localhost:3307/house_rental?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

还有一种容易被忽略的情况：防火墙拦截。如果数据库不在本机，检查防火墙规则是否放行了 3306 端口。本机连接一般不受防火墙影响，但如果你把项目部署到虚拟机或另一台机器上，这一步必须查。

2.3 Unknown database：库名写错与 SQL 文件没导入

第三个报错：

java.sql.SQLSyntaxErrorException: Unknown database 'house_rental'

这个最直接——MySQL 里根本没有这个库。原因通常是：SQL 文件没导入，或者导入时库名和配置文件里写的不一致。

先看 SQL 文件在哪。房屋租赁源码的压缩包里一般会有一个sql目录或者单独的.sql文件，文件名可能是house_rental.sql、db.sql之类。导入之前先确认文件内容：

# 查看 SQL 文件前 30 行，确认库名和字符集 head -30 house_rental.sql

你会看到类似这样的语句：

CREATE DATABASE IF NOT EXISTS `house_rental` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE `house_rental`;

这里的库名house_rental必须和application.properties里 URL 中的库名完全一致。不一致的话，要么改 SQL 文件，要么改配置文件，二选一。

导入 SQL 文件的正确姿势：

# 先登录 MySQL mysql -u root -p # 在 MySQL 命令行里执行导入（注意路径用绝对路径或确认当前目录） source /path/to/house_rental.sql; # 或者直接在系统命令行导入 mysql -u root -p house_rental < /path/to/house_rental.sql

导入完成后验证：

-- 查看所有数据库，确认 house_rental 存在 SHOW DATABASES; -- 切换到该库，查看表是否完整 USE house_rental; SHOW TABLES;

如果SHOW TABLES输出为空，说明 SQL 文件只建了库没建表，或者导入过程中报错被中断了。重新导入时注意看命令行有没有报错信息，常见的导入失败原因包括：字符集不匹配导致中文乱码、外键约束导致建表顺序出错、SQL 文件本身不完整。

注意：导入 SQL 文件时如果遇到ERROR 1067 (42000): Invalid default value这类报错，通常是 MySQL 版本差异导致的。源码开发时用的 MySQL 版本和你本地版本不一致，datetime默认值语法可能有变化。解决办法是在 SQL 文件开头加上SET sql_mode = '';临时关闭严格模式再导入。

3. 项目启动失败：JDK 版本、依赖冲突与端口占用的排查

3.1 Unsupported class file major version：JDK 版本对不上

启动时看到这个报错：

java.lang.UnsupportedClassVersionError: com/example/HouseRentalApplication has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

翻译一下：编译时用的 JDK 版本比你运行时用的 JDK 版本高。class file version 61.0对应 JDK 17，55.0对应 JDK 11。你的项目是用 JDK 17 编译的，但你现在用 JDK 11 在跑。

先查本地 JDK 版本：

java -version javac -version

两个命令的输出要一致。如果java -version是 11 而javac -version是 17，说明你的JAVA_HOME和PATH指向了不同的 JDK。

再看项目要求的版本。打开pom.xml（Maven 项目）或build.gradle（Gradle 项目），找 Java 版本配置：

<!-- pom.xml 中的 Java 版本配置 --> <properties> <java.version>17</java.version> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> </properties>

如果这里写的是 17，你就必须用 JDK 17 来运行。解决办法有两个：装一个 JDK 17 并切换过去，或者把项目配置改成你本地已有的 JDK 版本。我一般建议前者，因为改项目配置可能引发其他依赖的兼容问题。

切换 JDK 版本（以 Linux 为例）：

# 查看系统里装了哪些 JDK update-alternatives --list java # 切换到 JDK 17 sudo update-alternatives --config java # 在交互界面中选择 JDK 17 对应的编号 # 验证切换结果 java -version

Windows 用户需要在环境变量里把JAVA_HOME指向 JDK 17 的安装目录，并把%JAVA_HOME%\bin放到PATH最前面。

3.2 Port 8080 was already in use：端口被占用的处理

Spring Boot 项目默认跑在 8080 端口，如果这个端口已经被别的程序占了，启动时会报：

Web server failed to start. Port 8080 was already in use.

先找到谁占了 8080：

# Linux/macOS lsof -i :8080 # Windows netstat -ano | findstr :8080

输出会显示占用端口的进程 PID。如果是你之前启动的项目没关干净，直接杀掉：

# Linux/macOS kill -9 <PID> # Windows taskkill /PID <PID> /F

如果占用 8080 的是其他重要服务，那就改项目端口。在application.properties里加一行：

# 把端口改成 8081 server.port=8081

改完之后访问地址也要跟着变：http://localhost:8081。

提示：改端口是最省事的做法，但要注意前端页面里如果有硬编码的localhost:8080，也要同步改掉，否则会出现“后端起来了但前端请求发不出去”的问题。

3.3 依赖下载失败：Maven 仓库与网络问题

Maven 项目启动前会下载依赖，如果网络不通或者仓库配置有问题，会看到大量Could not resolve dependencies报错。典型输出：

Could not resolve dependencies for project com.example:house-rental:jar:1.0.0: Failed to read artifact descriptor for org.springframework.boot:spring-boot-starter-web:jar:2.7.0

第一步，检查 Maven 的 settings.xml 配置。文件通常在~/.m2/settings.xml（Linux/macOS）或C:\Users\你的用户名\.m2\settings.xml（Windows）。确认镜像仓库配置正确：

<mirrors> <mirror> <id>aliyun</id> <mirrorOf>central</mirrorOf> <url>https://maven.aliyun.com/repository/public</url> </mirror> </mirrors>

第二步，强制更新依赖。有时候依赖下载了一半中断了，本地仓库里有残缺文件，Maven 不会自动重新下载。执行：

# 强制更新所有依赖 mvn clean install -U # 如果只想更新依赖不重新编译 mvn dependency:resolve -U

-U参数的作用是强制检查远程仓库的更新，忽略本地缓存。如果还是失败，可以尝试删除本地仓库中对应的目录再重新下载：

# 删除本地仓库中某个依赖的缓存（以 spring-boot-starter-web 为例） rm -rf ~/.m2/repository/org/springframework/boot/spring-boot-starter-web/

第三步，确认项目本身的依赖声明没有冲突。打开pom.xml，检查有没有重复引入同一个库的不同版本。依赖冲突的典型表现是：项目能编译但运行时报NoSuchMethodError或ClassNotFoundException。用 Maven 命令查看依赖树：

# 查看依赖树，找出冲突的版本 mvn dependency:tree -Dverbose

输出里如果有omitted for conflict字样，说明存在版本冲突。解决办法是在pom.xml里用<dependencyManagement>统一版本号，或者用<exclusions>排除掉不需要的传递依赖。

4. 页面空白与功能异常：前端资源、接口路径与数据初始化的排查

4.1 启动成功但页面 404：静态资源路径与上下文配置

项目启动日志显示Started HouseRentalApplication in X seconds，但浏览器打开http://localhost:8080显示 404 或者一片空白。这种情况通常是静态资源没被正确加载。

先确认静态资源放在哪。Spring Boot 项目默认从src/main/resources/static/或src/main/resources/templates/目录加载静态资源。如果你拿到的是前后端分离的项目，前端文件可能在单独的frontend目录里，需要单独启动。

检查application.properties里有没有配置上下文路径：

# 如果配置了 context-path，访问地址要加上这个前缀 server.servlet.context-path=/house

配了这个的话，访问地址就变成了http://localhost:8080/house，而不是http://localhost:8080。很多人不知道这个配置，直接访问根路径当然 404。

如果是前后端分离项目，前端通常用 Nginx 或 Node.js 单独跑。检查前端项目里的接口地址配置：

// 前端配置文件里通常有 API 基础地址 const baseURL = 'http://localhost:8080/api';

这个地址必须和后端实际暴露的接口地址一致。后端接口路径可以在 Controller 类里看到：

@RestController @RequestMapping("/api/house") public class HouseController { // 实际接口路径是 /api/house/xxx }

前后端路径对不上，就会出现“页面能打开但数据加载不出来”的现象。

4.2 登录失败与数据为空：初始数据与密码加密方式

能打开登录页，但输入账号密码后提示“用户名或密码错误”，或者登录进去后房源列表是空的。这类问题多半出在数据初始化上。

先查数据库里有没有数据：

-- 切换到项目数据库 USE house_rental; -- 查看用户表数据 SELECT * FROM user LIMIT 10; -- 查看房源表数据 SELECT COUNT(*) FROM house;

如果user表是空的，说明 SQL 文件里的初始数据没导入成功。重新检查 SQL 文件里有没有INSERT INTO语句，以及导入时有没有报错。

如果表里有数据但登录还是失败，检查密码字段的存储方式。有些项目用明文存密码，有些用 MD5 或 BCrypt 加密。如果你在数据库里手动插入了一个明文密码，但代码里用的是 BCrypt 校验，那永远登不进去。

// 看登录逻辑里用的密码校验方式 // 如果是 BCrypt if (BCrypt.checkpw(inputPassword, storedPassword)) { // 登录成功 } // 如果是 MD5 String md5Input = DigestUtils.md5DigestAsHex(inputPassword.getBytes()); if (md5Input.equals(storedPassword)) { // 登录成功 }

解决办法：要么用代码里同样的加密方式生成密码再插入数据库，要么直接找 SQL 文件里自带的初始账号。通常 SQL 文件里会插入一个默认管理员账号，用户名和密码在注释里会写。

房源列表为空，先看house表有没有数据，再看查询接口有没有报错。打开浏览器开发者工具，看 Network 面板里接口请求的返回内容。如果返回的是{"code": 500, "message": "..."}，根据错误信息定位；如果返回空数组，那就是数据库里确实没数据。

4.3 中文乱码：字符集配置的连锁反应

页面上的中文显示成??????或者房�，这是字符集问题。涉及三个层面：数据库字符集、连接字符集、页面字符集。

数据库层面：

-- 查看数据库和表的字符集 SHOW CREATE DATABASE house_rental; SHOW CREATE TABLE house;

确保字符集是utf8mb4而不是latin1。如果不是，改：

ALTER DATABASE house_rental CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; ALTER TABLE house CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

连接层面：检查 JDBC URL 里有没有加字符集参数：

spring.datasource.url=jdbc:mysql://localhost:3306/house_rental?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

useUnicode=true和characterEncoding=utf8这两个参数必须带上。

页面层面：检查 HTML 文件的<meta>标签：

<meta charset="UTF-8">

以及后端返回 JSON 时的编码配置。Spring Boot 默认用 UTF-8，但如果手动配了HttpMessageConverter可能会覆盖默认行为。

5. 避坑清单：五个最容易翻车的操作

5.1 直接双击 SQL 文件导入

现象：用 Navicat 或 MySQL Workbench 双击 SQL 文件执行，提示成功但表里没数据。

原因：图形化工具执行 SQL 文件时，如果文件里有CREATE DATABASE和USE语句，工具可能在不同的数据库上下文里执行，导致建表和插入数据不在同一个库里。

解决：用命令行导入，或者先在工具里手动选中目标数据库，再执行 SQL 文件里的建表和插入语句。导入后务必用SHOW TABLES和SELECT COUNT(*)验证。

5.2 改完配置不重启项目

现象：改了application.properties里的数据库密码，重新访问页面还是报同样的错。

原因：Spring Boot 项目启动时读取一次配置，运行期间不会自动重新加载。改完配置文件必须重启项目才生效。

解决：改完配置后，先停掉正在运行的项目（Ctrl+C 或点停止按钮），再重新启动。如果用的是 IDE 的 DevTools 热部署，配置文件变更也不一定触发重启，手动重启最保险。

5.3 忽略控制台的第一条报错

现象：控制台刷了几百行报错，不知道从哪看起。

原因：第一条报错往往是根因，后面的报错是连锁反应。比如数据库连不上会导致后续所有查询都失败，但根因只有那一条Access denied。

解决：从控制台最上面开始看，找到第一条Caused by或Exception。把那条报错单独拿出来搜索，解决它之后后面的报错大概率会自动消失。

5.4 用错 JDK 版本编译和运行

现象：项目在 IDE 里能跑，打包成 jar 之后运行报UnsupportedClassVersionError。

原因：IDE 里配置的 JDK 版本和命令行java命令指向的 JDK 版本不一致。IDE 编译用 JDK 17，命令行运行用 JDK 11。

解决：统一JAVA_HOME、PATH和 IDE 项目配置里的 JDK 版本。打包前用mvn -version确认 Maven 使用的 JDK 版本，运行前用java -version确认运行时版本。

5.5 端口冲突后只改一处配置

现象：改了server.port=8081，后端启动成功，但前端页面还是请求 8080，数据加载失败。

原因：前端代码里硬编码了后端地址，改后端端口时忘了同步改前端配置。

解决：全局搜索项目里的8080，把所有出现的地方都改成新端口。前端项目里通常在config.js、.env文件或axios的baseURL配置里。

6. 快速定位故障：一套可复用的排查顺序

遇到项目跑不起来，不要东改一下西改一下。按下面的顺序走一遍，90% 的问题能在十分钟内定位到根因。

第一步，看控制台第一条报错。从最上面开始读，找到第一个Exception或Error。把报错信息复制出来，重点看Caused by后面的内容。

第二步，判断故障层级。用下面这张表快速分类：

第三步，用最小化验证缩小范围。数据库问题就用命令行连一次；JDK 问题就java -version和javac -version各跑一次；端口问题就netstat查一次。命令行能复现的问题，就不要在项目里瞎猜。

第四步，改一处验证一处。不要同时改三个配置然后重启，那样即使跑通了也不知道是哪个改动起了作用。改一个地方，重启，验证，再改下一个。

第五步，记录你的环境信息。在项目根目录建一个环境说明.md，写清楚你用的 JDK 版本、MySQL 版本、Maven 版本、数据库密码、端口号。下次再遇到问题，先对照这份记录检查环境有没有变过。

提示：如果以上步骤都走完了还是跑不起来，把控制台完整报错、java -version输出、mysql -V输出、application.properties里的数据库配置（密码可以打码）整理成一份文档，再去找人帮忙看。信息给全了，别人一眼就能看出问题在哪。

从那以后我每次拿到一套新源码，第一件事不是急着启动，而是先花两分钟确认三件事：JDK 版本对不对、MySQL 在不在跑、配置文件里的账号密码是不是我本地的。这三步走完再启动，能省掉后面大量的无效排查。希望帮到你。

本文还有配套的精品资源，点击获取