旅游小程序毕设开发指南：需求、技术、答辩全流程

1. 项目立项：为什么旅游小程序适合做毕设

每到毕业季，总有人问我毕设选什么题。我的建议一直很明确：如果你想选一个工作量适中、技术点覆盖面广、答辩演示效果好、而且源码和素材都好找的题目，旅游类微信小程序几乎是首选。它不像电商平台一样牵扯复杂的订单履约和售后体系，也不像社交类App一样需要做实时通信，但同时又完整包含了信息展示、数据检索、用户交互、位置服务、订单流程、内容管理这些核心开发场景，做下来以后，前后端的核心能力基本都练到了。

旅游小程序的覆盖范围可以从很简单的"景点图文展示"一路扩展到"酒店民宿预订 + 路线规划 + 特产商城 + 用户收藏评论 + 后台数据管理"，功能边界完全由你掌握。如果你论文需要写"系统的创新点"，还可以加上路线智能推荐、语音导览、基于位置的附近景点推荐等模块。相比单纯做"图书管理"或者"学生选课"那种传统的CRUD管理系统，旅游小程序的展示效果华丽很多，答辩现场打开小程序扫一扫，效果远比PPT截图来得有说服力。

从工作量角度来评估，一个功能完整但不过度设计的旅游小程序，前端页面大概在15到20个，后端数据表在10张左右，核心业务接口在20个上下，一个人认真做大概6到8周可以完成。这个节奏对于毕设来说比较合理，不会因为任务量太大影响考研或者实习安排，也不会因为太简单导致答辩时没东西可讲。

收益层面，这类项目做完以后，完全可以作为作品放在简历里，因为旅游行业的小程序需求很大，很多线下景区、旅行社、民宿老板都在找电商化解决方案。哪怕你后续不从事小程序方向，整个项目从需求分析、数据库设计到前后端联调、部署上线的流程经验，在软件工程面试中也是可以拿出来讲的硬通货。

2. 需求分析与功能拆解：先想清楚要做什么

很多人做毕设一上来就写代码，做到一半发现功能越做越乱，最后论文也没法圆回来。正确做法是先做需求分析，把功能边界界定清楚，再动手。旅游小程序的需求分析其实可以分成用户端和管理端两个视角来看。

2.1 用户端功能模块

用户端是核心展示层，直接决定演示效果。我的建议是必须包含以下六个模块：

• 首页：轮播图、搜索框、热门景点推荐、分类入口（景点 / 酒店 / 美食 / 线路）、最新活动公告。
• 景点列表与详情：景点分类筛选、关键词搜索、景点详情页包含图文介绍、地图位置、开放时间、门票价格、用户评价。
• 酒店与民宿预订：酒店列表、房型展示、日期选择、下单预订、订单状态查看。
• 旅游线路规划：系统预设几条经典线路，用户也可以根据景点位置自选生成一日游/两日游线路，路线以列表和地图轨迹两种方式展示。
• 个人中心：登录注册、我的订单、我的收藏、浏览记录、意见反馈、设置。
• 辅助功能：景点导航（调起地图App或内嵌地图组件）、门票购买（如果做支付模块）、分享给微信好友。

有些同学会问：要不要做"特产商城"？可以做，但要注意工作量控制。商城模块会牵扯到商品SKU、购物车、库存、支付退款等一系列逻辑，如果已经做了酒店预订，再加商城会让体量翻倍。我的建议是如果时间紧张，把特产商城收敛成"景点文创推荐"列表页，展示加收藏即可，不做下单流程，论文里把它归为"资讯展示类模块"，逻辑上也说得通。

2.2 管理端功能模块

管理端不一定需要做成独立的管理系统，尤其是用微信云开发做后端的项目，直接在云开发控制台里管理数据就够了。但为了论文内容好看，建议做一个简单的后台管理页面，技术栈用纯HTML + JavaScript + 云开发SDK即可，不需要额外部署服务器。

管理端至少要有这几个功能：

• 景点信息管理：添加、编辑、上下架景点内容。
• 酒店房型管理：维护房型、价格、库存。
• 订单管理：查看所有用户订单、修改订单状态（待支付 / 已支付 / 已取消 / 已完成）。
• 轮播图管理：配置首页轮播图。
• 数据统计：简单的访问量、订单量统计，用图表展示。

2.3 数据库设计

数据库设计是论文里"系统设计"章节的核心内容，设计得好不好直接决定论文的含金量。基于云开发的旅游小程序，数据表建议这样划分：

