企业官网建设流程全解析

这个标题看起来就是标准的毕设题目清单产物——说实话，我今年就带过好几个学生做类似方向的题目。先说个普遍现象：每年计算机专业的毕业设计题目里，旅游类APP基本能占两成左右，原因很简单，这类项目功能边界清晰、用户端和管理端都是现成的业务模型、有足够多的中文参考资料可以借鉴，关键是你不用去求别人给你数据，景区信息、攻略内容、出行线路这些素材网上遍地都是。但做归做，把它做成一个能过答辩、能拿出来讲清楚架构设计和业务逻辑的项目，却并不像题目那样简单。

这篇文章就围绕“基于Android + SpringBoot的智能旅游自助服务移动平台”这个项目，把从选题思路、技术选型、数据库设计、接口实现到Android端适配的完整过程，以及我在实际指导过程中学生踩过的那些坑，一次性梳理清楚。不管你是选了类似题目正在发愁怎么做，还是准备奔着这个方向做开题，这篇文章都能给你一条可以直接照着走的路径。

1. 项目定位与核心需求拆解

1.1 毕设选题的考量

为什么旅游类APP在毕业设计里这么常见？我个人的判断是三个原因：一是业务场景足够通用，评审老师一听就明白你要做什么，不需要花大量时间解释项目背景；二是技术栈组合灵活，既可以做成纯客户端项目，也可以做成前后端分离的完整系统，能满足不同难度层级的要求；三是数据获取成本低，景点介绍、门票价格、开放时间、交通方式这些信息属于公开数据，拿来整理成自己的数据库完全没问题。

但这个题目也有它的坑。最大的坑在于“泛”——旅游自助APP看起来什么都能往里装，景点展示、门票预订、酒店民宿、机票火车票、攻略社区、地图导航、语音导览，如果你什么功能都想要，那这个项目根本做不完。我见过太多学生开题时写得天花乱坠，到中期检查发现光是用户模块和景点模块就够喝一壶的了。

所以拿到这个题目之后，第一件事不是急着写代码，而是做需求减法。我通常建议学生把功能圈定在三到四个核心模块上，比如：用户注册登录、景点信息浏览与搜索、出行攻略查看与收藏、个性化线路推荐。至于支付、预订这类涉及第三方对接的功能，能不做就不做——不是说技术上实现不了，而是毕设答辩的时间有限，你花了大量篇幅讲支付流程，老师反而会觉得你核心业务没做扎实。

1.2 功能性需求分解

从题目描述“智能旅游自助服务”“旅游景点与出行攻略”这两个关键词来看，整个系统的核心价值是帮助用户解决“去哪玩”和“怎么玩”这两个问题。基于这个理解，我把系统功能拆成五个模块：

第一是用户模块。注册、登录、个人信息维护、密码修改，这是几乎所有系统的基础模块，没什么好商量的。如果想让项目显得更完整，可以加一个用户收藏和浏览记录的功能，后面做个性化推荐的时候用得上。

第二是景点模块。景点信息的增删改查是核心中的核心，前台展示和后台管理都需要。每个景点至少要有名称、简介、图片、所在城市、门票价格、开放时间、评分、热度这些字段。这里我建议把景点图片做成本地静态资源路径或图片URL存储，不要在数据库里放base64，不然数据库会变得很臃肿。

第三是攻略模块。出行攻略与普通景点介绍的区别在于，攻略更强调“行程建议”和“体验分享”，比如“某城市三天两夜游玩路线”“某个景区的最佳拍照机位”。我建议设计成用户可发布的UGC内容，管理员审核后展示，这样系统做出来之后数据可以持续丰富，也比较容易填充演示数据。

第四是推荐模块。这就是题目里“智能”的落点。推荐算法不需要搞得多高深，千万不要一上来就用协同过滤或者深度学习，毕设的体量根本撑不住。最简单有效的做法是基于标签和热度的规则推荐：用户浏览或收藏了某个景点后，系统根据景点的类型标签（自然风光、历史文化、主题乐园等）和城市匹配度，推荐同类型或同城市的热门景点。

第五是后台管理模块。用SpringBoot自带的AdminLTE或者若依这类现成脚手架都行，主要功能是管理景点数据、审核攻略、查看用户数据统计。有后台管理模块的存在，整个系统在答辩时能展示的页面和功能就完整多了。

2. 技术选型与架构设计

2.1 为什么选SpringBoot而不是SSM

