搞过毕业设计或者课程设计的同学应该都清楚，房屋租赁系统算是Java Web方向很经典的一个选题了。市面上能搜到的相关项目不少，但大多数要么只有后端、要么只有前端，能把Spring Boot后端和Android客户端串起来，还附带完整源码、文档、运行视频和讲解视频的，确实不多。我最近刚好完整过了一遍这套基于Java Spring Boot + Android的房屋租赁系统，从环境搭建到功能实现、从本地调试到打包部署都跑通了。这篇文章就围绕这套系统的技术选型、核心模块拆解、实操过程和踩坑记录来写，给正在做类似项目或者想自己从零搞一套全栈项目的同学一个参考。
1. 项目整体设计与思路拆解
1.1 需求分析：房东、租客和管理员三种角色的边界划分
房屋租赁这个业务场景，说白了就是三拨人在里面打交道：房东要把房子挂出去，租客要找房子、看房、下单，平台方（管理员）要做审核和运营管理。很多同类项目把三种角色糊在一起做权限，结果后期改需求的时候越改越乱。这套系统的思路很清晰，从一开始就按角色把功能边界切开了。
租客端的核心操作是浏览房源、搜索筛选、收藏、发起租赁订单、支付订金或者租金、发表评价。房东端的核心操作是发布房源、管理自己名下的房源上下架、处理租客提交的订单、查看成交记录和收益。管理员端则负责用户管理、房源审核、订单监管、公告发布、数据统计这些后台操作。
三种角色对应到Android客户端上，实际上就是登录后根据用户类型动态渲染不同的功能入口。比如同样是一套房源详情页，租客看到的是"申请看房""立即预订"按钮，房东看到的是"编辑房源""下架房源"按钮，管理员看到的是"审核通过""删除房源"按钮。这套设计的好处是业务边界清晰，后期维护每个模块的时候不会互相牵连。
Android端采用单应用多角色的方案，不管什么用户登录，都进入同一个App，只是功能菜单根据角色动态变化。这样比做三个独立App的方案要省事得多，对于毕设级别的项目来说，一套代码解决所有角色的需求，不用维护多套客户端，工作量也相对可控。
1.2 为什么选Spring Boot + Android：技术选型背后的逻辑
现在做Java Web方向的毕设，后端框架基本就是在Spring Boot、SSM、Spring Cloud这几类里面选。这套系统用Spring Boot而不用传统的SSM，最关键的原因是Spring Boot大大降低了配置成本和部署门槛，内置Tomcat、自动配置、约定优于配置，一个注解就能启动整个应用。
Spring Boot对于这种单体架构的毕设项目来说是恰到好处的选择。SSM需要手动配置大量的XML文件、数据源、事务管理器，光是环境搭建就能劝退不少人。Spring Boot则把这些繁琐的配置用自动配置机制取代了，只需要在pom.xml里引入依赖、在application.yml里写几行配置就能跑起来。
Android端选择原生开发而不是H5套壳或者跨平台框架，主要是因为原生Java代码和后端Java语言栈统一，在校生对Android的原生组件体系（Activity、Fragment、RecyclerView、OkHttp）一般都有基础，出问题也好排查。而且这套项目配套了运行视频和讲解视频，老师或者评委看到的是一个真机运行的原生App，演示效果比H5套壳要扎实得多。
1.3 系统功能架构：从信息流看全貌
这套系统从信息流的角度看就一条主线：房源信息从房东的手里发布出来，经过管理员审核，展示在租客的App上，租客下单后生成订单，交易完成后产生评价。所有的功能模块都是围绕这条主线展开的。
- 用户模块：注册、登录、身份切换（租客/房东）、个人信息维护
- 房源模块：房源发布、图片上传、列表展示、条件筛选、详情查看、收藏管理
- 订单模块：创建订单、订单状态流转（待支付、待确认、已生效、已完成、已取消）
- 评价模块：租客对房源和房东进行评分和文字评价
- 管理模块：用户封禁/解封、房源审核、订单监管、统计分析
- 公告模块：管理员发布平台公告，用户端轮播展示
这六个模块之间的耦合度控制得比较好。房源模块和订单模块是核心，用户模块提供基础支撑，管理模块和评价模块则是辅助延伸。对于毕设答辩来说，这个功能体量足够展示工作量，又不会大到一个人做不完。
2. 核心细节解析与实操要点
2.1 数据库设计：六张表怎么撑起整个业务
数据库设计是这套系统的基础，表设计得是否合理直接决定了后续代码好不好写。这套系统的核心表大概是这样的：
t_user：用户表，字段包括id、username、password、phone、role、status、create_time。角色用int类型区分，比如0代表管理员、1代表房东、2代表租客，比直接用字符串存角色更节省空间、查询效率也更高。t_house：房源表，字段包括id、landlord_id、title、description、price、area、address、cover_image、images、status、create_time。status字段很关键，0代表待审核、1代表已上架、2代表已下架、3代表审核不通过，这个字段串起了整个审核流程。t_order：订单表，字段包括id、house_id、tenant_id、landlord_id、start_date、end_date、total_price、status、create_time。订单状态用int存储，0待支付、1待确认、2已生效、3已完成、4已取消、5已退款，不同的业务操作触发不同的状态迁移。t_favorite：收藏表，字段包括id、user_id、house_id、create_time。用户和房源关联的时候必须用唯一约束，防止用户对同一套房源重复收藏。t_comment：评价表，字段包括id、order_id、house_id、user_id、content、rating、create_time。评价表关联order_id可以防止有人没交易过就乱评价。t_announcement：公告表，字段包括id、title、content、create_time、update_time。
表结构的核心设计原则是主外键关系清晰，尽量用状态机字段而不是物理删除。比如用户删除房源，实际是把房源status改成已下架而不是从数据库里DELETE掉，这样能保留审计痕迹，后面即使出问题也好回溯。
2.2 后端接口设计：RESTful API和统一返回体
Spring Boot后端和Android客户端的数据交互走的是HTTP接口，接口设计规范直接关系到前端开发的效率。这套系统在接口设计上遵循了RESTful风格，按资源命名URL、通过HTTP方法区分操作类型。
接口统一返回格式是JSON，并且定义了一个通用的返回体类Result<T>：
public class Result<T> { private Integer code; private String message; private T data; // 省略构造方法和getter/setter }所有接口的返回都包一层Result，code=200表示成功，code=401表示未登录，code=500表示服务器异常。这样的好处是Android端只需要解析一次这个结构，统一处理异常，不用每个接口单独判断。
接口的URL设计大概是这样：
POST /api/user/register：注册POST /api/user/login：登录GET /api/house/list?page=1&size=10：房源列表GET /api/house/{id}：房源详情POST /api/house：发布房源（房东）PUT /api/house/{id}：修改房源（房东）DELETE /api/house/{id}：下架房源（房东）POST /api/order：创建订单GET /api/order/my：我的订单POST /api/comment：发表评价GET /api/admin/user/list：管理员获取用户列表
分页参数、筛选条件都通过query参数传递，例如GET /api/house/list?keyword=两室&priceMin=1000&priceMax=3000&areaType=整租，服务端用MyBatis Plus的Wrapper条件构造器实现动态拼接查询。PC端管理后台和Web管理端可以通过AdminLTE或者Vue等模板进行构建，而Android端作为主要的业务操作端使用这些接口。
2.3 Android端架构：MVP模式与网络层封装
Android端的架构选择的是MVP（Model-View-Presenter）模式，跟MVC相比，MVP最大的优势是业务逻辑和界面展示完全解耦。Activity只负责界面渲染和事件回传，具体的业务逻辑放在Presenter里面，数据获取放在Model层。
Android端的网络层基于OkHttp + Retrofit封装，Retrofit用注解定义接口，省去了写大量网络请求代码的重复劳动。登录后服务端返回Token，客户端把Token存在SharedPreferences里，每次请求在拦截器中自动携带Token，实现会话保持。
界面层比较核心的是房源列表，使用的是RecyclerView + CardView组合，每个卡片展示房源封面图、标题、价格、面积、地址等核心信息，整体视觉效果比ListView时代要好看不少。图片加载用的是Glide，支持占位图、圆角、图片裁剪，加载网络图片体验比较流畅。
3. 实操过程与核心环节实现
3.1 环境准备：一套能直接跑起来的配置清单
跑这套系统的步骤其实不复杂，难点主要在一些细节配置容易出错。我列一下完整的踩坑后的环境配置清单：
本机环境建议如下（我用的是这套，完全不冲突）：
- JDK 1.8（Spring Boot 2.x系列对JDK 8支持最友好）
- Maven 3.6.3
- MySQL 5.7（8.0也可以，但注意驱动依赖要换成
com.mysql.cj.jdbc.Driver） - Android Studio 4.x以上（AGP版本必须和你手里的源码保持一致，最好直接用项目自带的gradle wrapper）
- Navicat或者IDEA自带的数据库工具，用来建库导数据
后端启动步骤：
- 用Navicat新建数据库，导入项目中的
sql/house_rent.sql脚本 - 修改
application.yml中的数据源配置：
server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/house_rent?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 servlet: multipart: max-file-size: 10MB max-request-size: 10MB- 在IDEA中打开项目，等待Maven依赖下载完成，运行
HouseRentApplication.java - 后端启动成功后，通过
http://localhost:8080/api/user/test这个测试接口验证接口是否正常返回JSON。
Android端启动步骤：
- Android Studio打开根目录下的
android文件夹，等待Gradle同步完成 - 修改项目中的网络配置，找到
ApiConstants.java或者类似的基础配置类，把本机IP地址填进去：
public class ApiConstants { // 模拟器访问本机后端地址必须是10.0.2.2，不能写localhost public static final String BASE_URL = "http://10.0.2.2:8080/api"; }- 连接真机或者启动模拟器，点击Run按钮运行App
- 注册一个租客账号和一个房东账号，分别登录验证首页和发布房源流程
这套配置跑下来，前后端端口不冲突、数据库连接正常，基本就是一套完整的可运行状态。
3.2 后端核心模块：登录鉴权与房源全生命周期管理
登录鉴权是整个后端最基础的模块。这套系统没有引入SpringSecurity，采用的是JWT（JSON Web Token）技术。用户登录成功后，服务端生成一个Token返回给客户端，后续的请求里带着这个Token就能识别用户身份。
Token的生成用Java的JWT库：
public class JwtUtil { private static final String SECRET_KEY = "house_rent_secret_key"; private static final long EXPIRE_TIME = 7 * 24 * 60 * 60 * 1000; // 7天有效期 public static String createToken(Integer userId, String username, Integer role) { return Jwts.builder() .claim("userId", userId) .claim("username", username) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token) .getBody(); } }前端每次请求在拦截器中读取Token，然后通过ThreadLocal把用户信息传递到Service层，这样就可以知道当前登录用户是谁、他的角色是什么，对应不同角色做不同的操作权限校验。比如修改房源接口，服务端先判断当前登录用户是不是这间房子的房东，如果不是直接返回"无权操作"错误码，这个判断逻辑虽然简单但是很实用。
房源模块的核心是发布流程。房东在前端Android端填好房源标题、描述、价格、面积、地址，选择封面图片后提交，后端接收请求后存储房源记录，房源status默认为0（待审核）。管理员在后台列表中看到待审核房源，点击"通过"后status变为1，房源才会在前端的房源列表中展示出来。这里涉及一个多文件上传的处理，Spring Boot接收MultipartFile数组，保存到服务器本地的uploads目录：
@PostMapping("/api/house/upload") public Result<List<String>> upload(@RequestParam("files") MultipartFile[] files) { List<String> urls = new ArrayList<>(); for (MultipartFile file : files) { String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = UUID.randomUUID().toString() + suffix; File dest = new File(uploadDir + fileName); file.transferTo(dest); urls.add("/uploads/" + fileName); } return Result.success(urls); }这里有一个比较重要的参数细节：Spring Boot默认上传文件大小限制为1MB，上传房源图片时非常容易出现超出限制的报错，需要在配置中调整参数：
spring: servlet: multipart: max-file-size: 10MB max-request-size: 10MB3.3 Android端核心界面：从列表页到下单流程的完整实现
Android端最核心的一个功能链路是"浏览房源 → 查看详情 → 创建订单 → 支付 → 评论"，这个链路覆盖了房源、订单、支付、评价四个模块，也是演示时最能体现系统完整性的一段操作。
首页的房源列表用的是RecyclerView+LinearLayoutManager，数据从接口GET /api/house/list里拉取。这里的列表不仅是简单的数据渲染，还支持下拉刷新和上拉加载更多：
public class HouseListActivity extends AppCompatActivity { private List<House> houseList = new ArrayList<>(); private HouseAdapter adapter; private int currentPage = 1; private boolean isLastPage = false; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_house_list); RecyclerView recyclerView = findViewById(R.id.recyclerView); LinearLayoutManager layoutManager = new LinearLayoutManager(this); recyclerView.setLayoutManager(layoutManager); adapter = new HouseAdapter(houseList); recyclerView.setAdapter(adapter); // 下拉刷新 SwipeRefreshLayout refreshLayout = findViewById(R.id.refreshLayout); refreshLayout.setOnRefreshListener(() -> getHouseList(true)); // 上拉加载更多：监听滚动事件，判断滑到最后一个item时加载下一页 recyclerView.addOnScrollListener(new RecyclerView.OnScrollListener() { @Override public void onScrolled(RecyclerView recyclerView, int dx, int dy) { int visibleItemCount = layoutManager.getChildCount(); int totalItemCount = layoutManager.getItemCount(); int firstVisibleItemPosition = layoutManager.findFirstVisibleItemPosition(); if (!isLastPage && (visibleItemCount + firstVisibleItemPosition) >= totalItemCount) { getHouseList(false); } } }); } }房源详情页的展示比较直接，用ViewPager做图片轮播展示房源多张图片，下面是房源的基本信息、房东信息、价格区间和房屋描述。底部固定两个操作按钮，左边是"联系房东"弹出底部的Dialogs，右边是"立即预订"跳转到订单确认页面。
下单页面的核心逻辑包括选择租期起止日期、系统自动计算总价、展示押金和中介费规则。金额计算必须放在后端做，Android端只负责传入日期参数，防止客户端被轻易篡改。这个设计虽然看起来不复杂，但确实是很多半路出家的项目容易漏掉的关键点。
3.4 管理员端业务逻辑：审核流程与数据看板
管理员端的功能其实不需要单独做一个App，因为管理员通常用的是后台系统。这套系统里管理员的功能嵌入在Web管理端或者Android的特定角色入口，核心操作是审核房源和管理用户。
房源审核的页面就是一个列表，展示所有status=0的待审核房源，管理员点击"审核通过"或者"驳回"后更新状态。对应的后端代码逻辑很简单：
@PutMapping("/api/admin/house/{id}/audit") public Result<?> auditHouse(@PathVariable Integer id, @RequestParam Integer status) { House house = houseMapper.selectById(id); if (house == null) { return Result.error("房源不存在"); } house.setStatus(status); houseMapper.updateById(house); return Result.success(); }数据统计模块可以用来做柱状图和饼图展示，比如统计每个月的成交订单数、不同类型房源的占比、各区域房源数量等。这个模块在答辩时是比较加分的展示点，老师一般都会很感兴趣。
4. 常见问题与排查技巧实录
4.1 Android连不上后端：WebView和模拟器的网络坑
这个绝对是遇到频率最高的问题。Android模拟器里访问宿主机有一个特殊的IP地址规则，localhost指的是模拟器自己而不是你的电脑。模拟器访问宿主机必须用10.0.2.2：
public static final String BASE_URL = "http://10.0.2.2:8080/api";如果你是用真机调试，就必须把IP地址改成电脑在局域网内的IP。可以在命令行敲ipconfig查看（Windows）或者ifconfig（Mac），然后填上类似192.168.1.5的地址。
另外，Android 9.0及以上系统默认禁止HTTP明文请求，虽然你的Retrofit地址写对了，依然会报CLEARTEXT communication not permitted错误。解决办法有两个：一个是在AndroidManifest.xml里配置android:usesCleartextTraffic="true"，另一个是写一个network_security_config.xml配置文件。
真机调试还有一个坑：电脑防火墙默认会拦截Android真机发来的请求。我第一次用真机调试时后端接口怎么都访问不了，关了Windows防火墙就好了。如果不想关防火墙，可以单独开放8080端口。
注意：在同一个局域网环境下，Android设备和后端服务所在的电脑必须处于同一网段。用公司或者校园网时要特别留意ACL隔离和Wi-Fi用户隔离，这种情况下怎么都连不上的话换个手机热点测试是最快的排查方式。
4.2 Spring Boot版本兼容性：最容易翻车的隐性问题
Spring Boot版本选错会导致一堆莫名其妙的依赖冲突。我建议大家认准Spring Boot 2.5.x到2.7.x这个版本区间，不管系统的pom里已经锁定了什么版本，尽量不要去手动升级成Spring Boot 3.x版本。Spring Boot 3对JDK版本要求变成了17+，而且很多第三方组件的API有变化，如果项目里用了旧的依赖，一升级整个项目就跑不起来了。
MyBatis Plus版本也要特别注意。当前项目的写法用的可能是3.4.x或者3.5.x的API，如果你换了一个版本，selectPage和Wrapper构造器的行为可能都有变化。最稳妥的办法是直接用项目自带的pom.xml和Maven仓库，不要自己动手改版本号。
另外MySQL 8.0和MySQL 5.7的驱动类也不一样。5.7用com.mysql.jdbc.Driver，8.0用com.mysql.cj.jdbc.Driver。如果用的是高版本数据库但配置的是旧驱动，启动报错会提醒你换驱动类，直接改配置就行。
4.3 图片上传失败：权限和大小限制的双重问题
房源发布时图片上传失败的频率非常高，分为两种情况。第一种是没配权限，Windows服务器上如果没有给uploads目录设置写入权限，文件保存时会抛出Permission denied。第二种是大小超限，这在前端容易被忽略，因为Android端选图时手机照片动辄几MB，但Spring Boot的默认上传限制是1MB。
解决的常规操作是两步：在后端application.yml调整大小限制到10MB或者更大；在Android端加一个图片压缩处理，用BitmapFactory.Options的inSampleSize来压缩大图。
以下是一个标准的图片压缩代码片段：
public static File compressImage(Context context, Uri uri, int targetWidth) { try { BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; BitmapFactory.decodeStream(context.getContentResolver().openInputStream(uri), null, options); int width = options.outWidth; int sampleSize = 1; while (width / sampleSize > targetWidth) { sampleSize *= 2; } options.inSampleSize = sampleSize; options.inJustDecodeBounds = false; Bitmap bitmap = BitmapFactory.decodeStream(context.getContentResolver().openInputStream(uri), null, options); File file = new File(context.getCacheDir(), System.currentTimeMillis() + ".jpg"); FileOutputStream fos = new FileOutputStream(file); bitmap.compress(Bitmap.CompressFormat.JPEG, 85, fos); fos.flush(); fos.close(); return file; } catch (IOException e) { e.printStackTrace(); return null; } }4.4 JWT用户登录丢失问题：误区与排气顺序
Android端登录成功后，后端返回的Token会保存在本地，每次请求在拦截器里统一添加Authorization头。如果出现了"用户未登录"报错，排查顺序先看Token在本地有没有存下来，再看请求头有没有正确添加，最后看服务端解析的时候有没有报异常。
我遇到过一种比较隐蔽的情况：用户登录成功，但隔了一天再来访问接口就报401。排查后发现是JWT过期时间设置成了12小时，而用户刚好是前一天晚上登录的，过了一天就一定过期了。解决办法是把过期时间拉长到7天，同时在前端做Token失效的拦截处理，收到401或者特定的业务码就跳回登录页，提示用户重新登录。这个方案既能保持良好的用户体验，也不会让会话无限期有效。
4.5 常见的报错速查表
| 现象 | 根本原因 | 解决方案 |
|---|---|---|
| 后端启动失败，报端口被占用 | 8080端口被其他进程占用 | 换个端口改成8090，或者杀掉占用进程 |
| Android连不上接口，一直转圈 | 模拟器用了localhost | 改成10.0.2.2，或真机用局域网IP |
| 上传图片提示文件过大 | Spring Boot默认1MB限制 | 配置文件上传大小到10MB |
| 数据库中文乱码 | JDBC连接没有指定字符集 | URL加characterEncoding=utf8 |
| 访问接口报CLEARTEXT错误 | Android 9+拦截明文HTTP | 启用usesCleartextTraffic |
| 刷新列表出现重复数据 | 分页页码没有正确加一 | 检查loadMore时的page增量逻辑 |
| 注册时提示用户名已存在 | 查询条件写错 | 检查selectOne的Wrapper条件是否正确 |
5. 这套源码附带资源包的使用建议
这套项目附带的内容不只是一堆代码文件，源码压缩包里通常包含四类东西：完整的Java后端源码、Android客户端源码、数据库SQL脚本和说明文档PDF、演示视频和讲解视频。很多人拿到手就急着跑代码，其实先花一点时间梳理包内结构会更高效。
建议的浏览顺序是：先看doc目录下的需求分析文档和数据库设计文档（理清系统是干什么的、表关系怎么样） → 再看项目的接口文档和部署说明（搞清楚接口和数据流向） → 然后按照部署文档把环境跑起来 → 最后再看演示和讲解视频，对照视频里的操作流程复现功能。这样从文档到运行再到理解，效率比直接看代码高得多。
讲解视频通常是讲解员边操作边讲解，内容会覆盖系统登录流程、各功能模块的操作演示、源码的目录结构和核心代码逻辑、数据库的导入步骤。这些视频的价值在于能快速告诉你"哪里是重点、哪里可能问什么"，在答辩前看一遍非常有帮助。
其实这个项目的文档资料做得比较完整，从需求分析、数据库设计、接口设计到测试用例都有覆盖。这对写自己的毕业论文或者设计报告有直接的参考价值，不需要全部照搬，但完全可以参照它的结构和表达方式来组织自己的章节逻辑。
6. 项目扩展思路：改造成更有竞争力的项目
如果一个基本完整的房屋租赁系统不足以让你在答辩中脱颖而出，可以考虑在它的基础上做一些低成本高回报的功能扩展。这些扩展不会改动系统的基本架构，但能在功能丰富度和技术深度上提升一个档次。
一个比较适合的扩展方向是引入Redis做房源浏览量的缓存和热门房源的排序。Spring Boot整合Redis的成本很低，引入spring-boot-starter-data-redis依赖，然后对访问量高的接口做缓存处理。比如房源的详情数据用Redis缓存，每次访问先查缓存、再查数据库，可以明显提升接口的响应速度，答辩的时候解释起来也很好懂："我用了Redis做热点数据缓存，压测QPS提升了X倍。"
另一个方向是做简单的推荐算法。根据用户的浏览记录和收藏记录，用基于类别的协同过滤思想，推荐类似的房源。虽然实现不了太复杂的算法模型，但用SQL或者简单的Java逻辑就能实现"看了又看"的推荐效果。
还可以把管理员后台从简单的页面升级成Vue + ElementUI开发的管理系统，通过前后端分离的方式调用后端接口。这个扩展也很有吸引力，技术点从"Spring Boot + Android"升级成了"Spring Boot + Vue + Android"前后端分离全栈架构。
如果你准备把系统部署到服务器上让外部访问，注意三个点：服务器安全组放行8080端口、MySQL的远程访问权限、后端接口的跨域配置。CORS跨域可以在后端写一个WebMvcConfigurer实现addCorsMappings方法，允许前端访问。
7. 实操总结：从拿到项目到顺利演示的关键经验
整套系统从零开始跑通，我自己走了一遍下来，最大的体会是：比起代码本身，跑通环境和理清数据流是更花时间的事。如果你拿到这套源码，请一定严格按照文档里写的环境版本来配置，不要凭感觉用最新的JDK、最新的Spring Boot版本，否则各种隐性问题会消耗掉大量没必要的时间。
另外，建议所有演示前先自己做一遍完整的演示流程：登录、发布房源、管理员审核、租客看房下单、评论、数据统计。不要觉得步骤熟了就可以跳过实操模拟，真实演示环境下的卡顿和Bug往往都是因为跳过了准备步骤。
说到底，毕业设计做得精不精彩，关键不在于用了多高级的技术栈，而是你把一个完整的问题用可运行、可维护、有文档、可演示的方式进行了解答。这套Spring Boot + Android的房屋租赁系统，技术路线不算花哨，但是胜在扎实、完整、能跑，配合它的文档和视频，确实是一个值得推荐的参考项目。