订单状态字段建议用数字表示，0待支付、1已支付、2已取消、3已完成、4退款中、5已退款，而不是直接存中文，这样后续扩展状态机也比较方便。收藏表要注意给 userId + targetType + targetId 建联合索引，否则数据量大了以后查询会变慢。

3. 技术选型：原生开发还是uni-app，后端用云开发还是自建

技术选型是论文里"技术介绍"章节的重点，也是答辩时评委最爱问的问题。很多人的错误是选型理由写得太虚，比如"微信小程序生态成熟"这种话，评委听着完全没有感觉。技术选型必须结合项目实际情况给出有说服力的理由。

3.1 前端：原生微信小程序的优势

目前主流的小程序前端方案无非三种：微信原生、uni-app、Taro。毕设场景下我推荐原生开发，理由有三个。

第一，原生开发不需要额外引入框架层，项目结构就是标准的 pages 目录 + app.json 配置，发现问题好排查，答辩时被问到底层原理也能讲得清楚。第二，原生组件的调用方式最直接，比如 wx.login、wx.request、wx.chooseLocation 这些API都是原生语法，网上资料最多，遇到问题搜解决方案也最快。第三，原生小程序的性能表现通常比跨端框架好一点，因为少了编译层转换的开销。

如果你自己已经熟悉 Vue，那用 uni-app 也完全可以，尤其是你打算以后同时做App端的话，uni-app 的跨端能力确实有优势。但从"毕设求稳"的角度来看，原生开发的风险最低。论文的技术选型部分就写"为了确保系统在微信环境下的稳定性和API兼容性，采用微信小程序原生框架开发"，简洁且站得住脚。

3.2 后端：云开发是最省事的选择

后端的方案选择，直接影响你整个项目的工作量和答辩时可能遇到的坑。这里我把几个主流方案摆出来对比一下：

说实话，现在毕设做小程序，云开发几乎是"默认选项"。云端的数据库、存储、云函数三件套完全覆盖了旅游小程序的全部需求，而且云开发自带权限控制，前端可以直接调用数据库，不用自己写后端登录鉴权逻辑。云开发还提供了"开通按量付费"的低成本方案，个人项目基本在免费额度内就能跑起来，不用花一分钱。

有的人担心用云开发会被评委质疑"没做后端"，这个顾虑其实可以打消。你设计了数据库表结构、写了云函数处理业务逻辑、实现了数据权限校验，这本身就是后端工作。论文里把云开发定位成"服务端托管平台"，把云函数定位成"业务逻辑层"，逻辑完全自洽。如果你希望保险一点，还可以在云函数里做一些复杂业务，比如生成订单号、多表联查、库存扣减，用这些体现后端设计能力。

3.3 小程序商城等扩展模块的选型问题

热搜词里反复出现"小程序商城"和"购买小程序平台"，如果你是想在旅游小程序里加入商城模块，那要注意一个问题：不要直接用别人封装好的商城模板改，因为模板的代码结构往往很混乱，论文里没法交代清楚。我的建议是自学一遍购物车的核心逻辑，把加入购物车、购物车列表、下单、订单支付这几个功能自己写出来，工作量并没有想象中那么大。

商城模块的技术要点其实就两个：购物车数据保存在本地缓存还是云数据库，以及支付逻辑怎么走。购物车用本地缓存（wx.setStorageSync）实现，体验好且无服务器压力，但换设备后购物车数据就丢了；用云数据库实现，数据持久化但每次增删改查都有网络开销。毕设场景下两种方案都可以，我更推荐云数据库，因为可以在论文里写"购物车数据云端同步，支持多端登录场景"，效果更好。

4. 核心模块的代码实现：从页面到云函数

题目里提到"附源代码+演示视频"，说明你要交付的是完整能跑的项目。这里我把核心几个模块的代码实现拆开讲一讲，都是实际项目里验证过能跑的方案。

4.1 项目结构规划

一个合理的原生小程序项目结构长这样：