现在很多学校还在教SSM（Spring + SpringMVC + MyBatis），但到了实际做毕设的时候，我几乎不带学生用纯SSM了，原因很简单：SSM的配置太繁琐，XML配置文件动辄几十行，学生把时间耗在配置上，真正的业务逻辑反而没时间写。SpringBoot的核心价值在于“约定优于配置”，一个启动类加几个注解就能跑起来一个Web项目，对于毕设这种时间紧、任务重的场景非常合适。

SpringBoot 2.x（对应JDK 8或JDK 11）是目前最稳妥的选择。为什么不推荐SpringBoot 3.x？因为SpringBoot 3要求JDK 17，而且很多第三方库的兼容性还没跟上，毕设用的主机和服务器环境往往没那么干净，为了一个版本特性去折腾环境不值得。

ORM框架我推荐用MyBatis-Plus，不是MyBatis。两者的区别在于，MyBatis-Plus提供了内置的通用Mapper和条件构造器，单表操作完全不用写SQL，这对学生来说省了很多事。你要做的只是定义好实体类和Mapper接口，增删改查直接在Service层调用几个方法就搞定了。多表关联查询再单独写XML里的SQL语句，工作量能减少一半以上。

2.2 Android端技术栈取舍

前端这块，题目写了“基于Android”，但具体用什么方式开发，里面还有讲究。原生Java仍然是毕设场景下的最优解。虽然现在Kotlin已经成了Android开发的主流语言，但绝大多数本科课程里教的还是Java，用Java做意味着你可以直接把课堂上学到的东西迁移过来，有问题也能在中文社区里找到大量解决方案。

我见到有些学生会提议用Flutter或者uniapp来做跨平台，理由是“一套代码多端复用”。这种方案在商业项目里确实好，但放在毕设答辩上反而容易翻车：老师如果问“你这个应用在Android上运行的底层原理是什么”“WebView和原生渲染有什么区别”，跨平台的抽象层会让你很难自圆其说。当然我不是说不能用跨平台，而是说如果是自己熟悉的领域那还好，否则别为了炫技增加答辩风险。

网络请求用OkHttp + Retrofit组合，目前这是最主流的方案，Retrofit帮你把接口调用封装成了Java接口，代码非常简洁。图片加载用Glide，这个库的优势在于内存管理好，列表滑动时不容易OOM。JSON解析用Gson或Fastjson都行，我一般推荐Gson，稳定且无漏洞问题。

2.3 整体架构与数据流转

整个项目的架构是典型的前后端分离，Android端通过HTTP接口与后端交互。之所以强调前后端分离，而不是像很多老毕设那样把前端页面塞进SpringBoot的templates目录里用Thymeleaf渲染，是因为你手机上运行的APP本质上只是一个“客户端”，它跟后端之间通过JSON数据通信——这种模式既符合真实互联网产品的架构方式，也便于在答辩时把系统的各个层次讲清楚。

系统的数据流转大概是这样的：用户打开APP，登录后进入首页，Android端发起HTTP请求到SpringBoot的Controller，Controller接收参数后调用Service层，Service层通过MyBatis-Plus操作MySQL数据库，数据结果以JSON格式返回给Android端，Android端用Gson解析后渲染到列表或详情页。

一个容易被忽视的点是接口的返回格式。我强烈建议把所有接口都统一成同样的返回结构：code（状态码）、message（提示信息）、data（具体数据）。这样Android端在做网络层封装的时候就可以写一个通用的回调处理，不用每个接口单独处理状态判断。这个看似很小的设计，实际开发时能节省大量时间。

3. 数据库设计与关键表结构

3.1 核心实体关系梳理

先理清楚系统里有多少个实体，以及它们之间是什么关系。基于前面确定的功能模块，整个系统至少需要六张表：用户表（user）、景点表（scenic_spot）、攻略表（travel_guide）、攻略评论表（guide_comment）、用户收藏表（user_favorite）、管理员表（admin）。

实体之间的关系并不复杂：一个用户可以收藏多个景点和攻略，一个景点可以被多个用户收藏，所以用户与景点之间是多对多关系，通过收藏表来关联。一个攻略属于一个用户（作者），一个攻略下面有多条评论，一条评论属于一个用户。如果把推荐功能做得更细一点，还可以加一个景点类型表（如自然风光、历史文化、美食探店等），用外键关联到景点表上。

3.2 关键表结构设计

