1. 项目概述与核心需求拆解1.1 这类酒店管理系统到底解决了什么问题上半年陆续帮几个学生调过类似的项目看到“Java springboot基于Android的酒店管理系统”这个标题基本就能猜到它长什么样一个用 SpringBoot 写后端接口用 Android 原生写的手机端订房/管理应用再配上一份数据库脚本、一份毕业论文和几个演示视频。它是计算机专业毕业设计里出场率极高的题目但正因为太常见反而拉不开差距。真正拉开差距的是你有没有把里面的每一个模块都弄懂能不能在答辩时讲清楚“为什么这么做”而不是只会照着视频敲代码。酒店管理系统的核心业务其实不复杂无非是房间管理、客户入住退房、订单记录、会员信息这几块。麻烦的地方在于它同时涉及两个端Android 端面向住客负责看房、订房、查询订单后端要同时服务好这个手机端还要预留后续扩展的可能比如以后加一个网页后台管理端。这种“一个后端服务多个客户端”的结构正好是 SpringBoot 最擅长的场景。所以这个题目看起来很普通但它把“前后端分离”“接口设计”“移动端适配”这些实际开发中特别重要的概念都串起来了认真做完一遍比看十遍教学视频都管用。1.2 技术选型背后的逻辑为什么是SpringBoot Android先说说这个组合的合理性。SpringBoot 能成为 Java 后端的绝对主流不是因为它性能有多极致而是因为它把“搭一个能跑的服务”这件事的成本降到了极低。内嵌 Tomcat、自动配置、starter 依赖几行代码就能起一个 Web 服务。对毕设来说这意味着你不用花大量时间在环境配置上可以把精力放在业务逻辑上。而且 SpringBoot 生态成熟你要用的所有东西几乎都有现成的 starter这对新手极其友好。Android 端的选型同样务实。虽然现在很多项目喜欢用 uniapp 或 Flutter 做跨平台但毕设场景下原生 Android 反而是更稳的选择。原因很简单原生开发的环境链最透明出问题能查到明确的原因你写的每个页面、每个请求都是实实在在的 Java 代码答辩时能讲的东西更多。用跨平台框架虽然开发快但很多东西被封在框架里老师一问底层原理就容易卡壳。我见过不少学生纠结“要不要用 Vue 做个后台管理页面”我的建议是如果时间和精力允许可以加但要在保证手机端和后端都完整可运行的前提下。这个项目真正的主线是 Android 端 SpringBoot 后端先把这条线走通再去考虑扩展。而且标题里提到的“源码文档运行视频讲解视频”这类交付物本质上要的是一个完整闭环不是花架子。提示如果后端是 2.x 版本Java 用 8 或 11 都行如果选的是 SpringBoot 3.x那 Java 必须 17 以上。这个版本匹配问题在下面会详细讲它是新手最容易踩的第一个坑。2. 数据库设计与后端工程结构2.1 数据表的核心设计思路酒店管理系统的表结构成熟的做法是五到六张表用户表、房间类型表、房间表、订单表再加一张管理员表。会员和用户通常可以合并成一张用户表用一个字段区分身份。这个设计看似简单但每一张表的字段都是有讲究的。用户表至少要包含手机号、密码、昵称、注册时间手机号要加唯一索引因为登录逻辑通常就是“手机号 密码”。房间类型表要区分价格和床型比如大床房、双床房、套房因为 Android 端首页的房型列表就是直接查这张表。房间表要关联房间类型表同时需要一个状态字段0 表示空闲1 表示已入住2 表示打扫中。订单表是最核心的表要包含订单号、用户 ID、房间 ID、入住日期、退房日期、实际金额、订单状态、创建时间。这里有一个特别容易忽略的点金额字段千万别用 double 或 float。数据库里要存小数金额用 decimalJava 实体类里对应的是 BigDecimal。为什么因为二进制浮点数在运算时会有精度丢失虽然十几块钱看不出问题但累计起来就可能出现 0.01 的误差而且答辩时老师很可能问到这一点你答“用 BigDecimal 避免精度丢失”是非常加分的点。SQL 语句我在下面给一个简化版本大家感受一下表结构的样子。实际项目建议用 MyBatis-Plus 的代码生成器或者让 MyBatis-Plus 根据实体类自动生成建表语句省时省力。2.2 SpringBoot后端的关键功能点拆解后端的功能模块按接口维度拆分大概是这么几块用户注册登录、房型列表查询、房间详情、创建订单、我的订单列表、订单详情、取消订单、管理员登录、房间管理、订单管理。每一块都不难但组合起来就是一个完整的系统。用户登录这块我的建议是不要用 JWT直接用 Session 或者简单的 Token 就够了。毕设项目用 JWT 会让代码复杂不少而且涉及密钥管理、过期刷新这些问题属于“用了但讲不清原理”的典型情况。用 Session 的好处是你可以在拦截器里直接判断用户是否登录逻辑非常直白。如果确实想用 Token就简单一点登录成功后生成一个 UUID 字符串存到 Redis 或者数据库表里前端每次请求带着后端对比一下是否有效。这种简化方案完全能支撑毕设的功能需求答辩时也能把原理讲清楚。订单流程是最能体现业务逻辑的地方。用户在 Android 端选好房型、填入住和退房日期后端要先计算总价。怎么算房间类型表里有一个每天的价格字段入住和退房日期相减得到天数乘以每日价格就是总金额。但这里有个隐藏需求同一种房型在不同日期可能价格不同比如周末涨价。如果毕设想做得更有深度可以加一张房价日历表按日期存价格但基础版本直接用固定单价也是完全合格的。入住日期和退房日期的校验也要做退房必须晚于入住这个前后端都要校验。后端校验的意义在于不能只依赖前端因为接口可以被任何人直接调用。还有一个点值得单独说后端返回给 Android 端的数据格式。我强烈建议统一用{ code: 200, message: success, data: ... }这种结构并用一个 Result 类来封装。这样做的好处太多了最关键的是前端解析变得非常统一不管请求哪个接口先判断 code 是不是 200再看 data。如果有的接口直接返回对象、有的返回 List、有的返回 null前端代码会写得很痛苦。2.3 关于MyBatis-Plus的一个实用技能热搜词里有一条“mybatisplus根据java实体类生成创建表的sql语句”这说明很多人已经用上了 MyBatis-Plus 但还没玩明白它的附加能力。MyBatis-Plus 确实能根据实体类生成建表 SQL但不是它内置的核心功能通常配合 MyBatis-Generator 或专门的工具来实现。实际操作中我更推荐根据实体类反推表结构然后手工写建表 SQL因为表结构的字段注释、索引这些信息写在 SQL 里最直观。MyBatis-Plus 的代码生成器更适合反过来用根据表结构生成实体类、Mapper、Service这也是我们项目中实际用到的方向。如果你用的是 Spring Initializr 创建项目勾选 MyBatis 框架只需要加两个依赖mybatis-plus-boot-starter和mysql-connector-java。在 application.yml 里配置数据源、MyBatis-Plus 的逻辑删除、驼峰命名映射这些参数后CRUD 基本就不用自己写 SQL 了。但注意多表查询还是要写 XML 或注解 SQLMyBatis-Plus 的 LambdaQueryWrapper 虽然强大它在单表查询上几乎是无敌的。3. Android端实现与前后端联调3.1 Android端页面与功能的组织Android 端这边我建议把功能分为三个大的 Tab首页、订单、我的。首页展示房型列表点击进入房型详情可以填写入住退房日期并提交订单。订单页展示当前用户的所有订单区分待入住、已入住、已完成、已取消几种状态。我的页面就是个人信息展示和退出登录。页面结构不建议搞太复杂用 LinearLayout 和 RecyclerView 就能解决大部分场景。很多新手一上来就想着用 Fragment 嵌套、ViewPager2、底部导航栏这种复杂的结构结果把自己绕晕了。其实一个 Activity 三个 Fragment 一个底部导航完全够用。如果你用 Android Studio 的新模板它会自动生成 Bottom Navigation 的 Activity 模板直接基于那个改就行。网络请求这块主流方案是 Retrofit OkHttp Gson。Retrofit 的好处是把接口定义、参数序列化、响应解析全部封装好你只需要定义接口方法和数据模型。注意要封装一个单例的 RetrofitClient统一配置 BaseUrl 和拦截器。这里有一个我踩过的坑BaseUrl 必须以/结尾否则会报 “must end in /” 的异常别看这是个小问题第一次遇到能卡半小时。视图层的数据绑定简单项目可以不用 ViewBinding 或 DataBinding直接 findViewById 也行。但如果你的 RecyclerView 列表项比较多建议了解一下 ViewBinding它能帮你省掉很多类型转换的模板代码而且 Google 官方现在是默认推荐 ViewBinding 的。3.2 与后端联调的三个核心问题联调是这类项目里最折磨人的环节问题几乎都集中在三处网络地址、明文请求、端口访问。第一个是地址问题。如果你用 Android 模拟器访问电脑本地的后端服务不能用 localhost 或 127.0.0.1要用 10.0.2.2。这是 Android 模拟器的特殊规则因为模拟器里的 localhost 指向的是模拟器自己。如果你用真机调试手机和电脑必须在同一个 WiFi 下然后通过电脑的局域网 IP 访问比如http://192.168.x.x:8080。这个问题不问清楚后端明明跑得好好的手机端却死活连不上。第二个是明文 HTTP 问题。Android 9.0 之后系统默认禁止应用使用明文 HTTP 流量。你开发调试时用的是http://不是https://所以必须在 AndroidManifest.xml 里配置android:usesCleartextTraffictrue或者配置网络安全策略允许特定域名走明文。这个不配置你会直接看到 “CLEARTEXT communication not permitted” 的报错很多人第一次碰到根本不知道是为什么。第三个是端口占用问题。SpringBoot 默认端口是 8080如果你机器上已经有别的服务占了 8080后端启动会直接失败。解决办法很简单在 application.yml 里换一个端口比如 8081然后记得把 Android 端的 BaseUrl 也一起改掉。我见过最离谱的情况是学生换了端口忘了改前端查了半天才发现 BaseUrl 里还写的是 8080。3.3 Android端开发工具选择开发 Android 端现在官方推荐的是 Android Studio版本要选最新的稳定版。创建工程时选 Empty Views Activity 就行别用 Compose 模板因为大多数毕设项目的老师不熟悉 Compose而且你网上找到的参考代码大多是传统的 XML 布局跟着教程走更顺。模拟器建议创建 Pixel 4 或 Pixel 5 的镜像系统版本选 API 30 或 31接口版本稳定兼容性好。如果你电脑性能一般用真机调试反而比模拟器流畅但要注意上面说的同一局域网问题。4. 环境搭建与项目运行全流程4.1 基础环境JDK、Maven、MySQL、Android Studio在动手跑项目之前先把环境检查一遍。后端需要 JDK、Maven、MySQL这三个缺一不可。JDK 版本要和 SpringBoot 版本对应SpringBoot 2.x 用 JDK 8 或 11SpringBoot 3.x 用 JDK 17。Maven 用 3.6 或 3.8 都行它是 Java 项目的依赖管理和构建工具不用单独下装上 IDEA 后它自带 Maven 插件但最好还是装一个独立的 Maven 并配置好阿里云镜像不然下载依赖的速度会让你怀疑人生。阿里云镜像配置在settings.xml里加一个 mirror 节点指向https://maven.aliyun.com/repository/public这个谁用谁知道。MySQL 建议装 8.0 版本5.7 也没问题但注意 8.0 的驱动类名是com.mysql.cj.jdbc.Driver连接 URL 要加serverTimezoneAsia/Shanghai否则会报时区错误。这一点对新手特别不友好因为报错信息很长关键内容被淹没在里面。Android Studio 装好后SDK 管理里至少需要一个 API 30 以上的平台。创建模拟器时要选带 Google APIs 的系统镜像否则有些功能在模拟器里不可用。首次启动 Android Studio 会花很长时间下载组件如果网络不好一定要配置国内镜像这是无数人卡住的第一道关。4.2 后端启动步骤与验证后端项目拿到手以后第一步不是急着启动而是先看配置。打开application.yml确认数据源配置正确数据库名称要和你的本地数据库对应。然后打开 SQL 脚本在 Navicat 或命令行中执行把表结构和基础数据建好。基础数据至少要包含几条房间类型记录和房间记录不然 Android 端首页列表是空的看起来像没跑起来一样。启动后端前我建议先在 IDEA 里执行mvn clean install或直接mvn clean compile确认代码没有编译错误。然后点击 Application 类的 main 方法启动。看到类似于Started Application in x.xxx seconds的日志说明启动成功。为了验证接口是否正常用浏览器直接访问http://localhost:8080/接口路径如果能返回 JSON 数据说明后端完全正常。这里要补充一个非常常见的坑启动时提示Port 8080 was already in use。这个用上面的方法两步处理找到占用进程杀掉它或者在配置文件里换端口。很多毕设资料里自带的视频演示用的是 8080如果你换了端口记得全程统一别出现前端连 8081、后端跑 8080 的分裂情况。4.3 Android端启动与模拟器调试Android 端的启动分为两步先用 Android Studio 打开项目等 Gradle 同步完成。这一步最容易出问题的是 Gradle 版本和 Android Gradle Plugin 版本不匹配。如果你下载的是别人分享的源码对方的 Gradle 版本可能和你本地不一致这时不用紧张把项目里的 Gradle wrapper 版本改成你自己 AS 兼容的版本然后重新同步。只要代码本身没有语法错误Gradle 同步成功基本就能 Run。运行起来之后第一件事是看能不能拉到后端的数据。如果首页列表空白先查后端日志有没有请求进来。没请求进来说明 Android 端的 BaseUrl 配得不对有请求但列表还是空说明返回的数据结构和 Android 端的数据模型对不上重点检查 JSON 字段名和实体类的字段名是否完全一致比如后端返回roomType你在前端却定义成room_typeGson 不会自动帮你转直接解析失败。4.4 “热词”里的版本坑SpringBoot版本太高引发的连锁问题有一个热搜词“springboot版本太高”特别值得说。很多学生拿到项目后习惯性去 Spring Initializr 创建最新版 SpringBoot 3.x 项目。3.x 本身没问题但它会连锁引发一系列问题JDK 必须 17 以上、javax 包名变成了 jakarta、部分老教程里的写法失效、MyBatis-Plus 需要 3.5.3 以上版本才支持。如果项目资料里原本用的是 SpringBoot 2.7 JDK 8你盲目升到 3.x代码大概率改得面目全非。我的建议是这个项目如果资料是 2.x 版本就老老实实用 2.x不要追求新版本。能用、能跑、能答辩比什么都重要。5. 常见问题与排查技巧实录5.1 后端常见问题速查现象原因处理方式启动报时区错误MySQL 8.x 连接 URL 未加 serverTimezone在 jdbc url 加?serverTimezoneAsia/Shanghai端口被占用8080 被其他程序使用换端口或杀掉占用进程注意前端 BaseUrl 同步改依赖下载失败Maven 源是国外仓库配置阿里云镜像到 settings.xml中文乱码数据库或接口编码不一致统一为 UTF-8URL 加characterEncodingutf8实体类映射表名失败表名与类名不一致用TableName指定表名或开启驼峰映射5.2 Android端常见问题速查现象原因处理方式访问不到后端模拟器用了 localhost模拟器改用 10.0.2.2真机用局域网 IP报 CLEARTEXT 错误默认禁止明文 HTTPManifest 配置 usesCleartextTraffic列表数据解析为空JSON 字段名与实体类不一致用 Gson 的SerializedName或统一命名风格Gradle 同步失败插件版本与 AS 不兼容修改 Gradle 和 AGP 版本重新 Sync数字格式化异常金额或日期格式不一致确认后端返回格式前端用对应类型接收5.3 排查思路先定位问题在哪一层这些坑挨个说的时候都简单但真实情况往往是多个问题叠加在一起。我在帮学生排查时最常用的手段是“分层定位”先确认后端能不能通过浏览器/Postman 正常返回数据能就说明问题出在 Android 端不能说明问题在后端比如数据库连接、SQL 语句、端口等。然后一层一层往前推。这一招看着简单却是最有用的排查方法比瞎改代码强一百倍。还有一个小技巧Android 端用 OkHttp 拦截器把请求和响应的完整日志打出来或者在关键位置加 Log。不用来回猜日志会告诉你问题到底出在哪里。永远不要在自己脑子里做“推理”要根据日志和数据来做判断。6. 源码、文档、运行视频、讲解视频四大件的使用建议6.1 怎么用源码而不是被源码用很多同学拿到一份完整项目后第一反应是“跑起来就算完事”。这种心态我理解但非常不建议。正确做法是先把项目跑通然后从登录接口开始对照源码逐行读一遍看看别人是怎么写的。不需要读懂每一行重点是搞清楚“一条请求从前端页面到后端数据库的完整链路”。你只要能把这一条链路讲清楚答辩已经成功了一大半。源码里有些代码是“冗余但正确”的比如某些工具类可能写得很全但实际没用到这是作者为了完整性或演示效果留下来的。读源码时不要被这些干扰按核心业务流程去读就好了。真正重要的是 Controller、Service、Mapper 这三层之间的调用关系以及 Android 端 Retrofit 接口方法和后端 Controller 的映射关系。6.2 文档怎么改才能过查重毕设文档是另一个重头戏。我见过很多学生拿到参考文档后改几个关键词就交上去了结果查重率 80% 多直接被毙。正确的改法是先读懂原文档的逻辑用自己的话重新表述同时把项目里的真实截图、真实测试数据替换进去。比如文档里写“系统采用 B/S 架构”你可以改成“系统的后端服务以独立进程运行Android 客户端通过 HTTP 接口访问从部署形态上看是 C/S 与 B/S 的混合模式”既保留了技术含量又完全换了表述方式。文档结构通常包括绪论、需求分析、系统设计、数据库设计、系统实现、系统测试、总结。这里最重要的章节是需求分析和数据库设计因为老师最可能在答辩时从这两个章节里挑问题。你需要把用例图、E-R 图、数据表结构都讲清楚这些内容在数据库设计文档里都有对应内容。6.3 运行视频和讲解视频的正确用法运行视频的作用是让老师看到一个能跑的系统讲解视频则是老师了解项目思路的重要途径。如果你是自己拍演示视频我建议按三条线来录第一条线是正常业务流用户注册→登录→查看房型→提交订单→查看订单第二条线是后台管理流管理员登录→管理房间→查看订单列表第三条线是异常流程比如重复提交订单、日期不合法、密码错误展示系统的容错能力。这三条线录完项目完整性非常强。讲解视频的时长控制在 20 到 30 分钟。先介绍项目背景和技术栈然后打开数据库看表结构再启动后端最后演示 Android 端功能。讲解时要注意把“为什么这样做”讲出来不要让老师觉得你只是在背操作步骤。比如演示到订单价格计算时可以主动讲价格是怎么算的遇到跨天房间怎么处理。这种细节非常加分。7. 从完成项目到准备答辩的最后一公里答辩是这类项目的最后一关。老师最爱问的问题翻来覆去就是几类为什么选这个技术栈、某张表为什么这么设计、某个接口怎么处理并发、如果用户量大了怎么办、订单支付流程有没有考虑。提前把这些问题梳理一遍当成“八股文”背熟面试答辩时就能对答如流。其中“技术选型为什么”几乎必问我建议你的答案里一定包含以下逻辑SpringBoot 选型是因为它自动配置能力强开发效率高社区生态完善能快速构建可维护的 RESTful APIAndroid 原生选型是因为需要调用系统的网络、存储能力原生开发性能更好、可控性更强。这个答案并不是空话你只要在项目里用过这些特性就完全能支撑起来。还有一个很多人忽略但特别关键的数据库设计里的“外键”问题。不少参考项目会在订单表里加外键约束但实际开发中更推荐用逻辑外键而非物理外键。为什么因为物理外键在删除、更新时会影响性能而且在分库分表场景下根本没法用。答辩时可以主动讲这一点会显得你对数据库设计有真正的思考。最后再分享一个我在多次调试中总结出来的心得这类项目从拿到手到完全跑通绝大多数问题都不是代码的问题而是环境的问题。JDK 版本、Maven 仓库、端口冲突、模拟器网络、数据源配置这些环境细节占据了调试时间的七成以上。所以如果你现在正被某个报错折磨别怀疑自己的代码能力先冷静下来一层一层看日志按“配置文件→端口→网络→数据库→代码”的顺序排查基本上都能搞定。等你把这些环境问题全部踩过一遍你对 SpringBoot 和 Android 联调的理解就已经超过大多数只会照着视频敲代码的人了。