cloudf-travel/ ├── cloudfunctions/ │ ├── login/ // 登录云函数 │ ├── getSpots/ // 获取景点列表 │ ├── getSpotDetail/ // 获取景点详情 │ ├── createOrder/ // 创建订单 │ ├── updateOrder/ // 更新订单状态 │ └── getOrders/ // 查询用户订单 ├── pages/ │ ├── index/ // 首页 │ ├── spotList/ // 景点列表 │ ├── spotDetail/ // 景点详情 │ ├── hotelList/ // 酒店列表 │ ├── hotelDetail/ // 酒店详情 │ ├── booking/ // 预订页 │ ├── orders/ // 订单列表 │ ├── personal/ // 个人中心 │ └── route/ // 旅游线路 ├── components/ // 自定义组件 ├── utils/ │ ├── request.js // 请求封装 │ └── auth.js // 登录校验 ├── images/ // 静态资源 ├── app.js ├── app.json └── app.wxss

云函数和页面一一对应，每个云函数单独维护，这种结构在答辩讲解时非常清晰，你只要说清楚"每个业务操作对应一个云函数"，评委立刻就能理解你的系统架构。

4.2 云数据库的初始化和权限设置

云开发的项目，首先要确保在 app.js 里正确初始化云环境。很多新手项目跑不起来，百分之八十是环境ID没配对。

// app.js App({ onLaunch: function () { if (!wx.cloud) { console.error('请使用 2.2.3 或以上的基础库以使用云能力'); return; } wx.cloud.init({ env: 'your-environment-id', // 这里必须改成你自己的环境ID traceUser: true }); } });

环境ID在云开发控制台首页可以看到，是一串类似cloud1-xxxxxx的字符串。很多同学从网上下的源码，直接跑别人的环境ID，结果就是权限不足或者数据为空。拿到源码第一步就是去 app.js 和每个云函数里的 config.json 中把所有环境ID替换成自己的。

数据库集合的权限设置也很关键。云开发数据库默认有四种权限设置，建议这样配置：

• 对于需要公开读取的集合（如 spots、hotels、banners），设置为"所有用户可读，仅创建者可读写"。
• 对于订单、收藏等涉及用户私有数据的集合，设置为"仅创建者可读写"。
• 云函数端使用管理端权限操作数据库，可以绕过前端的读写限制，适合做数据校验和订单创建。

4.3 首页与景点列表的渲染逻辑

首页的轮播图和数据列表，通过云函数查询再返回给前端，是比较标准的做法。这里的关键点是云函数里要处理好数据返回格式。

先看一个获取景点列表的云函数示例：

// cloudfunctions/getSpots/index.js const cloud = require('wx-server-sdk'); cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }); const db = cloud.database(); exports.main = async (event, context) => { const { category = '', keyword = '', page = 0, pageSize = 10 } = event; let where = { status: true }; if (category) { where.category = category; } if (keyword) { where.title = db.RegExp({ regexp: keyword, options: 'i' }); } try { const countResult = await db.collection('spots').where(where).count(); const res = await db.collection('spots') .where(where) .skip(page * pageSize) .limit(pageSize) .orderBy('createTime', 'desc') .get(); return { code: 0, data: { list: res.data, total: countResult.total, hasMore: (page + 1) * pageSize < countResult.total } }; } catch (err) { return { code: -1, msg: err.message }; } };

这段代码的关键点在于分页参数的设计，page 从 0 开始，pageSize 控制每页条数，hasMore 字段用于前端判断是否还有下一页。前端拿到数据后用 onReachBottom 触底加载，这样用户体验好，论文里也可以写"实现了列表的分页加载，优化大数据量场景下的渲染性能"。

前端请求封装在 utils/request.js 里，统一调用云函数：

// utils/request.js function callFunction(name, data = {}) { return wx.cloud.callFunction({ name, data }).then(res => { if (res.result && res.result.code === 0) { return res.result.data; } else { wx.showToast({ title: (res.result && res.result.msg) || '请求失败', icon: 'none' }); return Promise.reject(res.result || {}); } }); } module.exports = { callFunction };

这里做了一个简单的约定：云函数统一返回 { code: 0, data: xxx } 表示成功，非0表示失败。这个约定的好处是前端处理逻辑高度统一，不用每个页面单独写错误处理。

4.4 微信支付v3对接的现实困境

热搜词里专门有"小程序微信支付v3对接"，这说明很多人做毕设都卡在支付环节。但我必须泼一盆冷水：微信支付对于个人开发者来说基本是"开不下来的"。微信支付要求主体必须是企业、个体工商户或政府机关等，个人主体无法申请微信支付商户号。即使你借了朋友的个体工商户资质申请了商户号，小程序后台也需要进行支付权限申请，平台会审核你的行业资质，旅游类目还需要提供旅行社业务经营许可证等资质，非常麻烦。