用户表是最基础的，字段包括用户ID、用户名、密码（这里必须存加密后的密文，推荐用MD5加盐或者BCrypt）、昵称、头像、手机号、创建时间。密码加密这点在答辩时几乎是必考点，如果你项目里是明文存储，老师一问就会露馅。

景点表是整个系统数据量最大的表，核心字段如下：景点ID、名称、所在城市、景点类型、简介、详细描述、封面图片、门票价格、开放时间、建议游玩时长、热度值、评分、创建时间、状态（用于上下架管理）。热度值这个字段是实现推荐功能的关键，它的计算方式可以在程序里写一个定时任务，每隔一段时间根据用户访问量、收藏数、评论数来重新计算，然后按热度倒序取Top N就能实现“热门景点推荐”。

CREATE TABLE scenic_spot ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '景点ID', name VARCHAR(100) NOT NULL COMMENT '景点名称', city VARCHAR(50) NOT NULL COMMENT '所在城市', type VARCHAR(30) COMMENT '景点类型：自然风光/历史文化/主题乐园等', intro VARCHAR(500) COMMENT '一句话简介', description TEXT COMMENT '详细描述', cover_image VARCHAR(255) COMMENT '封面图片URL', ticket_price DECIMAL(10,2) DEFAULT 0 COMMENT '门票价格', opening_hours VARCHAR(100) COMMENT '开放时间', suggest_duration VARCHAR(30) COMMENT '建议游玩时长', hot_value INT DEFAULT 0 COMMENT '热度值', score DECIMAL(2,1) DEFAULT 5.0 COMMENT '用户评分', status TINYINT DEFAULT 1 COMMENT '状态：1上架 0下架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT '景点信息表';

攻略表的设计要注意一个点：攻略正文是大段的富文本内容，必须用TEXT类型而不是VARCHAR（VARCHAR最多只能存储64KB，而且会影响查询效率），另外要单独把标题、封面图、摘要这样的摘要字段拿出来，方便列表页展示。评论表则是典型的父子结构，每条评论关联一个攻略ID和一个用户ID，同时可以设计一个parent_id字段来实现楼中楼，但这个功能在毕设里属于加分项，不做也不影响主线。

收藏表的字段设计比较讲究，很多人会设计成两个收藏表（一个收藏景点、一个收藏攻略），其实完全没必要。用一张表加一个type字段区分收藏类型就够了：type为1表示收藏的是景点，type为2表示收藏的是攻略，target_id字段存对应对象的ID。这样查询的时候一条SQL就能搞定，扩展性也好。

3.3 数据表设计的几个注意点

第一，所有表都要有主键，推荐用自增的BIGINT类型，不要用UUID当主键。原因有两条：一是UUID比BIGINT占用空间大得多，索引效率低；二是UUID是无序的，在InnoDB引擎中插入时会导致页分裂，性能损耗明显。对毕设体量来说，自增主键是压倒性的最优解。

第二，统一字段命名规范。数据库字段推荐用下划线命名（如create_time），而Java实体类里使用驼峰命名（如createTime），通过MyBatis-Plus的驼峰映射设置可以自动转换。如果不做这个配置，要么前端返回的JSON字段全部是带下划线的，要么就得写一堆@JsonProperty注解去映射，非常麻烦。

第三，不要在数据库里存储图片文件本身，存图片URL路径就行。实际部署的时候，图片可以放在服务器的静态资源目录下，也可以存到云存储上，后端只维护一个URL字符串。这样数据库表会非常干净，查询效率也高。

第四，关于逻辑删除。给关键表加上deleted字段，用0和1标记是否删除，而不是真正DELETE。这样做的目的是为了保护数据，尤其是用户表、攻略表这类有后续关联的数据。MyBatis-Plus提供了@TableLogic注解，配置之后所有的删除操作都会自动变成更新操作，非常简单。

4. 后端接口与核心模块实现

4.1 用户模块与JWT鉴权

用户模块是系统的访问入口，核心接口包括注册、登录、获取用户信息、修改个人信息、修改密码。这里我重点讲登录鉴权方式——JWT（JSON Web Token）。

我在指导中发现，不少学校教的还是传统Session方案，登录成功后把用户信息存在服务器的Session里，客户端持有SessionId。这种方案在单体应用里没什么问题，但它在APP场景下有个天生的缺点：APP的HTTP请求是无状态的，每次请求都要携带SessionId，服务器端还得维护Session存储。这在分布式环境下根本没法用，而且也不符合现在主流的接口认证方式。

