毕业设计-基于Android的旅游系统
每年到了毕业季，总有一大批计算机专业的同学被分到旅游类App开发这个题目。说实话，这个选题能火不是没道理的——它功能边界清晰、技术栈成熟、扩展空间大，作为本科毕设来说既不会难到做不完，又足够在答辩时讲出东西来。我前后帮几位同学参谋过这类系统，自己也上手调过不少代码，今天就把整个"基于Android的旅游系统"从零到答辩的完整路径拆给你。
先给个定位：这是一个典型的客户端-服务端架构项目，前端用Android原生开发，后端可以选Java/Spring Boot、Node.js或者Python Flask，数据存储用MySQL，通信走HTTP+JSON。你的核心工作不是发明新东西，而是把用户注册登录、景点信息展示、旅游线路推荐、订单预订、个人中心这几大模块做扎实，再配上管理后台让管理员能维护数据。这套东西做完，你的毕设就已经超过绝大多数同学的水平了。
适合谁来参考？基础偏低、只学过Java和Android入门、对服务端开发不熟的同学，这套路可以直接照抄；基础不错、想加点亮点的同学，我会在最后讲几个不太难但很让答辩老师眼前一亮的扩展方向。
1. 整体设计与思路拆解
1.1 为什么“前后端分离”是毕设最稳的姿势
很多人一想到Android项目，第一反应是"全部写在App里"。如果你真这么干，会踩两个坑：第一，MySQL不能直连手机端，你绕不开一个中间服务层；第二，全部堆在客户端，代码一多你自己都维护不过来，答辩被问"服务端在哪"的时候会很尴尬。
所以我的建议是：必须做前后端分离。Android端只负责界面展示和用户交互，数据全部通过接口从服务端获取。这样做的直接好处有三个：
- 客户端崩溃率高往往是因为业务逻辑和数据耦合太深，分离后App只干一件事——渲染和请求。
- 答辩时你可以坦诚地说"系统采用当前主流的B/S与C/S混合架构"，这句话在老师那儿的加分效果比你想象的大。
- 你自己开发的时候可以并行推进，后端用Postman测通了，Android端对接就轻松很多。
1.2 选型背后的真实考量
先聊后端。如果你是JAVA方向的，Spring Boot是默认答案。它内嵌Tomcat、自带依赖管理、写REST接口快，最关键的是Spring全家桶在简历上写出来不丢人。你要是Python熟，Flask或者Django也可以，代码量更少、开发更快，但需要额外处理跨域和部署问题。我见过一个同学用Django REST framework做后端，三天就把所有接口写完了，不能说不好，但答辩时容易被追问"为什么不用Java"——你得提前准备个说得过去的理由。
前端就只有两个路线：原生Android（Java/Kotlin）或跨平台（Flutter/React Native）。毕设我强烈建议原生，理由很现实：Android Studio + Java是对你大学所学知识最直接的验证，而且网上能找到的旅游类毕设参考代码绝大多数都是Java写的，你能抄作业、能改、能跑通，这比什么都重要。Kotlin语法更现代，但你得自己折腾协程、扩展函数，对本来就赶时间的毕业季来说不太友好。
数据库选MySQL没悬念，免费、资料多、SQL语句你本来就会。ORM层面我建议后端用MyBatis-Plus或者Spring Data JPA，前者SQL控制更细，后者写起来省事，看你平时的习惯。
1.3 功能模块怎么划分才不乱
我的习惯是先画功能脑图，再定数据库表，最后才动代码。旅游系统至少要拆成这么几块：
- 用户模块：注册、登录、退出、个人信息修改、头像上传、密码找回。
- 景点模块：景点列表、景点详情、景点搜索（按城市、按分类）、景点评分与评论。
- 线路模块：推荐旅游线路、线路详情、线路中包含的景点列表。
- 订单模块：选择线路、填写出行日期和人数、生成订单、模拟支付、订单查询与取消。
- 收藏模块：收藏景点/线路、展示收藏列表。
- 管理后台：管理员登录、景点管理、线路管理、订单管理、用户管理、数据统计（可选）。
每个模块你都要能讲清楚"谁在用、用来干嘛、数据从哪里来"这三点。我见过太多同学把时间耗在美化界面上，结果核心的订单流程走不通，最后熬夜补逻辑，非常不划算。
2. 数据库设计与接口设计的完整细节
2.1 核心表结构设计思路
数据库是答辩时老师最爱深挖的地方。"你为什么要这么设计"这个问题你必须答得上来。旅游系统的表我推荐这样设计：
用户表 user
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(255) NOT NULL COMMENT '密码，保存MD5或BCrypt哈希', `nickname` varchar(50) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;密码存储我单独说一句：绝对不要存明文。至少用MD5加盐，稳妥点用BCrypt。答辩时老师看到你的实体类里写了private String password;，往往会追问一句"密码怎么存的？"，你说存的是哈希值，这一分就到手了。
景点表 scenic_spot
CREATE TABLE `scenic_spot` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL, `city` varchar(50) DEFAULT NULL, `category` varchar(50) DEFAULT NULL COMMENT '自然风光/人文古迹/主题乐园等', `description` text, `price` decimal(10,2) DEFAULT '0.00' COMMENT '门票价格', `open_time` varchar(50) DEFAULT NULL, `cover_image` varchar(255) DEFAULT NULL, `images` text COMMENT '多图，可存JSON或逗号分隔', `rating` decimal(2,1) DEFAULT '5.0', `status` tinyint(1) DEFAULT '1', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;景点表的核心是images字段。这里有个经验之谈：很多人会建一张景点图片子表来存多图，逻辑上更规范，但对毕设来说没必要，直接在字段里存JSON数组或者逗号分隔的URL列表，后端解析下就行。理由很简单——你的图片数量少、不会变、没有独立的业务逻辑，拆表反而徒增联表查询的复杂度。
线路表 travel_line 加 line_scenic 关联表
线路与景点是多对多关系：一条线路包含多个景点，一个景点也能出现在多条线路里。所以你需要在线路表和景点表之间建一张关联表：
CREATE TABLE `line_scenic` ( `id` int(11) NOT NULL AUTO_INCREMENT, `line_id` int(11) NOT NULL, `scenic_id` int(11) NOT NULL, `day_index` int(11) DEFAULT '1' COMMENT '景点在第几天', `sort_order` int(11) DEFAULT '0' COMMENT '当日游玩顺序', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;加day_index和sort_order这两个字段是我后来补上的。最初我只存了line_id和scenic_id的对应关系，但做详情页的时候发现没法展示"第一天去A景点、第二天去B、C景点"这种行程规划。补上这两个字段后，前端可以根据day_index分组展示行程安排，效果非常直观。
订单表 orders
CREATE TABLE `orders` ( `id` int(11) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `user_id` int(11) NOT NULL, `line_id` int(11) NOT NULL, `travel_date` date NOT NULL, `adult_count` int(11) DEFAULT '1', `child_count` int(11) DEFAULT '0', `total_price` decimal(10,2) NOT NULL, `status` tinyint(1) DEFAULT '0' COMMENT '0待支付 1已支付 2已取消 3已完成', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;订单状态用int表示，比字符串存"待支付"好得多——查询快、省空间、前端可以映射成中文标签。订单号我生成的规则是"yyyyMMddHHmmss + 4位随机数"，简单够用，不需要引入雪花算法。
2.2 RESTful接口怎么定才规范
接口设计你不需要搞得像大厂那么复杂，但要做到路径清晰、语义明白、返回格式统一。我常用的统一返回结构是：
{ "code": 200, "message": "success", "data": { } }code是业务状态码，200表示成功，其他值对应各类异常；message给前端提示用；data是具体数据。这样Android端解析JSON只需要判断code，然后取出data，代码非常简洁。
核心接口一览：
| 功能 | 请求方式 | 路径 | 参数 | 返回值说明 |
|---|---|---|---|---|
| 用户注册 | POST | /api/user/register | username, password, nickname | 注册结果 |
| 用户登录 | POST | /api/user/login | username, password | 用户信息+token |
| 景点列表 | GET | /api/scenic/list | page, size, city, category | 分页景点列表 |
| 景点详情 | GET | /api/scenic/{id} | — | 景点详情信息 |
| 线路列表 | GET | /api/line/list | page, size | 线路列表 |
| 线路详情 | GET | /api/line/{id} | — | 线路详情+关联景点 |
| 创建订单 | POST | /api/order/create | userId, lineId, travelDate等 | 订单信息 |
| 我的订单 | GET | /api/order/list | userId | 订单列表 |
| 收藏/取消 | POST | /api/favorite/toggle | userId, scenicId | 操作结果 |
登录之后要不要做Token鉴权？我的建议是：做。哪怕只用最简单的UUID token存内存Map，也比什么都不做强。Android端登录成功后拿着token，访问需要鉴权的接口时在请求头里加Authorization: token，服务端做个拦截器校验。这一小段代码在毕业答辩的"系统安全性"部分能撑住至少两三个追问。
但如果你时间实在来不及，把用户Id直接当参数传也能跑通。不少毕设项目就是这么干的，老师也都心知肚明。你只要在答辩时别说漏嘴"这个系统没有任何安全措施"就行。
2.3 数据库初始化数据怎么准备
这看着是个小事，但真能卡住很多人。景点和线路的数据不能太少，至少要有20个景点、6条线路，覆盖5个以上城市，不然分页查询一眼看到头、筛选功能没法演示。
数据从哪来？我的经验是三步走：
- 去旅游网站找真实的景点介绍、门票价格、开放时间，手动整理成INSERT语句。
- 用hsqldb或Navicat的导入功能把整理好的Excel/CVS直接导进MySQL，别一条条手敲。
- 图片地址用本地相对路径，比如
upload/scenic/beijing_gugong.jpg，App端通过IP:端口拼接完整URL访问。
这里有个易错点：Android模拟器访问主机要用10.0.2.2而不是localhost或127.0.0.1。这个坑我见过不下五个同学踩过，接口在浏览器里测着没问题，一上模拟器就超时，就是IP写错了。
3. 实操过程与核心环节实现
3.1 后端接口从零到跑通的完整流程
拿Spring Boot + MyBatis-Plus这套组合演示，因为它最成熟、问题答案最多。
新建Spring Initializr项目，pom.xml引入这几个关键依赖：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency>然后配置application.yml：
server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/travel_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你自己的密码 driver-class-name: com.mysql.cj.jdbc.Driver注意：
serverTimezone=Asia/Shanghai这个参数必须有，不写的话MySQL 8.x会报时区错误，折腾半天才发现就差这一个小尾巴。
实体类用@Data注解省去getter/setter，Mapper接口继承BaseMapper<T>，Service层继承IService<T>，Controller层按接口文档写方法就行。MyBatis-Plus的Page分页插件需要配置一个拦截器：
@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }不配这个，selectPage查出来的total永远是0，这是我踩过的坑。
写完后用Postman把所有接口依次验证一遍。登录注册的接口重点测：用户名重复注册能不能正确拦截？密码错误能不能返回正确提示？参数缺失有没有报500？这些边界情况在答辩演示的时候最容易翻车。
3.2 Android客户端核心实现详解
Android端的项目结构我建议按模块分包：
com.example.travel ├── adapter // RecyclerView适配器 ├── entity // 实体类（与后端JSON字段对应） ├── network // 网络请求封装 ├── ui // 各个Activity/Fragment │ ├── login │ ├── register │ ├── home │ ├── scenic │ ├── line │ ├── order │ └── mine └── utils // 工具类网络请求我推荐用OkHttp + Retrofit + Gson的组合。Retrofit把接口定义成注解，代码很清爽：
public interface ApiService { @POST("api/user/login") Call<BaseResponse<User>> login(@Body LoginRequest request); @GET("api/scenic/list") Call<BaseResponse<PageResult<Scenic>>> getScenicList( @Query("page") int page, @Query("size") int size ); }加一个统一的网络层封装：
public class NetworkManager { private static ApiService apiService; public static ApiService getApiService() { if (apiService == null) { Retrofit retrofit = new Retrofit.Builder() .baseUrl("http://10.0.2.2:8080/") .addConverterFactory(GsonConverterFactory.create()) .build(); apiService = retrofit.create(ApiService.class); } return apiService; } }Android端的界面用RecyclerView + CardView做列表页就够了，场景化很强。景点详情页用ViewPager2做图片轮播，再用嵌套ScrollView装下所有信息。首页用Fragment + BottomNavigationView做底部导航，这个组合是主流App的标准结构，实现起来也不难。
这里说一个非常重要的经验点：Android里所有网络请求必须放在子线程，不能在主线程直接调。最简单的方式是用Thread + Handler，官方推荐用协程或者Call.enqueue()回调。Retrofit的enqueue本身就是异步的，回调会切回主线程，你直接在onResponse里更新UI就行。
还有一个所有人都容易忽略的点：Android 9及以上默认禁止明文HTTP请求。你本地调试用http://地址，必须在res/xml/network_security_config.xml里配置：
<network-security-config> <base-config cleartextTrafficPermitted="true" /> </network-security-config>然后在Manifest里引用这个配置。不写这个，你的接口请求会直接被拦掉，报错信息还特别难懂——Cleartext HTTP traffic not permitted。这个坑，调试的时候遇到就明白了。
3.3 图片加载与界面渲染的细节
很多人会在图片加载上卡住。不建议自己写BitmapFactory去解析网络图片，直接用Glide，四行代码搞定：
Glide.with(context) .load(imageUrl) .placeholder(R.drawable.placeholder) .error(R.drawable.error) .into(imageView);Glide内部帮你处理了图片压缩、缓存、生命周期绑定，你只需要把后端图片URL拼对就行。图片URL的拼接逻辑我建议统一放到一个工具类里：
public static String getFullImageUrl(String relativePath) { return BASE_URL + relativePath; }这样改后端地址时只改一处。页面显示的预览缩略图，Glide的override(400, 300)可以指定加载尺寸，不但节省流量、加载更快，列表滑起来也更顺滑。
3.4 管理后台怎么快速搭出来
很多毕设要求有后台管理功能，但你又不想花大时间写一个Web管理端。我的替代方案是：
- 方案A：用Spring Boot搞几个REST接口，数据管理用Postman直接调。适合时间非常紧张的同学。
- 方案B：在Android端里做一个管理员入口，登录账号判断
role字段后显示管理菜单，直接用App管理数据。这个方案界面复用度高，而且"一套代码双角色"在答辩时很加分。 - 方案C：用Vue + ElementUI搭一个独立的Web管理后台，走完整的登录流程。适合前端基础还行、时间充裕的同学。
我自己推荐方案B。旅游App客户端已经写了列表和详情页面，管理员界面其实就是套同样的布局，加个新增/编辑对话框。用户表加一个role字段（0普通用户，1管理员），再做一个隐藏的管理入口——比如在登录页连点5次版本号弹出管理员登录。这种设计在答辩演示时很有效果：先展示用户端，手指点几下切到管理端，老师会觉得很有意思。
4. 常见问题与排查技巧实录
4.1 接口联调阶段的高频问题
问题1：模拟器访问不到后端服务
- 症状：请求一直转圈，最后报
TimeoutException或Failed to connect to /192.168.x.x。 - 排查：在模拟器浏览器里访问
http://10.0.2.2:8080/xxx，能打开就是代码问题，打不开就是后端没启动或防火墙挡了。 - 解决：Android Studio自带模拟器用
10.0.2.2；真机调试时保证手机和电脑在同一局域网，用电脑的局域网IP:8080，并且关掉电脑防火墙对8080端口的拦截。
问题2：后端能访问，但解析JSON时报错
- 症状：
Gson抛JsonSyntaxException，或者data字段是null。 - 排查：第一步在Postman里看真实返回的JSON结构，第二步用在线JSON解析工具对比你的实体类字段。特别注意后端返回的字段名是
coverImage还是cover_image——MyBatis-Plus默认驼峰映射，如果你没配置mapUnderscoreToCamelCase=true，cover_image不会自动变成coverImage。 - 解决：application.yml加一行
mybatis-plus.configuration.map-underscore-to-camel-case: true，或者后端返回的实体类用@JsonProperty("cover_image")注解。
问题3：手机安装的App连不上电脑后端
- 症状：真机上报
SocketTimeoutException。 - 解决：不要用
localhost，用局域网IP；确保电脑防火墙允许Java进程入站；如果用AS自带的Wi-Fi调试（Android 11及以上），额外检查adb配对是否成功。
4.2 界面与线程相关的经典坑
问题4：滑动列表卡顿掉帧
- 原因多半是你在
onBindViewHolder里直接做了网络请求或者加载了原图。 - 解决：数据先分页加载（每页10-20条），图片用Glide压缩加载，不要在getView里频繁创建新对象。如果还卡，检查RecyclerView有没有设置
setHasFixedSize(true)。
问题5：网络请求回调里的UI更新报异常
- 症状：
android.view.ViewRootImpl$CalledFromWrongThreadException。 - 原因：在子线程中直接修改了UI组件。
- 解决：Retrofit的
enqueue回调本身在主线程，但如果你自己用Thread+ OkHttp的execute()，就必须用runOnUiThread包一层或者Handler.post()。
问题6：Glide图片加载黑屏/显示不了占位图
- 先看URL能不能在浏览器打开，再看是不是相对路径没拼完整。
- 图片URL里含
&等特殊字符时，记得URLEncoder编码，不然服务端可能返回404。
4.3 答辩前必须自测的十个场景
我把毕业季帮人调试时总结的自测清单列出来，你答辩前完整跑一遍，基本不会翻车：
- 全新用户注册，然后登录，个人信息是否正常显示。
- 注册时用户名重复，是否提示"用户名已存在"而不是崩溃或空白。
- 景点列表分页加载，向下滑动翻页是否流畅、数据不重复。
- 按城市和分类筛选，结果是否正确。
- 搜索关键词无结果时，界面是否有"暂无数据"的友好提示。
- 线路详情展示的行程（第几天、玩哪些景点）是否与后台数据一致。
- 选线路、填日期人数、提交订单，订单列表里能否查到，并且总价计算正确。
- 取消订单后状态是否正确变化。
- 收藏一个景点，再到收藏列表查看，退出App重进后收藏状态是否保留。
- 断网状态下打开App，是否有Toast提示而不是卡死或闪退。
第7条和第9条是业务的核心闭环，第10条是"做没做异常处理"的直观体现。这三个做好，答辩演示环节就稳了大半。
5. 扩展亮点与答辩加分思路
5.1 不增加太多工作量却能明显加分的三个方向
如果你核心功能都做完了，还剩一周到十天的时间，我建议优先做这几个扩展：
- 地图展示：集成地图SDK，在景点详情页展示位置标记；线路页把行程景点按顺序连成一条线。这个功能视觉冲击力强，答辩时"用百度地图/高德地图SDK"一说出来，老师基本都会点头。实现上只需要定位坐标存到数据库，地图上批量添加Marker和Polyline即可。
- 搜索功能的强化：不只是按景点名精确匹配，改成模糊搜索+按城市搜索+按分类筛选的三维组合查询。后端构造SQL时用
LIKE CONCAT('%', #{keyword}, '%')，条件用MyBatis-Plus的LambdaQueryWrapper动态拼接。这个改动代码量很少，但从"能搜"变成"好搜"，体验差别很明显。 - 数据分析：后台统计订单数量、热门景点Top10、用户增长趋势，用柱状图和折线图展示。Android端可以引入MPAndroidChart，后端写几个聚合统计SQL。这块做好了能直接撑起"系统意义和应用价值"的答辩问题——你的系统不只是展示数据，还能辅助运营决策。
5.2 答辩证中常见问题怎么应对
提前准备以下问题的回答思路：
- "为什么选这个课题？"别只说"因为旅游是朝阳产业"，太假大空。可以结合个人经历：你喜欢旅行，但发现现有App普遍存在信息分散、行程规划不方便的问题，所以想做一个集景点浏览、线路定制、一键预订于一体的工具，解决"想去玩但不知道去哪、怎么安排"的痛点。
- "系统最大的难点是什么？"推荐答订单状态管理和行程关联关系的建模。前者是因为涉及多状态流转、并发下的订单号生成；后者是因为线路与景点多对多关系需要合理设计关联表来支持按天展示行程。这两个都能看出你对数据建模有思考。
- "安全方面做了什么？"密码哈希存储、登录token校验、参数校验（防止空值和非法数字）、SQL注入防护（MyBatis-Plus的预编译机制）。这四句话一说，整场答辩的安全问题直接过关。
- "后续怎么改进？"推荐回答"接入真实支付"、"增加基于用户浏览行为的智能推荐"、"加入行程评论和用户互助社区"、"适配平板和手表端"。这些都不需要真实现，但你展示了对项目生命周期的理解。
5.3 论文与文档撰写的关键提醒
毕设不只代码，文档占的比重不小。写论文时我建议按这个结构走：
- 第一章绪论：研究背景、国内外现状、课题意义。强调数据来源要引用真实的旅游行业报告，显得严谨。
- 第二章需求分析：画出用例图，描述各个角色和功能需求。这里配合你在1.3里划分出的功能模块来讲，不要漏掉非功能性需求（性能、安全性、可用性）。
- 第三章系统设计：总体架构图、功能结构图、数据库ER图、核心表结构。论文里的图表可以手绘草稿后重画，但内容必须和实际代码保持一致，这是很多答辩翻车的重灾区——论文说状态有4种，代码里实际却写了2种，老师一翻代码就露馅。
- 第四章系统实现：典型功能界面的截图 + 核心代码片段 + 实现思路说明。关键在于"图配文"：每张截图必须紧跟一段说明，讲了什么功能、怎么实现的、遇到什么问题怎么解决的。
- 第五章系统测试：功能测试用例表格 + 测试结果。把你在4.3里的自测清单整理成正式的测试用例，再做一轮简单的性能测试（接口响应时间）。
- 第六章总结与展望：总结做了什么，不足是什么，未来怎么改进。
6. 关于资源获取与环境准备的建议
6.1 开发环境版本怎么选
版本问题是新生最容易踩的坑。我给一个经过验证的参考配置：
- JDK：1.8和11都行，推荐JDK 8，兼容性最好。
- Android Studio：建议用最新的稳定版，但注意SDK版本别太激进，
compileSdk用34，minSdk用24，覆盖约97%的安卓设备。 - 后端：Spring Boot 2.7.x 配 JDK 8，不要一上来就用Spring Boot 3，不然JDK版本和依赖兼容性问题能磨掉你一天时间。
- MySQL：5.7或8.0均可，5.7资源占用小、资料多，适合老电脑。
- 数据库管理工具：Navicat或DBeaver。DBeaver免费开源，支持连接类型多，推荐。
6.2 遇到问题去哪找答案
说句实在话，你遇到的所有问题，大概率都能在某技术社区、某技术问答网站上找到直接答案。搜索技巧是关键：直接复制报错信息的英文原文，比如Cleartext HTTP traffic not permitted，比搜"Android无法连接服务器"有效得多；报错信息后面加版本号，比如Spring Boot 2.7 security config，能过滤掉大量过时答案。
我再强调一次：把报错信息原封不动地放到搜索引擎里查，是解决技术问题最高效的方法，没有之一。
6.3 时间规划的参考节奏
按常规毕设周期12周来排，建议这么分配：
| 时间段 | 任务 |
|---|---|
| 第1-2周 | 确定课题、搭建开发环境、学习必要的框架基础 |
| 第3-4周 | 完成需求分析和数据库设计、搭好后端框架 |
| 第5-6周 | 完成后端全部核心接口并用Postman测试 |
| 第7-9周 | 完成Android端全部核心页面和业务功能 |
| 第10周 | 接口联调、界面美化、处理bug |
| 第11周 | 系统测试、修复问题、撰写论文初稿 |
| 第12周 | 完善论文、准备答辩PPT、演示环境检查 |
前两周留一点缓冲，中间六周是代码产出高峰期，最后两周全部留给文档和答辩准备。这个节奏比较稳，就算中间偶尔卡壳一两天，整体也不至于失控。
7. 最后想说的几句经验之谈
旅游系统这个题目，说难不难，说简单也并不是一个照抄就完事的活。我见过有同学把所有的精力都放在界面花不花哨上，结果导出的APK装进手机里，注册登录都调不通；也见过基础一般的同学，老老实实按"注册登录-景点列表-线路详情-下单"的顺序一步步来，最后答辩拿了不错的成绩。区别不在于天赋，而在于有没有按照一个清晰的路线去执行，有没有在最容易出问题的环节提前踩坑填坑。
如果你做完这个项目之后还有精力和时间，我的建议是不要把代码一交了之。这个系统的价值在于它是一整套完整的业务闭环——从数据建模、接口设计，到客户端交互、状态流转，再到管理端的数据维护。把它整理进简历项目经历里，面试时能讲的东西非常多。一个能讲清楚"用户从注册到下单再到查看订单，中间经过了哪些表、哪些接口、哪些状态变化"的候选人，在很多面试官看来已经是超过平均水平的了。
最后再分享一个小技巧：答辩前把你写的SQL语句全部跑一遍，看看有没有慢查询或者死锁风险。带着这个意识和数据去答辩，你自然就会说出类似"我通过explain优化了这条查询语句"这种话——不仅听起来专业，更重要的是你确实做了这件事，底气是完全不一样的。
