又到一年毕设季每年这个时候“Java Spring Boot Android旅游攻略系统”这类题目都会被反复翻出来。这个题目热度高不是没道理的——它覆盖了后端、移动端、数据库三大块难度适中技术栈通用既能锻炼完整项目能力又不至于让大部分同学卡死在底层细节里。我的这个项目不是那种随手写的demo而是把用户端后台管理端、旅游景点、攻略文章、评论、收藏、分类搜索这些功能都做了闭环配合完整的数据库设计和接口文档适合拿来当课程设计、毕业设计甚至后续找工作时的项目经验。能做什么先给你一个直观感受Android端打开App可以注册登录、浏览景点列表、查看景点详情、阅读旅游攻略、发表评论、收藏喜欢的内容、按关键词搜索后台管理端网页可以维护景点信息、审核攻略文章、管理用户和评论数据。前后端数据通过RESTful API交互整个项目跑起来之后一套完整业务流程是通的。适合谁用呢基础是学了Java和数据库原理、但对Spring Boot和Android开发还比较陌生的同学或者自己有项目经验、想快速套一个完整系统来应付毕设/面试的人。这套系统我最早是给自己带的几个学生做的后来陆陆续续改了好几版踩了不少坑。今天就把整个设计思路、核心实现、实操过程、以及那些文档里不会写的问题排查经验全部整理出来你照着这个思路走能省掉大量自己摸索的时间。1. 项目整体设计与思路拆解1.1 系统定位与技术选型毕设项目的核心矛盾永远是“工作量够不够”和“能不能跑通”。很多同学上来就想上微服务、Redis缓存、消息队列结果自己把自己坑了。旅游攻略系统本质是一个内容型应用核心数据模型是“用户-景点-攻略文章-评论-收藏”这个规模下单体应用就是最合理的架构。我的技术选型这样定后端Spring Boot 2.x MyBatis-Plus MySQL 5.7构建 RESTful API移动端Android原生Java开发网络层用Retrofit Gson图片加载用Glide管理端为了控制工作量直接复用后端接口用简单的Thymeleaf页面做后台管理界面为什么不用Vue写管理端因为对大部分没接触过前端工程化的同学来说Vue ElementUI那套Node环境、跨域配置、打包部署的坑比后端本身还多。Thymeleaf是Spring Boot原生支持的模板引擎语法简单一个Spring Boot项目就能同时搞定API和后台页面省掉一整个前端的部署复杂度。Spring Boot 2.x而不是3.x这也是一个重要的考虑。Spring Boot 3要求JDK 17很多学校机房和教程环境还停留在JDK 8而且大量第三方组件对3.x的兼容并不完善。我实测下来2.7.x版本最稳定组件兼容性也最好。记住一个原则毕设项目不追新版本追的是“跑得起来、答辩稳得住”。1.2 功能模块规划整个系统的功能模块可以拆成两大端清晰分离开用户端Android App注册登录手机号/用户名 密码登录成功后返回token保持会话状态首页景点列表分页加载支持按分类筛选和关键词搜索景点详情图文介绍、评分、地址、开放时间、所属分类攻略模块查看攻略列表、攻略详情富文本内容、发表攻略评论与收藏对景点发表评论、点赞/取消点赞、收藏景点个人中心我的收藏、我的评论、我的攻略、修改资料后台管理端Web页面管理员登录景点管理增删改查、上下架、上传景点图片攻略管理审核/删除用户发布的攻略评论管理删除违规评论用户管理查看用户列表、禁用账号这个功能划分有几个巧思后端的CRUD四件套增删改查完整覆盖了用户端和管理端都有了图片上传、权限控制用户/管理员两种角色、关联查询景点关联攻略、评论关联用户都涉及了这些点恰好是答辩时老师最喜欢问的也刚好是评分表里的加分项。1.3 数据库表设计思路数据库设计往往是先画ER图再建表但实际写代码时我习惯反过来——先思考接口需要什么数据再决定表结构。因为接口的输入输出决定了表的字段表驱动接口容易导致接口设计别扭。核心表一共5张user表用户信息区分role字段0普通用户1管理员scenic表景点信息包含标题、描述、详情、图片、分类、评分、地址article表攻略文章包含标题、正文、封面、作者id关联user、审核状态comment表评论包含评论内容、用户id、景点id、评论时间favorite表收藏关系表用户id 景点id联合唯一这5张表基本能把所有业务串起来。我见过很多同学把表设计得特别散一看就是故意凑数量反而让关联查询复杂得不行。表设计讲究的是朴素正确不是花哨。2. 核心细节解析与实操要点2.1 Spring Boot后端从配置到接口的核心细节后端工程结构上我用标准的三层架构Controller接口层- Service业务层- Mapper数据访问层这是大家都懂的结构但有几个细节你要注意。application.yml是后端的命门。我习惯把数据库配置、端口配置、MyBatis-Plus日志、文件上传大小全部集中管理server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/travel_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: id-type: auto这里有两个藏在细节里的重点。第一serverTimezoneAsia/Shanghai是必须加的不加就会遇到“数据库连接失败”的经典报错而且报错提示和真正原因完全对不上能卡住你半天。第二map-underscore-to-camel-case这个配置非常关键它让数据库的create_time字段能直接映射到Java实体类的createTime属性不用每处都写TableField注解。MyBatis-Plus的选型也是一个很实际的决定。相比原生MyBatis需要手写大量XML映射文件MyBatis-Plus内置了CRUD方法selectById、selectPage、insert、updateById这些基础操作直接可用省掉大约60%的重复代码。复杂查询再通过Wrapper条件构造器解决比如搜索景点QueryWrapperScenic wrapper new QueryWrapper(); wrapper.like(StringUtils.isNotBlank(keyword), name, keyword) .eq(categoryId ! null, category_id, categoryId) .orderByDesc(create_time); PageScenic page new Page(current, size); scenicMapper.selectPage(page, wrapper);这个方法不仅省了SQL而且MyBatis-Plus的Wrapper自带条件判断第一个参数为false时自动忽略该条件不用自己写一堆if判断拼接SQL代码清爽得多。接口层需要统一返回格式。我定义了一个通用返回体Result包含code状态码、msg提示信息、data数据所有接口统一返回这个格式。这样做的好处是Android端解析JSON时只用处理一种结构而且可以统一拦截业务错误。2.2 Android端开发的关键实现点Android端是很多人真正头疼的地方因为安卓开发涉及UI、网络、线程、本地存储一堆东西交织在一起。我的经验是把它拆成几层逐层处理。网络层用Retrofit接口定义为Java接口把后端每个URL映射成方法。举例用户登录的接口public interface ApiService { POST(user/login) CallResultVOUser login(Body LoginRequest request); GET(scenic/page) CallResultVOPageResultScenic getScenicPage( Query(current) int current, Query(size) int size ); }使用的时候要记住网络请求必须放在子线程Retrofit的enqueue方法内部已经做了异步处理回调方法自动切回主线程这个机制要理解透不要去手动开线程容易乱套。登录状态保持我用的是SharedPreferences保存token。用户登录成功后后端返回token和一个user对象Android端把token存起来之后的每次请求都在拦截器里给请求头加上tokenRequest.Builder builder originalRequest.newBuilder() .header(token, token) .method(originalRequest.method(), originalRequest.body());这个拦截器是OkHttp提供的功能位于Retrofit底层。实现这个拦截器之后不用在每个接口调用处手动传token全局自动生效能省事不少。UI层面列表页用RecyclerView FastAdapter或BaseQuickAdapter。图片加载统一用Glide一行代码解决网络图片的加载、缓存、占位图问题不需要自己管理线程池和缓存。地图这块如果有需要比如景点位置展示可以接高德地图SDK但要注意注册开发者账号拿到Key这个Key要在清单文件和代码里都配置。Android还有一个绕不开的坑是异步更新UI。很多人第一次写的时候会在子线程里直接改UI控件结果应用闪退。Android原生开发规定必须在主线程更新UIRetrofit的enqueue回调已经自动切回主线程了但如果你用了RxJava或者自己开线程就得手动runOnUiThread。2.3 图片上传和富文本内容存储景点图片和攻略封面是另一个容易忽视的部分。我的做法是Android端把图片文件转成Base64编码字符串通过JSON传给后端后端收到后解码成图片文件保存到服务器本地返回图片访问URL给前端。这种方法稳定不需要额外搭建OSS或文件服务器毕设场景的数据量完全够用。// 后端接收Base64图片 public String uploadImage(RequestBody MapString, String body) { String base64Data body.get(base64Image); // 去掉data:image/jpeg;base64, 前缀 byte[] bytes Base64.getDecoder().decode(base64Data.split(,)[1]); String fileName UUID.randomUUID().toString() .jpg; File file new File(uploadDir, fileName); FileUtils.writeByteArrayToFile(file, bytes); return /upload/ fileName; }攻略文章的正文我用的是HTML格式。Android端的WebView控件可以直接渲染HTML内容不需要引入很重的富文本编辑器。用户发布攻略时在App里也是用WebView配合一个简单的HTML编辑器实现这样存到数据库里就是这个HTML字符串展示时直接WebView加载天然统一。3. 实操过程与核心环节实现3.1 搭建数据库从实体类到建表SQL的快捷路径先建数据库和表还是先写Java实体类根据我的经验推荐先画好实体类再用MyBatis-Plus的插件直接生成建表SQL。很多同学不知道IDEA插件市场里有一个“MyBatis-Plus SQL Generator”之类的工具你根据Java实体类就能自动生成创建表的SQL语句字段类型、长度、注释都能从注解里读取到。比如这个User实体类Data TableName(user) public class User { TableId(type IdType.AUTO) private Integer id; private String username; private String password; private String nickname; private String avatar; private String phone; /** 0-普通用户 1-管理员 */ private Integer role; private Date createTime; }通过这个实体类生成的SQL基本长这样CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, username varchar(50) DEFAULT NULL, password varchar(100) DEFAULT NULL, nickname varchar(50) DEFAULT NULL, avatar varchar(255) DEFAULT NULL, phone varchar(20) DEFAULT NULL, role int(11) DEFAULT 0, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4;注意字符集一定要用utf8mb4不要用utf8因为utf8在MySQL里存不了emoji表情评论内容但凡出现一个emoji整个插入操作就会报错。生成的SQL还不够表之间要设置外键还是不加外键我的建议是不加物理外键只建立逻辑关联。物理外键虽然在数据库层面保证了数据的完整性但会导致删除用户时受到关联限制、插入性能下降等问题而且MyBatis-Plus的关联查询根本不会用到外键约束。更重要的是答辩时老师如果问“为什么不用外键”你可以理直气壮地解释现代互联网应用为了追求性能和扩展性普遍采用应用层维护数据关联的方式逻辑外键更灵活。所有表建好之后插入一部分测试数据时要注意景点的图片地址别写死成本地的用几个真实的外链图片URL这样Android端跑起来界面好看演示效果会好很多。3.2 后端接口开发三层架构的一个完整实例我拿景点分页查询接口来讲完整流程。Controller层RestController RequestMapping(/scenic) public class ScenicController { Autowired private ScenicService scenicService; GetMapping(/page) public ResultVO getScenicPage(RequestParam(defaultValue 1) Integer current, RequestParam(defaultValue 10) Integer size, RequestParam(required false) String keyword, RequestParam(required false) Integer categoryId) { return ResultVO.success(scenicService.getScenicPage(current, size, keyword, categoryId)); } }Service层Service public class ScenicServiceImpl extends ServiceImplScenicMapper, Scenic implements ScenicService { Override public PageResult getScenicPage(Integer current, Integer size, String keyword, Integer categoryId) { QueryWrapperScenic wrapper new QueryWrapper(); wrapper.like(StringUtils.isNotBlank(keyword), name, keyword) .eq(categoryId ! null, category_id, categoryId) .orderByDesc(create_time); PageScenic page scenicMapper.selectPage(new Page(current, size), wrapper); // 把MyBatis-Plus的Page对象转换成自定义的PageResult返回 return new PageResult(page.getRecords(), page.getTotal(), page.getCurrent(), page.getSize()); } }整个过程遵循“Controller只管接收参数和返回结果、Service管业务逻辑、Mapper管数据查询”每层各司其职。评审老师看到这种清晰的代码结构印象分通常会拉满。核心API清单如下接口路径请求方式功能说明是否需要登录/user/registerPOST用户注册否/user/loginPOST用户登录否/scenic/pageGET景点分页列表否/scenic/{id}GET景点详情否/article/pageGET攻略列表否/article/{id}GET攻略详情含评论否/article/addPOST发布攻略是/comment/addPOST发表评论是/favorite/addPOST收藏景点是/favorite/listGET我的收藏列表是/admin/scenic/savePOST景点新增/编辑是管理员/admin/article/auditPOST攻略审核是管理员3.3 Android页面实现从登录到列表的一套完整流程Android端的核心页面主要就是六个登录页、注册页、首页列表、景点详情、攻略详情、个人中心。登录页的核心代码就是一个Retrofit请求public void login(String username, String password) { ApiService api RetrofitManager.getInstance().getApi(); LoginRequest request new LoginRequest(username, password); api.login(request).enqueue(new CallbackResultVOUser() { Override public void onResponse(CallResultVOUser call, ResponseResultVOUser response) { if (response.body() ! null response.body().getCode() 200) { User user response.body().getData(); // 保存用户信息到SharedPreferences PrefManager.saveUser(user); PrefManager.saveToken(user.getToken()); // 跳转到首页 startActivity(new Intent(LoginActivity.this, MainActivity.class)); finish(); } else { Toast.makeText(LoginActivity.this, 登录失败, Toast.LENGTH_SHORT).show(); } } Override public void onFailure(CallResultVOUser call, Throwable t) { Toast.makeText(LoginActivity.this, 网络连接失败, Toast.LENGTH_SHORT).show(); } }); }首页列表是一个典型的RecyclerView场景。布局是垂直滚动每个item展示景点缩略图、名称、评分、简要描述。点击item跳转到详情页详情页在onCreate里根据传入的id请求接口并渲染。列表分页我用的方案是“下拉刷新 上拉加载更多”下拉用Android官方SwipeRefreshLayout上拉通过判断RecyclerView滚动到末尾时自动加载下一页recyclerView.addOnScrollListener(new RecyclerView.OnScrollListener() { Override public void onScrolled(NonNull RecyclerView recyclerView, int dx, int dy) { super.onScrolled(recyclerView, dx, dy); LinearLayoutManager lm (LinearLayoutManager) recyclerView.getLayoutManager(); if (lm ! null lm.findLastVisibleItemPosition() lm.getItemCount() - 2) { // 加载更多 loadMore(); } } });注意这里有个小坑loadMore函数里要加一个isLoadingMore标志位防止滑动时多次触发重复请求。这个标志位在请求开始时置为true请求完成后置为false。3.4 后台管理的实现思路后台管理页面我用了Thymeleaf Bootstrap。Bootstrap是前端CSS框架但用法很傻瓜直接CDN引入就能用现成的表格、按钮样式不用自己写样式。后台管理的关键是权限控制。我在后端写了一个拦截器HandlerInterceptor在进入管理端所有接口之前检查请求头里的token对应的用户角色是否为管理员public class AdminInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(token); User user userService.getUserByToken(token); if (user null || user.getRole() ! 1) { response.setStatus(401); return false; } return true; } }这个拦截器的注册要写进WebMvcConfigurer实现类中。这里需要注意排除登录接口本身并且把静态资源目录css、js放行否则页面的样式全挂掉看起来像没做前端一样。4. 常见问题与排查技巧实录做毕设一定会踩坑关键是踩完坑知道怎么爬出来。下面这些是历届学生和我自己实际遇到的高频问题整理成表格方便对照排查。问题现象根本原因排查方法解决方式Spring Boot启动失败报错说端口被占用8080端口被其他程序占用命令行执行netstat -ano找到占用进程关闭占用程序或改application.yml端口数据库连接失败时区配置错误、MySQL未启动、账号密码不符检查MySQL服务状态控制台直接登录验证连接串加serverTimezoneAsia/ShanghaiEntity类报错“Invalid bound statement”Mapper接口和XML文件没有映射到检查mapper-locations配置在application.yml中配置mybatis-plus.mapper-locationsAndroid连不上后端接口模拟器地址写错检查基础URL配置模拟器访问宿主机必须用10.0.2.2不能用localhostApp闪退日志一堆空指针是最大的可能查看Logcat红色异常信息找到报错行检查对象是否初始化中文乱码字符集不一致检查数据库、连接串、前端页面编码统一使用utf8mb4URL加characterEncodingutf8图片上传后无法显示静态资源映射未配置后端访问图片地址是否404实现WebMvcConfigurer映射/upload/路径到本地目录分页查询返回总数为0数据量统计异常或wrapper条件错误打印SQL到控制台检查开启MyBatis-Plus日志看排除条件评论后列表不刷新未重新请求详情接口检查是否在onResume里刷新数据页面返回时重新加载数据安卓控件点击没反应控件设置了不可点击属性或被遮挡检查布局层级调整控件z轴顺序检查clickable属性这里我单独展开几个最有代表性的问题因为这些坑看起来很小却能卡住你好几个晚上。第一个是“模拟器访问localhost失败”。这个问题几乎每个月都有人来问。你的Spring Boot跑在自己电脑上Android模拟器是虚拟机模拟器里的localhost是模拟器自己不是你电脑。你必须写http://10.0.2.2:8080这是Android官方规定的模拟器访问宿主机的专用地址。如果是真机调试则要写你电脑在局域网里的IP手机和电脑连同一个WiFi。这个知识点必须记牢换了环境就报网络连接失败十有八九是这个问题。第二个是Spring Boot版本太高导致的依赖冲突。我的项目用Spring Boot 2.7.x配套的MyBatis-Plus版本应该选3.5.xJDK用8或11。如果你直接启动一个新项目选了Spring Boot 3.2.x那么JDK要17、MyBatis-Plus要升到3.5.5以上而且很多东西的API有变化网上大部分教程代码都跑不了。所以建项目时宁可选低一档的版本稳定压倒一切。新版特性带来的复杂度对毕设来说根本用不上。第三个是Gradle项目构建缓慢或失败。Android Studio现在默认用Gradle构建由于网络原因Gradle首次下载可能特别慢。解决办法是在项目根目录的build.gradle文件里配置阿里云的Maven镜像仓库buildscript { repositories { maven { url https://maven.aliyun.com/repository/public } maven { url https://maven.aliyun.com/repository/google } mavenCentral() google() } }同时在gradle-wrapper.properties中把Gradle版本和本地已下载的版本保持一致如果本机有现成的就不要重新下载。第四个是MyBatis-Plus查询结果字段全是null。这个极大概率是map-underscore-to-camel-case没配置或者实体类没有加TableName注解数据表表名和实体类名对不上。比如实体类叫ScenicInfo表名是scenicMyBatis-Plus默认会把ScenicInfo映射到scenic_info表于是查询报错。第五个是评论功能的时间显示不对。数据库里存的是带时区的datetime但Java的Date默认使用本地时区如果配置不一致就可能导致时间相差8小时。解决办法是在创建实体类时的createTime字段上加上TableField(fill FieldFill.INSERT)并用一个MetaObjectHandler处理器统一填充创建时间Component public class MyMetaObjectHandler implements MetaObjectHandler { Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, createTime, Date.class, new Date()); } }5. 文档、视频与答辩准备的实用建议源码、文档、运行视频、讲解视频这四样东西是很多同学买毕设项目时比较在意的交付物。其实这几样东西的本质是“帮你消化这个项目”不是“买了就完事”。文档尤其重要因为答辩打分很大比重看文档的规范程度。我的项目文档里包含的章节可以给你参考需求分析项目背景、功能需求概述、可行性分析系统设计总体架构图、功能模块图、数据库ER图、表结构说明系统实现每个模块的核心代码说明、关键逻辑截图系统测试测试用例表、测试结果、缺陷记录总结与展望遇到的困难、解决方案、后续改进方向写文档有个诀窍先写表结构说明和接口文档再补需求分析最后写测试报告。因为表结构是固定的接口是实测跑通的这两部分不会虚需求分析可以反过来从表结构反推测试报告用你自己操作过程中的截图绝对真实可信。运行视频录制时我建议在录制前先列一份“演示脚本”按照功能点顺序操作登录注册→首页浏览→景点详情→搜索→查看攻略→发表评论→个人中心→后台管理端操作。每一步操作3到5秒语速平缓。视频的作用是让导师快速了解系统的全貌不需要炫技但要流畅、无卡壳。如果操作到一半发现Bug了宁可重新录一条也不要剪接导师最忌讳看到“演示完功能就报错”的画面。讲解视频是给期末答辩用的“提前预习”。录制时不用面面俱到重点讲三个部分项目背景和功能概览、数据库表结构和关联关系、核心功能的技术实现。具体到代码层面可以挑登录鉴权、分页查询、上传图片这三个点详细讲因为这三个点能同时体现你的后端理解、数据库能力和工程细节把控。答辩现场还有一个容易被问倒的问题“如果数据量变大了你的系统怎么优化”这个问题不要慌哪怕是毕设系统你也可以从技术角度给出方案分页查询已经做了可以减小单次查询压力给表增加索引比如搜索字段建普通索引热点数据可以用Redis做缓存。你要表达的是“我理解这个方向并且知道业界成熟方案”而不是一定要在代码里实现Redis。设计时的可扩展性远比你现场临时堆功能更重要。6. 关于项目后续的扩展思路如果做完这个系统还有余力或者想让项目在简历上更有亮点有两条改动成本低但加分明显的路径。第一条是给“攻略模块”增加标签体系和推荐逻辑。每篇攻略打几个标签比如“穷游”、“亲子”、“美食”、“徒步”然后用简单的规则推荐同类攻略。不需要机器学习算法一个简单的关联查询就能做出“猜你喜欢”的效果。在简历上写“基于标签关联的内容推荐”就比单纯“攻略展示”更有说头。第二条是把管理端的图片上传从本地存储改成云存储。现在的云对象存储服务提供了对应SDK接入复杂度很低。在这个改动过程中你实际接触到的是生产级别的文件存储方案这个技能面试时会比较讨喜。我个人大量实操之后有一个明显体会毕业设计项目的价值不在于用了多高深的技术而在于你是否把每个选择背后的逻辑想清楚了。Spring Boot为什么用这个版本、MyBatis-Plus为什么能省掉大量手写SQL、Android端为什么用Retrofit不用原生HttpURLConnection这些“为什么”才是答辩时你真正能说出来的东西也是以后面试官真正会追问的东西。照着这篇文章的路线做下来你收获的不止是一个能交差的系统还有一套完整的全栈开发思路。