JWT的思路是服务器不保存登录状态，用户登录成功后，服务器生成一个包含用户ID、过期时间等信息的Token返回给客户端。客户端后续每次请求都在Headers里带上这个Token，服务器只需要验证Token的签名和过期时间，就能确认用户身份。这种无状态认证方式不仅代码简单，而且在答辩时能讲出亮点。

基于Java的JWT实现，推荐使用jwt或java-jwt库，核心代码大概长这样：

// 生成Token String token = JWT.create() .withClaim("userId", user.getId()) .withClaim("username", user.getUsername()) .withExpiresAt(new Date(System.currentTimeMillis() + 7 * 24 * 60 * 60 * 1000)) .sign(Algorithm.HMAC256("你的密钥")); // 解析Token DecodedJWT decoded = JWT.require(Algorithm.HMAC256("你的密钥")) .build() .verify(token); Long userId = decoded.getClaim("userId").asLong();

有了Token之后，需要在后端写一个拦截器，对所有需要登录的接口进行Token校验。注意不要把校验逻辑写在每个Controller里，而是用Spring MVC的拦截器机制统一处理。继承HandlerInterceptorAdapter，在preHandle方法中从Header中取出Token并解析，如果解析失败就直接返回401状态码，不再进入Controller层。

4.2 景点与线路推荐模块

景点模块的接口比较常规，无非是分页获取景点列表、根据条件搜索景点、获取景点详情。这里说一下搜索接口的写法。如果只是按名称模糊查询，MyBatis-Plus的like条件就够用了。但如果想做得更像样一点，可以加一个城市下拉筛选，配合关键词搜索，还能支持按热度排序和按价格区间筛选。

推荐模块是体现“智能”二字的重点，也是很多学生最容易做过头的地方。我见过有学生真的去用了Python后端调一个机器学习模型来做推荐，结果技术上确实展示了，但整个系统的部署复杂度直线上升，一旦模型预测不准，反而成了答辩时的硬伤。

我的建议是做一个两步走的推荐方案。第一步，基于物品的协同过滤：用户A收藏了景点X，系统将所有收藏过景点X的用户找出来，再看这些用户还收藏了哪些其他景点，按收藏次数排序取Top N推荐给用户A。这个逻辑用SQL写起来也不难，但代码层面更容易实现的是第二步——基于标签匹配的推荐：景点有类型标签，用户在收藏行为中天然累积了“感兴趣的类型”，系统统计用户收藏的景点类型分布，找出占比最高的类型，然后把该类型下热度值最高的景点推荐给用户。

这个方案的好处是逻辑简单、可解释性强，答辩时你可以直接说清楚“我是基于什么逻辑做的推荐”，不会让人感觉是玄学。而且数据量不大的情况下，它的推荐效果甚至比复杂的深度模型更稳定。

线路规划方面，可以做一个城市内路线推荐接口，输入城市名和游玩天数，返回该城市高分景点的合理排列组合。这个纯粹是基于规则的方式处理：先把指定城市的景点按热度降序排列，再按“日均游览3-4个景点”的节奏切分到每天，生成一条推荐线路。这样写出的功能看得见摸得着，用户是真的能用到。

4.3 攻略模块与内容展示

攻略模块的设计逻辑是这样的：普通用户登录后可以发布攻略，内容包括标题、封面图、目的地城市、出行天数、人均花费、行程正文、出行标签。攻略提交后默认状态为待审核，管理员在后台审核通过后才会展示在前台列表页。这个审核机制不仅能丰富系统的数据层次，也让后台管理模块有了实际的工作内容，而不是摆设。

攻略列表的查询要注意性能问题。如果直接表连接攻略表和用户表来获取作者头像和昵称，在数据量大的时候会有性能隐患。一个更稳妥的做法是：攻略表里冗余存储作者的头像和昵称字段，在发布攻略时从用户表带过来。虽然从数据库规范的角度看存在数据冗余，但对于这个体量的项目来说，用空间换查询速度是完全值得的。

评论模块的设计我放在这里一起讲。评论表和攻略表是父子关系，查询评论列表时要用攻略ID过滤。注意在展示评论列表时，是需要关联用户表拿到评论者的头像和昵称的，这里就没办法冗余了，因为评论可能由任意用户发布。我的经验是分页查询评论时，直接用一条联表SQL搞定，别在Java代码里做循环查询，否则会产生N+1问题，列表一多就卡顿。