所以毕设项目里，我的建议是做一个"模拟支付流程"：用户点击支付后，弹出支付确认框，确认后直接生成支付成功订单。同时在论文里写明"由于支付接口需要企业资质，系统采用模拟支付策略，预留了微信支付v3接口的对接方案，企业用户可通过配置商户号、API密钥等信息实现真实支付"。这个写法既诚实又不影响答辩效果。

如果非要在项目里展示真实支付，可以在云函数里引用微信支付的云开发扩展能力，或者用开发版的小程序配合测试商户号做联调，但这个复杂度已经超出毕设必要范围了。更多精力应该花在订单状态流上，因为订单状态流转逻辑写得清楚，本身就很加分。

订单状态机建议这样设计：待支付 -> 已支付 -> 已完成，任何一个状态都可以 -> 已取消。云函数里通过更新状态的原子操作避免并发问题。

4.5 地图导航与线路规划的实现

旅游小程序里地图功能是展示亮点。微信小程序原生提供了<map>组件，配合腾讯位置服务API可以实现定位和路径规划。

景点详情页的地图使用比较简单：

<map id="spotMap" longitude="{{spot.longitude}}" latitude="{{spot.latitude}}" markers="{{markers}}" scale="14" show-location style="width: 100%; height: 300rpx;" />

markers 数组在 js 里构建：

this.setData({ markers: [{ id: 1, latitude: spot.latitude, longitude: spot.longitude, title: spot.title, iconPath: '/images/marker.png', width: 30, height: 30 }] });

更上档次一点的做法是做"调用微信内置导航"，用wx.openLocation：

wx.openLocation({ latitude: Number(spot.latitude), longitude: Number(spot.longitude), name: spot.title, address: spot.address, scale: 18 });

这样点击"去这里"按钮就能调起微信内置的地图导航能力，用户可以直接用腾讯地图或高德导航过去。

旅游线路方面，比较简单可靠的方案是预设线路 + 列表展示。如果要做"用户自选景点生成路线"，可以用云函数计算景点之间的直线距离，然后按顺序排列。直线距离用 Haversine 公式计算就可以，在云函数里跑，基本不耗时。

5. 毕业论文写作框架与注意事项

论文是毕设的另一半工作量，也是最容易拖到最后一刻才动笔的部分。很多人代码写完了才写论文，时间紧就东拼西凑，查重率爆表。我的建议是：代码写一个功能模块，就同步写论文里对应的章节，代码和论文同步推进，最后再整体打磨，效率最高。

5.1 论文的整体结构

本科毕业论文一般要求8000到15000字，旅游小程序这个题目的论文结构建议这样安排：

• 第一章 绪论：项目背景、国内外研究现状、研究意义、主要工作。约1500字。
• 第二章 相关技术介绍：微信小程序开发框架、云开发平台、JavaScript语言、腾讯地图API。约1500字。
• 第三章 系统需求分析：可行性分析（技术、经济、操作）、功能需求分析（功能性需求 + 非功能性需求）、用例图。约2000字。
• 第四章 系统设计：系统总体架构设计、功能模块设计、数据库设计（E-R图 + 数据表结构）。约3000字。
• 第五章 系统实现：核心功能模块的实现思路、关键代码展示、界面截图。约4000字。
• 第六章 系统测试：测试环境、测试用例、测试结果、功能测试 + 兼容性测试。约1500字。
• 第七章 总结与展望：项目总结、不足之处、未来改进方向。约800字。

你注意到没有，这个结构里"系统设计"和"系统实现"占了最大篇幅，这也是评委最关注的部分。与其花很多篇幅写"研究背景"里那些空话，不如把数据库表结构画清楚、把关键代码讲明白。

5.2 如何写出有深度的章节

大多数同学的论文败在"系统实现"章节只贴代码不解释。正确的写法是：先描述这个模块要实现什么功能，遇到什么难点，你的解决思路是什么，然后贴核心代码的片段，最后用图展示运行效果。

举个例子，菜单模块你可以在"核心实现"里这样写：

在酒店预订功能中，存在房型库存与订单状态一致性的问题。用户在预订页选择日期后，系统需要判断该日期下房型的剩余库存是否满足需求。考虑到并发访问场景下的超卖问题，本系统在创建订单时使用云数据库的事务能力，将库存扣减和订单创建放入同一个事务中执行，确保数据的一致性。

