南瑾i一到毕业季，“Java springboot基于Android的旅游攻略系统”这类题目几乎是计算机专业选题里的常青树。我之前帮不少同学看过这套类似的代码，也踩过不少坑，发现一个很普遍的现象：代码能跑、App能打开、录个演示视频没问题，但只要答辩老师多问一句“数据库表是怎么设计的”“接口返回结构是什么”“为什么模拟器能联网、真机却连不上”，很多人就开始支支吾吾。
这篇文章不打算复读某个开源仓库里的README，而是把“Spring Boot 3.x + Android 原生”这套旅游攻略系统当成一个真正的前后端分离项目来拆。从选题定位、数据库设计、后端接口实现，到Android端请求封装、图片上传、真机联调，再到毕设答辩前最该检查的那几个坑，我会把涉及到的关键代码和判断逻辑全部写出来。不管你是准备拿现成源码改成自己的毕设，还是从零开始自己写一个，按这套思路走完，你对整个系统的理解会明显不一样。
1. 项目整体设计与技术选型思路
1.1 选题定位：毕设场景下如何把“旅游攻略”做出区分度
旅游攻略系统这个方向，本质上是一个带内容管理属性的信息展示类项目。用户注册登录后可以浏览景点、查看攻略、收藏内容，管理员在后台维护景点和攻略数据。功能点看着很常规，但它非常适合用来展示一个学生完整的工程能力，原因有三个：
第一，业务链路完整。登录、列表、详情、发布、收藏、评论，每个环节都有对应的HTTP请求和数据库操作，能覆盖Java Web开发的主要知识点。
第二，前后端天然分离。服务端用Spring Boot提供RESTful接口，Android端通过网络请求消费这些接口，这就比单纯搞一个Thymeleaf或JSP的SSM项目更有说头，也更能体现“接口设计能力”。
第三，可扩展空间大。答辩时如果老师问“你的项目有什么改进方向”，你可以说加路线规划、加LBS定位推荐、加Redis缓存热门景点、加ElasticSearch搜索攻略，这些都属于安全且常见的扩展点。
不过也要提醒一句，正因为这个题目太多人做，想把分数拉上去，关键不是堆功能，而是把基础模块做扎实。我见过不少人的项目里景点表和攻略表就两三个字段，接口直接返回整个List不分页，Android端也没有统一的网络层封装。这种代码即使能跑，答辩时老师拿眼睛扫一眼项目结构，也知道你只是把别人代码改了个名字。所以下面讲的很多细节，其实都是围绕“让这个普通的选题看起来像正经工程项目”来展开的。
1.2 技术栈选择：为什么是Spring Boot + Android原生
后端选择Spring Boot，基本不需要纠结。Spring Boot的自动配置和起步依赖能极大减少搭建成本，内嵌Tomcat让部署演示变得简单，而这些正好命中毕业设计最在意的“快速跑通”。但要注意版本选择，我强烈建议不要一上来就选Spring Boot 3.x，而是优先考虑2.7.x。很多网上的项目资料、教程、视频都停留在2.x时代，如果用3.x，原本的javax.servlet包会变成jakarta.servlet，部分第三方starter也会出现兼容问题。除非你对依赖冲突有足够的排查经验，否则老老实实选2.7.18这类稳定版本，能帮你省下大量折腾时间。
Android端选原生开发而不是Uniapp或Flutter，核心原因是这门课通常教的就是Java或Kotlin原生开发。使用RecyclerView、CardView、SharedPreferences这些系统组件写出来的项目，在答辩演示时更符合课程要求。更重要的是，很多高校评委对跨平台框架并不熟悉，你解释不清楚反而容易减分。原生Android配上Retrofit + OkHttp + Glide这套组合，既成熟又够用，也是搜索相关教程时最容易找到答案的技术栈。
1.3 功能模块划分：前后端各需要做哪些事
一个能够正常演示的旅游攻略系统，从用户视角出发至少需要六个核心功能：注册登录、景点列表、景点详情、攻略列表与发布、收藏、个人中心。服务端对应的是用户表、景点表、攻略表、收藏表、评论表这几张核心表的数据读写。Android端则负责页面展示、用户交互、Token保存与图片上传。
从开发顺序上，我建议先完成后端接口，再用Postman或Apifox把每个接口调试通，然后才动手写Android端的页面。原因是，如果你先把页面画好了再联调接口，一旦后端字段名和前端对应不上，改起来就非常痛苦。作为过来人，这个顺序我踩过很多次坑，先定契约、再填页面，是效率最高的方式。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 服务端核心模块实现：从建表到接口一次讲透
2.1 数据库设计：五张表的字段与关系
数据库设计是答辩时老师最常追问的部分。这套系统的核心关系不复杂，设计上遵循两个原则：能拆的表尽量拆开，避免一张大表装所有内容；关联字段尽量使用逻辑外键，不一定要在数据库层面建物理外键，但Java实体里要能体现关系。
用户表、景点表、攻略表各是一个独立实体。收藏表和评论表都依赖于用户与其他表之间的关联。这里把最关键的几张表列出来供参考：
| 表名 | 关键字段 | 说明 |
|---|---|---|
| t_user | id, username, password, nickname, avatar | 用户信息，密码用MD5或BCrypt存储 |
| t_scenic | id, name, cover, location, price, description, detail | 景点基础信息，图片存URL路径 |
| t_guide | id, user_id, scenic_id, title, content, cover, create_time | 攻略内容，与用户和景点关联 |
| t_favorite | id, user_id, scenic_id, create_time | 收藏关系表，联合唯一索引 |
| t_comment | id, user_id, guide_id, content, create_time | 评论表，按攻略维度组织 |
这里有一个容易忽略的设计点：攻略表的scenic_id要不要设置必填？很多真实场景下，用户发攻略未必绑定具体景点，但毕业设计为了展示关联查询，建议必填。这样在Android