5. Android端开发与踩坑实录

5.1 项目骨架与网络层封装

Android端的工程结构，我用的是标准的MVP模式或者MVVM模式。毕设答辩时老师大概率会问“你这个项目的架构是什么样的”，如果你说“就是Activity直接访问网络”，那未免有些太单薄。所以至少要让代码分层：界面层（Activity/Fragment）、逻辑层（Presenter或ViewModel）、数据层（网络请求和本地存储）。

网络层的封装是Android端最重要的基础设施。我用Retrofit来封装HTTP请求，需要定义一个接口来描述所有后端API：

public interface ApiService { @POST("api/user/login") Call<ApiResponse<LoginData>> login(@Body LoginRequest request); @GET("api/scenic/list") Call<ApiResponse<PageResult<ScenicSpot>>> getScenicList( @Query("current") int current, @Query("size") int size, @Query("city") String city, @Query("keyword") String keyword); }

Retrofit用起来很简单，但你必须在网络层做三件事：统一的请求头注入（把Token添加到Header中）、统一的异常处理（网络超时、服务器错误、Token过期）、统一的进度条控制。这三个问题不做好的话，你会发现自己的代码里塞满了重复的状态判断。

Token注入可以通过OkHttp的Interceptor实现：

public class AuthInterceptor implements Interceptor { @Override public Response intercept(Chain chain) throws IOException { Request original = chain.request(); Request.Builder builder = original.newBuilder(); if (TokenManager.getInstance().getToken() != null) { builder.addHeader("Authorization", "Bearer " + TokenManager.getInstance().getToken()); } return chain.proceed(builder.build()); } }

Token过期这个场景很多学生处理得很粗糙，直接弹一个“网络错误”就完事了。更好的处理方式是在统一的业务异常处理中判断返回码：如果是401，就清理本地用户信息，跳转到登录页，同时用Toast提示“登录已过期，请重新登录”。这个细节属于答辩中的亮点级体验优化。

5.2 地图与定位功能的适配细节

题目里有“自助服务”这个关键词，很多学生自然地会想加入地图模块。地图功能的实现，我建议用高德、腾讯或其他国内地图SDK，为什么不用谷歌？显而易见的原因是访问不便，调试的时候各种奇奇怪怪的问题，毕设时间经不起这么折腾。

接入国内地图SDK时，最容易踩的坑是Key申请和权限配置。高德地图SDK要求你在官网申请Key，同时在AndroidManifest.xml中配置包名和SHA1签名。这个SHA1签名分debug版本和release版本，如果你在开发时用的是debug签名，但发布时用了release签名，那地图是加载不出来的。很多学生折腾半天打不开地图，多半就是签名不一致导致的。

定位功能需要动态申请权限。Android 6.0及以上需要运行时权限申请，Android 10及以上还要特别注意，ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION只能拿到大概位置，精确定位需要额外判断。另外千万别忘了在设备的应用管理里给这个APP开启定位权限开关，否则代码里就算权限申请成功了，系统也会返回一个空位置。

弹权限申请框的正确姿势不是一进APP就要，而是等到用户确实要使用定位功能时再申请。这样更符合Android的设计规范，用户体验也好。你可以在打开某个景点详情页时再弹出定位权限，请求周边推荐。

5.3 Android高版本适配问题

现在Android的适配问题比前几年复杂多了。如果你用的编译SDK版本是Android 12或更高，必须处理以下几个问题：

第一，明文流量限制。Android 9.0（API 28）开始默认禁止应用使用明文HTTP流量。如果你的后端服务器没有配置HTTPS证书，那访问就会直接报错。最简单的做法是在AndroidManifest.xml的application标签里加上android:usesCleartextTraffic="true"，允许明文流量。但这个字段只在开发和测试阶段这么干，上线肯定不行。答辩演示时如果没有说明这一步，老师可能会问安全性的问题，你需要想好怎么回答。

第二，FileProvider和图片选择。Android 7.0之后，应用不能直接通过file://的Uri在不同App间共享文件，需要改用FileProvider。这意味着你的APP如果涉及选择头像、拍照上传这些功能，就必须配置FileProvider和xml路径，否则一启动相机应用就崩。

第三，适配屏幕尺寸。现在市面上的手机屏幕什么尺寸都有，如果你在布局里写死了dp尺寸，小屏还好，大屏就容易出现布局错乱。推荐用ConstraintLayout做复杂布局，简单布局用LinearLayout配合权重来做伸展。