然后贴上事务处理的云函数代码，这样这个功能就从"会跑"变成了"有技术深度"。

查重降重方面，核心技术介绍章节可以参考官方文档但一定要改写成自己的话。数据库表结构自己画的表格不会被查重。代码一般不会被查重系统标记，因为代码在论文中通常按灰色文本处理。最容易被标记的是绪论的背景介绍和国内外现状这类套话，写作时可以多用实际数据、具体事件来替代空泛表述。

5.3 代码目录与注释的规范化

论文提交时往往需要附源码。你项目的代码结构越清晰，评审老师的印象越好。除了源码本身，我建议在项目根目录写一个 README.md，内容包括项目简介、功能清单、环境要求、部署步骤、默认账号等。这个小文件不费时间，但专业感一下就上来了。

源码注释方面，核心函数建议使用 JSDoc 风格的注释，尤其是云函数的入参和返回结构，别人一看就明白。例如：

/** * 创建酒店订单 * @param {string} roomId - 房型ID * @param {string} startDate - 入住日期 YYYY-MM-DD * @param {string} endDate - 离店日期 YYYY-MM-DD * @param {number} quantity - 房间数量 * @returns {object} { orderNo, amount } */

6. PPT制作与演示视频录制的核心技巧

PPT和演示视频是答辩的门面，做得好的话能在5分钟内让评委对你的项目形成好印象。

6.1 PPT页面的信息架构

答辩PPT控制在12到15页左右，内容分配如下：

• 封面页（1页）：题目、姓名、学号、指导老师。
• 目录页（1页）：研究背景、需求分析、系统设计、功能展示、总结。
• 研究背景与意义（1至2页）：用数据说明旅游行业线上化趋势，点到为止。
• 关键技术介绍（1至2页）：微信小程序框架、云开发、地图API，配架构图。
• 需求分析（2页）：用户端和管理端的功能点，用功能结构图展示。
• 系统设计（2至3页）：系统架构图、数据库E-R图、核心表结构。
• 核心功能实现（2至3页）：挑两三个亮点功能，比如首页数据加载、酒店预订下单、地图导航，配实际运行截图。
• 系统测试（1页）：测试用例表 + 测试结果。
• 总结与致谢（1页）：项目收获、不足、下一步计划。

PPT的排版原则是"图文并茂，字少图多"。每页不超过6行文字，其他用架构图、流程图和截图补充。不要用网上花哨的模板，干净的深蓝色或墨绿色配色最稳妥。

6.2 答辩演示时怎么讲

答辩现场演示小程序时，最容易翻车的场景是现场网络不好、域名没过审、真机预览白屏。稳妥的做法是提前录制好演示视频，答辩现场直接播放，然后再用自己的电脑打开开发者工具做简单的补充演示。

演示手机建议提前准备一台安装了微信开发者版的测试机，打开体验版二维码让评委扫。但评委不一定愿意掏手机扫，所以备好视频是底线。

演示视频的录制要点：

• 总时长控制在3到5分钟。
• 使用模拟器或真机录屏，画质要清晰，避免模糊和抖动。
• 录屏工具可以用手机自带的录屏功能，或者用开发者工具自带的录屏。
• 视频按"从用户视角出发"的逻辑来录，先打开小程序看首页，然后搜索景点、查看详情、导航、预订酒店、查看订单，一气呵成。
• 操作过程中可以配旁白讲解，但不要念PPT，而是以"我现在打开的是首页，可以看到轮播图和热门景点推荐"这种自然口吻来描述。

6.3 演示视频后期处理

演示视频录完后可以用剪映或快剪辑简单处理一下。需要添加的部分包括：片头标题、重点功能字幕、关键操作放大效果。不需要搞炫酷转场，清晰自然最重要。

导出视频时选择1080p分辨率，时长控制在5分钟内，文件大小控制在100MB以内，视频编码用H.264，这样可以在微信里直接播放，如果提交到网盘也不需要花太久上传。

7. 常见问题与实战排查经验

最后这部分是干货中的干货。以上这些功能开发过程中，几乎每个环节都有容易踩的坑，我挑几个高频问题集中说一下。

7.1 域名校验和合法域名配置

用自建后端的学生一定要注意这个问题：微信小程序在真机上访问非HTTPS接口会被拦截，需要在微信公众平台配置 request 合法域名。云开发不存在这个问题，因为云函数和数据库的域名是微信内置的，不需要配置。但如果你用了外部图片资源，比如图片存储在自己的服务器上，就需要在 downloadFile 合法域名里配置。