6. 常见问题与排查技巧实录

6.1 开发过程中高频踩坑点

先整理一份高频问题速查表，这些都是我实际见到的学生卡壳最久的问题。

第一个是接口返回的JSON日期格式问题。Java后端的LocalDateTime默认序列化出来是RFC格式的字符串，比如“2025-01-15T10:30:00”。Android端用Gson解析时，如果你的业务Bean里是Date类型，就会解析失败。解决办法是在SpringBoot的配置中统一设置全局的日期格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

第二个是CORS跨域问题。如果前端调试时用了浏览器插件访问后台接口，或者某些测试工具（比如Postman）直接访问，有时会碰到跨域报错。对自带后台管理页面和API接口共存的SpringBoot项目，建议配置一个CorsFilter，放行所有来源的请求。注意配置时允许的请求方法要加全，GET、POST、PUT、DELETE都放行，有些学生只放行GET和POST，导致前端的删除请求全部失败，排查半天才发现是CORS问题。

第三个是Android端列表图片加载闪烁问题。这个问题的根源通常是ViewHolder复用和Glide加载冲突。解决办法就是在Adapter中写一行代码：

Glide.with(context) .load(url) .skipMemoryCache(false) .diskCacheStrategy(DiskCacheStrategy.ALL) .placeholder(R.drawable.img_default) .into(holder.ivImage);

如果你用的是上面的写法还有闪烁，多半是你把图片URL拼错了，导致Glide请求了一张不存在的图片，每次都走网络请求重新加载。排查方法是打开网络日志，看图片请求返回的是200还是404。

第四是本地调试时MySQL连接不上。这个是环境问题高发区，最常见的原因是MySQL 8.0的时区设置和驱动版本不匹配。驱动要用最新版本（mysql-connector-java 8.0.30以上），连接串要加上serverTimezone=Asia/Shanghai，否则启动SpringBoot时会报数据库连接超时或者时区不支持的错误。

6.2 毕业设计答辩的加分项

答辩的时候，老师不看你的代码是不是抄的，看的是你能不能把他做的系统讲明白。我建议答辩前的准备围绕几个点展开。

第一，准备一张系统功能结构图。不需要太复杂的手绘或Mermaid，画在PPT里或者直接画在白板上都行，重点是把“用户端APP和后台管理端互相配合”的逻辑讲清楚。老师看到你对自己的系统有全局认识，印象分自然就上去了。

第二，准备好项目亮点和技术难点的表述。比如“我在实现推荐功能时，没有用那种黑盒的复杂模型，而是设计了一种基于标签匹配和热度的规则推荐，并根据用户实时行为动态调整推荐结果”。这种话一出口，老师就能感受到你是真的在思考设计，而不是堆砌功能。

第三，准备好对常见技术问题的回答。老师大概率会问：你用的数据库是MySQL，那MySQL的事务机制了解多少？你的登录认证是怎么做的？如果数据量大，你的接口有没有性能优化？这些问题不一定都来自你的项目，有些是通用技术问题。建议提前把SQL优化、索引原理、HTTP状态码、Android生命周期这些基础概念过一遍。

第四，演示数据要提前准备到位。答辩用的模拟数据要看起来“真实”，景点名称、攻略内容、用户昵称都提前设计好，不要在演示时现场敲字，出现手忙脚乱的情况。最好准备一组演示脚本，一步一步展示注册、浏览景点、查看攻略、收藏、后台审核发布的全流程，每个步骤配合简短的讲解，流畅的演示比什么花哨的技术描述都管用。

我个人在实际指导中的体会是，这个题目能不能做好的分水岭，不在于你用了多高级的框架或者算法，而在于你有没有把“用户从注册到获取出行建议”这条完整链路跑通。数据库设计得再漂亮，接口写不好，视图层全是问题，最后还是在答辩现场翻车。反过来，哪怕功能精简一点，但每个模块逻辑自洽、交互顺畅、代码结构清晰，照样能拿到不错的成绩。

最后再分享一个小技巧。答辩之前，把你的项目拿到一台没有配置过任何环境的机器上完整部署一遍——数据库装好、后端跑起来、APK装上。这个动作至少提前做两次，保证你在任何一台机器上都能顺畅演示。我见过不少学生自己在笔记本上跑得飞起，一到答辩用的电脑就各种环境问题，那种尴尬谁也不想来第二次。提前演练，是目前我能想到的最靠谱的兜底方案。