有人会问：用开发者工具点"不校验合法域名"不就行了吗？可以，但那个选项只在开发者工具里有效，手机上仍然不能访问。而且演示那天如果评委死活要看你自己的数据库，因为域名没配置而白屏，那场面会非常尴尬。

7.2 真机预览白屏的排查思路

真机预览白屏是毕设答辩前的高频事故。大多数情况下是因为手机微信的基础库版本太低，项目里用了一些新的API。排查思路是：先在开发者工具里看到底有没有报错，然后点击"预览"按钮前的"真机调试"，把手机连上电脑看Console日志。我发现一个规律：白屏里面十有八九是数据读取权限的问题，云开发数据库打开了"仅创建者可读写"，而前端不是创建者，所以读取不到数据。把权限改成"所有用户可读"或者在云函数里绕开权限读取，问题马上解决。

7.3 云函数超时与性能问题

云函数的默认超时时间是3秒，如果你处理逻辑复杂，比如同时联查多个表、生成订单号、调用外部API，3秒很容易超时。在云开发控制台可以把超时时间调到20秒，但如果真的太慢，还是要检查代码，看看是不是有循环查库之类的低效写法。

一个典型场景：列表页每个景点都要去关联查询评论数，如果写成一个循环里查十次库，性能一定差。正确的做法是一次性把景点数据查出来，再按ID批量查评论数，利用云数据库的_.in()操作符。

7.4 微信支付v3对接失败怎么办

如果你的代码里接了真实的微信支付，但一直报签名错误或者商户号无效，大概率是参数配置问题。检查API v3密钥是否与商户平台一致、商户证书序列号是否填对、小程序AppID是否已关联商户号。这里有一个很容易被忽略的点：微信支付v3要求用商户私钥对请求签名，很多人把APIv3密钥当作签名密钥去用，一直报签名错误。另外，如果是测试环境，注意要在商户平台开通"APPID授权"。

如果实在调不通，就用我前面说的模拟支付，把这个模块从"真实实现"降级为"链路预留"，然后在论文和答辩中说明原因，完全不影响分数。

7.5 拿到别人的源码怎么跑起来

很多人会遇到从网上下的旅游小程序源码打不开、白屏、报错的问题。按这个顺序排查：

1. 打开 project.config.json，把 appid 改成你自己的测试号 AppID。
2. 在 app.js 里把云环境ID替换成你自己的环境ID。
3. 在云开发控制台创建好所有集合，并手工录入几条测试数据。
4. 给每个云函数右键"上传并部署：云端安装依赖"。
5. 在云开发控制台检查所有集合的权限设置。

这五步做完，90%的源码都能跑起来。剩下的10%是云函数引用了你没开通的扩展能力，比如HTTP API或定时触发器，去云开发控制台逐个开通就好。

8. 个人经验与总结建议

最后再分享一个我做过多个类似项目后总结出的经验。做旅游小程序毕设，最大的误区是"追求功能多"，而不是"把核心链路做到极致"。一个首页展示 + 景点详情 + 收藏 + 个人中心的简单项目和一个首页展示 + 搜索 + 筛选 + 详情 + 评论 + 酒店预订 + 订单全流程 + 地图导航 + 后台管理的项目，后者的论文篇幅和答辩效果都更占优势，但多出来的工作量其实并没有翻倍，关键在于你是否真的理解了每个功能模块的设计缘由。

如果你在时间规划上比较紧张，我建议给项目排一个四阶段进度：前两周做需求分析和数据库设计，中间四周完成前端页面和云函数开发，再往后两周写论文和制作PPT，最后一周录演示视频、测试、打磨答辩稿。每个阶段结束时都要能跑的通一个小demo，这样即使中途有突发情况，你手里也始终有可以展示的成果。

另外，源码管理从第一天开始就用 Git 托管到自己的私有仓库，每天提交一次，这个小习惯能让你的开发过程形成清晰的提交记录。答辩时如果被问到开发流程，你可以直接展示 Git 提交记录，证明这个项目确实是独立开发的。

做毕设这件事情，重要的是养成把需求落地成系统的完整思路，而不仅仅是为了通过答辩。旅游小程序这个选题，无论从学习价值还是实用性来看，都是非常划算的选择。希望这篇文章能帮你少走弯路，顺利毕业。