每年三四月份总有一批人被毕业设计折磨到怀疑人生。选题太简单怕过不了太难又怕做不完尤其是一听到“微信小程序”这种带着移动端和前后端分离双重Buff的题目很多同学的第一反应就是“这玩意儿我一个人能搞定吗”。但我带过的学生里凡是选了基于SpringBoot微信小程序这类题目的只要路子走对几乎是稳稳当当拿高分因为它的技术栈足够主流、业务场景足够清晰而且演示起来自带“看得见摸得着”的效果——老师在手机上扫码就能体验比对着网页点半天强太多了。这篇文章我以“基于SpringBoot微信小程序的新疆旅游系统”为完整案例把从选题拆解、技术选型、数据库设计、后端接口开发到小程序端落地、部署答辩这一整条链路掰开揉碎讲清楚。凡是正在做类似毕业设计、课程设计或者打算走旅游、文旅方向的实战新人这篇文章能帮你少走至少两个月的弯路。我要讲的不是教科书上的废话而是你真正打开IDE之后会遇到的那些事。1. 选题破局为什么“新疆旅游系统”是一个聪明的毕业设计很多同学听到这个题目第一反应是“这不就是个景点列表加个收藏功能吗有什么好做的”。如果你真的就这么交上去确实会挂因为评分老师看的不只是功能而是你“能不能把一个业务场景抽象成一套完整的信息系统”。1.1 这个项目到底在解决什么问题游客到新疆旅游最头疼的是什么不是景色不好看而是信息太分散。今天的朋友想去看天山天池明天的行程想去喀什古城住宿、车程、门票、开放时间、当地天气全靠一个个App来回切。传统旅游网站的信息往往是一刀切的通用内容到了新疆这种地域广阔、景点分散的地方用户需要的是“以景区为中心”的信息组织方式而不是“以旅行社为中心”的报价列表。所以你做的这个系统核心价值不是堆功能而是把“游客找信息”和“景区给人信息”之间的鸿沟填上。框架上天然需要两块管理端后台Web景区发布景区介绍、门票价格、开放状态、公告通知还可以处理游客预约订单。客户端微信小程序游客浏览景区、查看攻略、按分类筛选、收藏意向景点、在线预约行程、查看个人订单。这两端加起来才算一个“系统”而不是一个“页面”。这也是评审老师判断你有没有“系统设计能力”的分水岭——只会做一个移动端展示页的基本就是勉强及格水平能把预约流程和后台管理的状态联动做出来的才能稳拿高分。1.2 功能边界怎么划砍掉哪些才算合理我见过太多同学一上来就想着我要做地图导航、语音导览、实时天气、支付系统、用户社区评论。停你的时间是有限的。毕业设计的核心逻辑是“界定一个合理边界把这个边界内的事情做到位”。我建议第一版只保留四条主链路用户注册登录链路微信授权登录、手机号绑定、JWT会话维持。景区展示链路首页推荐位、景区列表按地区/分类筛选、景区详情图文、门票、开放时间、公告。预约链路选择日期、填写人数、提交预约单、后台审核或自动通过、查看订单状态。后台管理链路景区CRUD、公告发布、预约单查看与状态修改。支付功能我建议砍掉因为微信支付的商户资质申请对个人开发者来说流程繁琐而且如果你的毕设涉及金额交易答辩时的安全问题会非常不好绕。预约审核到“已确认”或者“待入园”就够了不需要真金白银流动。把边界划清楚以后你会发现这个项目的复杂度刚刚好同样能展示你“从数据库到接口到前端”的完整能力但不会因为业务逻辑过深把自己拖进泥潭。2. 技术选型定生死框架、数据库与接口方案的取舍技术选型这一步很多人是稀里糊涂开始的同学用啥我用啥。但选型背后其实是有逻辑的选定以后直接决定你后面两个月是顺畅还是到处踩坑。2.1 SpringBoot MyBatis-Plus 的搭配逻辑管理端我用的是SpringBoot 2.7.x MyBatis-Plus 3.5.x这是目前最主流也是毕设资料最多的组合。很多同学纠结“为什么不用SpringCloud”答案很简单你的系统根本不具备微服务拆分场景。单体应用在这个体量下开发效率最高部署最简单维护成本几乎为零。你硬上微服务反而显眼得像个没做过企业项目的实验室玩具。MyBatis-Plus的存在价值在于单表CRUD它帮你全自动生成你不需要大篇幅写XML。举个最实际的优势你写selectById、分页查询、条件构造器它全都内置了你只需要定义实体类和Mapper接口基础增删改查就全部可用了。这对毕业设计周期的同学来说极其友好。有个点需要注意MyBatis-Plus的字段自动填充功能MetaObjectHandler最好用上。比如createTime、updateTime这两个字段你每次插入和更新都要手动set一遍是真的烦配好填充处理器以后全项目统一自动维护省心不说代码也更干净。2.2 小程序端原生还是uni-app微信小程序端的开发框架我在这个项目里推荐用原生微信小程序框架。原因有三个毕业设计时间有限原生框架不用额外学Vue/编译链的概念微信开发者工具开箱即用。原生框架的组件和API调试起来路径最短预览、真机测试、上传体验版是一键链路。遇到问题搜索资料时原生案例可比uni-app多一个数量级。不是说uni-app不好它确实能一套代码多端复用但那个优势是用“多一层编译抽象”换来的。毕设场景下你只需要微信小程序这一个端没必要多引入一整套抽象层给自己增加变量。2.3 三条关键决策鉴权、文档、文件存储鉴权方案我用Token 拦截器 Redis可选。小程序端登录后拿到后端签发的token字符串每次请求在header里带上。后端用一个HandlerInterceptor统一校验白名单外的请求都检查token合法性。这套逻辑面试被问到也不会慌。接口文档写不写Swagger我的建议是接入knife4jSwagger的增强版UI因为答辩的时候“能看到在线接口文档”是非常直观的加分项老师一打开浏览器就能看到你所有的接口定义、参数说明、响应结构不用你费口舌解释。文件存储景区图片、公告图片最省心的是放在本地服务器静态目录写一个文件上传接口返回串拼接后的完整URL。如果学校有对象存储资源类似OSS的私有服务可以用没有也不用强求本地存储对这个体量完全够用。3. 数据库设计字段不规划好后面全是在改表数据库设计是这个系统里最见功力的环节也是我每次帮别人看毕设时最先检查的部分。好多同学前期不认真设计拍脑袋建几张表就开始写代码结果写着写着发现字段不够用了到处改表一个索引缺失还能逼死全站性能。3.1 核心表结构与字段说明这个项目第一版我建议至少设计8张表核心表如下表名核心字段说明userid, openid, nickname, avatar, phone, create_time游客用户信息openid唯一scenic_areaid, name, cover, images, category, region, description, price(ticket), opening_hours, status景区主表images建议JSON数组存多图categoryid, name, sort景区分类比如自然风光/人文古迹announcementid, title, content, create_time公告表做公告栏展示reservationid, user_id, scenic_id, reserve_date, people_count, contact_name, contact_phone, status, create_time预约单主表状态枚举待审核/已确认/已取消travel_noteid, user_id, title, content, images, create_time游记/攻略表可做用户产出内容的扩展这里我单独说一下images字段的处理。很多同学喜欢在数据库里单独建一个图片表来存景区多图逻辑上没错但在毕设里你等于给自己增加了一倍的联表工作量。我的做法是在scenic_area表直接加一个images字段类型varchar(1000)存JSON数组字符串查询的时候解析一下就行。这个方案在数据量不超过十万级别的场景下完全合理还省去了关联子表的复杂度。3.2 冗余字段与逻辑删除别小看这两点逻辑删除必做。scenic_area和reservation都加deleted字段0未删除/1已删除MyBatis-Plus里配上TableLogic注解删除操作就自动变成update了。这样哪怕你在演示中误删了数据还能保留记录答辩演示时多一重保险。冗余字段我在reservation表里冗余了scenic_name、cover这两个景区字段。从数据库三大范式的角度来说这不算规范但在实际业务里预约单列表页需要展示景区名称和封面如果不冗余就得每次查单再联表查景区信息。用一个很小的存储空间换一个干净的查询逻辑这是业务开发里非常常见且合理的取舍答辩老师也都认可“字段冗余换性能”这套说法。另外别忘给这些表加时间字段。create_time、update_time是标配你做列表排序、统计图表时都靠它们。4. 后端落地细节从登录鉴权到预约链路完整走通后端开发是重头戏也是代码量最大的部分。我不打算给你贴完整项目代码那纯属浪费时间我讲的是几条核心链路的思路和源码关键点把这些想明白代码就是水到渠成的事。4.1 微信小程序登录流程的三方会话问题登录这块是新手必卡的一个点。要知道微信小程序的登录不是传统意义上的“用户名密码登录”而是“静默获取用户身份标识”的流程。整个过程是这样的小程序端调用wx.login()拿到一个临时code。小程序把这个code发给你的后端接口比如/auth/login。后端拿着这个code调用微信的code2Session接口换取openid和session_key。后端拿着openid去你的user表查用户查不到就自动注册一个新用户这是第一种用户来源。生成一个自定义登录态比如JWT令牌返回给小程序端。这里有三个容易被忽略的点code只能用一次且有效期五分钟所以后端拿到code必须立刻调微信接口不要做任何中间缓存。不要在前端用openid当登录凭证因为小程序前端的数据是可以被伪造的一定要让后端来换取并签发自己的令牌。在控制台里把“未获取用户头像昵称”的旧能力停掉改用新版button open-typechooseAvatar和input typenickname组件获取用户信息这也是审核要求。4.2 景区查询与列表筛选的接口设计景区相关的接口是最基础的但基础不代表随便写。我给你的一个建议是列表接口一定用“分页条件查询”的组合不要写那种一把梭查全表的接口。路径示例GET /api/scenic/page?pageNum1pageSize10region喀什categoryId1keyword湖后端的Controller接收这些参数以后用MyBatis-Plus的LambdaQueryWrapper动态拼条件再套一个Page分页。有条件就过滤没条件就返回全部这就是动态查询的核心逻辑。这边要注意一个细节状态为“下架”status0的景区不能出现在游客端列表里。这个过滤条件要放在查询层统一处理不要漏掉否则你后台测试上传了一堆草稿景区小程序端全露出来了演示现场就不好看了。4.3 预约单的状态流转与并发防重预约模块是这个系统的业务中枢也是答辩时最可能被追问的地方。预约单的状态我设计了四个待确认、已确认、已取消、已完成。游客提交预约后进入“待确认”管理端在后台点“确认”状态变为“已确认”表示这个预约被接纳到期入园后手动或者在定时任务里变为“已完成”。这里有一个比较尖锐的问题同一个用户在同一个景区能不能重复提交同一日期的预约如果完全不限制那用户手滑多提交几个预约单管理端的待办列表里就会堆出一堆垃圾数据打回重做包括哪些方面所以后端在接收预约提交时先做一个幂等检查按user_idscenic_idreserve_date 状态必须是“待确认或已确认”这三个条件查一条已经存在就直接返回“您已预约过该日期的行程”。为了保证并发安全在插入之前也用这条查询做防重虽然极端并发下两个请求可能同时通过但那需要一瞬间发出两个相同请求在小体量的毕设系统里这一层已经足够防御绝大多数手误操作。真要做到极致你可以在表上建一个联合唯一索引彻底从数据库层封死重复。这个思路一提出来评委就知道你考虑过并发问题。5. 小程序端从零到能演示页面骨架与组件避坑小程序端是最容易出视觉效果的地方也是最容易藏坑的地方。很多后端写得很稳的同学到了小程序端反而被各种细节卡住我挑几条最关键的路给你指清楚。5.1 页面结构怎么划分最合理我的建议是底部TabBar四个页面首页index顶部搜索框 Banner轮播位 分类快捷入口 推荐景区列表景区列表页scenic/list条件筛选栏按地区、按分类 景区卡片列表 触底分页加载预约记录页order/list用户的预约单列表每个卡片显示景区名、日期、人数、状态个人中心页mine用户头像昵称、我的收藏、关于系统这个页面划分是有讲究的首页承担“逛”列表页承担“筛”预约页承担“查”个人页承担“我的数据”。功能入口既不重不漏又能在演示时用最短的路径展示核心闭环。5.2 微信小程序地图组件与定位权限的坑新疆旅游系统天然绕不开一个东西地图。你肯定想在小程序里放一个景区位置展示。实现方式很简单在景区详情页放一个map组件latitude和longitude从后端景区表里读出来标记点用markers数组。再给地图组件加一个“跳转导航”按钮调用wx.openLocation用户就能直接拉起微信内置地图导航到景区了。这里有个大坑是权限问题。很多同学写完地图之后真机一预览发现地图上全是空白网格控制台报个getLocation:fail the api need to be declared in the requiredPrivateInfos field in app.json。这不是代码问题是你在app.json里没声明requiredPrivateInfos字段。具体的做法是在app.json里加一段{ requiredPrivateInfos: [ getLocation, chooseLocation ] }然后在manifest.json如果你用的是原生就是app.json和微信公众平台后台的“开发管理-接口设置”里同时申请开通wx.getLocation这个接口的权限。很多新人对这一步完全没概念代码写好了权限没开就卡在原地半天。这个我当年也踩过现在直接给大家提前知会了。5.3 让答辩观众眼前一亮的三个交互细节骨架屏列表页用微信自带的skeleton效果或自己用CSS简单模拟一个灰块占位加载数据时先显示骨架屏加载完再显示真实内容。让页面看起来“高级”不少。下拉刷新和触底加载首页和列表页都加上。下拉刷新调接口refresh触底加载下一页用onReachBottom事件。这两个交互是移动端产品的标配做了以后答辩老师会觉得这个系统“像个正经产品”。空状态设计预约记录为空时不要让页面白花花一片放一个插图和“你还没有预约记录快去逛逛景点吧”的提示。不要小看这种细节体验的差距就是在这些地方体现出来的。6. 部署上线从本地跑通到公网可访问毕业设计到了5月份很多人的状态是“代码写完了但只在本地能跑”。然后答辩那天开个热点打开localhost给老师看——这倒也能演示但观感真的差一大截。你能让老师用自己的手机打开小程序看到你的系统真实运行在公网上这本身就是一个印象分拉满的操作。6.1 服务器、域名与HTTPS的三件套小程序有一个硬性的规则正式上线发布版本时所有请求的域名必须是HTTPS且已在后台配置。这个问题有两种解决路径路径一省心用微信云开发的云托管。云托管可以直接托管你的SpringBoot后端和数据库自带域名和HTTPS不需要你自己配SSL证书。缺点是云托管按量计费毕设期间注意控制流量。路径二传统自己买一台云服务器2核4G装好JDK、MySQL、Redis把项目打成jar包用nohup java -jar启动。再买一个域名用Nginx做反向代理配置免费的SSL证书比如Lets Encrypt然后在微信公众平台的后台把域名配置到request合法域名里。关于路径二我必须提醒一个很隐蔽的坑你在微信公众平台后台配置的域名必须要把根域名也写上比如配置了https://api.example.com那example.com根域名也要配置否则部分机型上可能出现请求失败。另外注意ssl证书要选“证书类型为TLS”不要选成那种仅用于邮件服的奇怪证书。6.2 常见部署报错与解决思路我每年帮人排查的部署问题无非这几类报错现象原因解决方案小程序请求tunnel报404请求不通后端服务未启动或端口没开检查 ps -ef后端日志报“连接数据库失败”服务器的数据库账号权限没配好给新账号授予远程连接权限GRANT ALL PRIVILEGES ON静态图片请求404SpringBoot静态资源配置漏了上传路径映射配置一个addResourceHandlers把本地目录映射到/files/**路径小程序请求提示“域名不在合法域名列表中”后台config未配置或未生效配置后记得保存并关闭开发者工具的“不校验合法域名”开关单独测试这里的核心心态是部署不是玄学报错一定要看日志。tail -f nohup.out是毕设期间最常用的命令没有之一。定位不了问题就逐层排查先确认服务在跑、再确认端口开放、再确认数据库通、最后确认域名证书和后台配置一层层往下走。7. 答辩前必须做的三件事数据、演示脚本、扩展点代码写完了、部署上线了不代表万事大吉。答辩这件事很多同学挂掉不是因为项目不行而是因为不会“展示”。我从过来人的角度给你列三件扎实的准备。7.1 数据准备让系统看起来像个“运行了几年的产品”新系统最致命的破绽就是“数据为空界面空空”。你打开首页后只有一条测试景点、零个预约单老师一眼就看穿这是个刚搭好的demo。建议做以下数据填充至少录入20个景区数据覆盖新疆的主要旅游地区天山天池、喀纳斯、那拉提草原、喀什古城等每个景区都要有真实的简介、门票价格、开放时间、3张以上清晰的封面图。至少3条公告内容用真实的旅游提示比如“旺季预约提醒”“区间车运营时间调整”让公告栏不空。预约单要有不同状态的数据至少各来2条“待确认”“已确认”“已完成”让管理端列表页展示效果饱满。7.2 设计一条30秒的演示主链路答辩时你大概率只有五到八分钟的项目演示时间你要准备好的不是“把所有页面逛一遍”而是“设计一条能讲故事的演示路径”。我用的故事线是打开小程序首页展示“新疆旅游”的Banner轮播和推荐景区列表一句话介绍系统定位。点击进入喀什古城的详情页展示图文介绍、门票信息、开放时间点击“立即预约”。选择日期和人数提交预约演示预约成功后跳转到预约记录页看到“待确认”状态。切换到管理端后台找到这条预约单把状态改为“已确认”。切回小程序刷新预约记录页面状态已变成“已确认”。这条链路完整展示了“用户端-后端-管理端”三端的数据联动正好把整个系统的闭环逻辑讲完了。而且每一步都是“实物表演”不需要画饼。7.3 能加的扩展点给“预期功能”留一手答辩最常被问的一句话是“你这个系统还能加什么功能”。这个问题问出来不是要难为你而是想看看你有没有“产品思维”。我的建议是准备好两个真实可落地的扩展方向基于协同过滤的景区推荐用户在收藏和预约的景区数据累计以后可以按地区或分类维度算一个“和你喜欢相似的景区”的推荐列表逻辑不难但一说出来就显高级。PDF行程单生成后端在确认预约后生成一份PDF行程单供用户下载/查看用于入园核验或旅游备案。这个用Java的itext或POI就能实现代码量大概三天但功能却超级显眼。这两个扩展点属于“方向明确工作量可控”的范畴真要做可以不做也能作为“我接下来的计划”来谈。答辩老师问起来你胸有成竹地讲出实现思路比支支吾吾说“还没想好”要强出十倍。最后再分享一个我踩过三次的坑用Git做版本管理时别把target/目录、node_modules/、上传的图片文件夹整个丢进去。提交代码前一定要配好.gitignore不然你的仓库会越来越臃肿而且一旦不小心提交了包含着旧密码的配置文件再推上去后期清理起来会异常痛苦。就这一条你后面就能少掉不少头发。
每年三四月份总有一批人被毕业设计折磨到怀疑人生。选题太简单怕过不了太难又怕做不完尤其是一听到“微信小程序”这种带着移动端和前后端分离双重Buff的题目很多同学的第一反应就是“这玩意儿我一个人能搞定吗”。但我带过的学生里凡是选了基于SpringBoot微信小程序这类题目的只要路子走对几乎是稳稳当当拿高分因为它的技术栈足够主流、业务场景足够清晰而且演示起来自带“看得见摸得着”的效果——老师在手机上扫码就能体验比对着网页点半天强太多了。这篇文章我以“基于SpringBoot微信小程序的新疆旅游系统”为完整案例把从选题拆解、技术选型、数据库设计、后端接口开发到小程序端落地、部署答辩这一整条链路掰开揉碎讲清楚。凡是正在做类似毕业设计、课程设计或者打算走旅游、文旅方向的实战新人这篇文章能帮你少走至少两个月的弯路。我要讲的不是教科书上的废话而是你真正打开IDE之后会遇到的那些事。1. 选题破局为什么“新疆旅游系统”是一个聪明的毕业设计很多同学听到这个题目第一反应是“这不就是个景点列表加个收藏功能吗有什么好做的”。如果你真的就这么交上去确实会挂因为评分老师看的不只是功能而是你“能不能把一个业务场景抽象成一套完整的信息系统”。1.1 这个项目到底在解决什么问题游客到新疆旅游最头疼的是什么不是景色不好看而是信息太分散。今天的朋友想去看天山天池明天的行程想去喀什古城住宿、车程、门票、开放时间、当地天气全靠一个个App来回切。传统旅游网站的信息往往是一刀切的通用内容到了新疆这种地域广阔、景点分散的地方用户需要的是“以景区为中心”的信息组织方式而不是“以旅行社为中心”的报价列表。所以你做的这个系统核心价值不是堆功能而是把“游客找信息”和“景区给人信息”之间的鸿沟填上。框架上天然需要两块管理端后台Web景区发布景区介绍、门票价格、开放状态、公告通知还可以处理游客预约订单。客户端微信小程序游客浏览景区、查看攻略、按分类筛选、收藏意向景点、在线预约行程、查看个人订单。这两端加起来才算一个“系统”而不是一个“页面”。这也是评审老师判断你有没有“系统设计能力”的分水岭——只会做一个移动端展示页的基本就是勉强及格水平能把预约流程和后台管理的状态联动做出来的才能稳拿高分。1.2 功能边界怎么划砍掉哪些才算合理我见过太多同学一上来就想着我要做地图导航、语音导览、实时天气、支付系统、用户社区评论。停你的时间是有限的。毕业设计的核心逻辑是“界定一个合理边界把这个边界内的事情做到位”。我建议第一版只保留四条主链路用户注册登录链路微信授权登录、手机号绑定、JWT会话维持。景区展示链路首页推荐位、景区列表按地区/分类筛选、景区详情图文、门票、开放时间、公告。预约链路选择日期、填写人数、提交预约单、后台审核或自动通过、查看订单状态。后台管理链路景区CRUD、公告发布、预约单查看与状态修改。支付功能我建议砍掉因为微信支付的商户资质申请对个人开发者来说流程繁琐而且如果你的毕设涉及金额交易答辩时的安全问题会非常不好绕。预约审核到“已确认”或者“待入园”就够了不需要真金白银流动。把边界划清楚以后你会发现这个项目的复杂度刚刚好同样能展示你“从数据库到接口到前端”的完整能力但不会因为业务逻辑过深把自己拖进泥潭。2. 技术选型定生死框架、数据库与接口方案的取舍技术选型这一步很多人是稀里糊涂开始的同学用啥我用啥。但选型背后其实是有逻辑的选定以后直接决定你后面两个月是顺畅还是到处踩坑。2.1 SpringBoot MyBatis-Plus 的搭配逻辑管理端我用的是SpringBoot 2.7.x MyBatis-Plus 3.5.x这是目前最主流也是毕设资料最多的组合。很多同学纠结“为什么不用SpringCloud”答案很简单你的系统根本不具备微服务拆分场景。单体应用在这个体量下开发效率最高部署最简单维护成本几乎为零。你硬上微服务反而显眼得像个没做过企业项目的实验室玩具。MyBatis-Plus的存在价值在于单表CRUD它帮你全自动生成你不需要大篇幅写XML。举个最实际的优势你写selectById、分页查询、条件构造器它全都内置了你只需要定义实体类和Mapper接口基础增删改查就全部可用了。这对毕业设计周期的同学来说极其友好。有个点需要注意MyBatis-Plus的字段自动填充功能MetaObjectHandler最好用上。比如createTime、updateTime这两个字段你每次插入和更新都要手动set一遍是真的烦配好填充处理器以后全项目统一自动维护省心不说代码也更干净。2.2 小程序端原生还是uni-app微信小程序端的开发框架我在这个项目里推荐用原生微信小程序框架。原因有三个毕业设计时间有限原生框架不用额外学Vue/编译链的概念微信开发者工具开箱即用。原生框架的组件和API调试起来路径最短预览、真机测试、上传体验版是一键链路。遇到问题搜索资料时原生案例可比uni-app多一个数量级。不是说uni-app不好它确实能一套代码多端复用但那个优势是用“多一层编译抽象”换来的。毕设场景下你只需要微信小程序这一个端没必要多引入一整套抽象层给自己增加变量。2.3 三条关键决策鉴权、文档、文件存储鉴权方案我用Token 拦截器 Redis可选。小程序端登录后拿到后端签发的token字符串每次请求在header里带上。后端用一个HandlerInterceptor统一校验白名单外的请求都检查token合法性。这套逻辑面试被问到也不会慌。接口文档写不写Swagger我的建议是接入knife4jSwagger的增强版UI因为答辩的时候“能看到在线接口文档”是非常直观的加分项老师一打开浏览器就能看到你所有的接口定义、参数说明、响应结构不用你费口舌解释。文件存储景区图片、公告图片最省心的是放在本地服务器静态目录写一个文件上传接口返回串拼接后的完整URL。如果学校有对象存储资源类似OSS的私有服务可以用没有也不用强求本地存储对这个体量完全够用。3. 数据库设计字段不规划好后面全是在改表数据库设计是这个系统里最见功力的环节也是我每次帮别人看毕设时最先检查的部分。好多同学前期不认真设计拍脑袋建几张表就开始写代码结果写着写着发现字段不够用了到处改表一个索引缺失还能逼死全站性能。3.1 核心表结构与字段说明这个项目第一版我建议至少设计8张表核心表如下表名核心字段说明userid, openid, nickname, avatar, phone, create_time游客用户信息openid唯一scenic_areaid, name, cover, images, category, region, description, price(ticket), opening_hours, status景区主表images建议JSON数组存多图categoryid, name, sort景区分类比如自然风光/人文古迹announcementid, title, content, create_time公告表做公告栏展示reservationid, user_id, scenic_id, reserve_date, people_count, contact_name, contact_phone, status, create_time预约单主表状态枚举待审核/已确认/已取消travel_noteid, user_id, title, content, images, create_time游记/攻略表可做用户产出内容的扩展这里我单独说一下images字段的处理。很多同学喜欢在数据库里单独建一个图片表来存景区多图逻辑上没错但在毕设里你等于给自己增加了一倍的联表工作量。我的做法是在scenic_area表直接加一个images字段类型varchar(1000)存JSON数组字符串查询的时候解析一下就行。这个方案在数据量不超过十万级别的场景下完全合理还省去了关联子表的复杂度。3.2 冗余字段与逻辑删除别小看这两点逻辑删除必做。scenic_area和reservation都加deleted字段0未删除/1已删除MyBatis-Plus里配上TableLogic注解删除操作就自动变成update了。这样哪怕你在演示中误删了数据还能保留记录答辩演示时多一重保险。冗余字段我在reservation表里冗余了scenic_name、cover这两个景区字段。从数据库三大范式的角度来说这不算规范但在实际业务里预约单列表页需要展示景区名称和封面如果不冗余就得每次查单再联表查景区信息。用一个很小的存储空间换一个干净的查询逻辑这是业务开发里非常常见且合理的取舍答辩老师也都认可“字段冗余换性能”这套说法。另外别忘给这些表加时间字段。create_time、update_time是标配你做列表排序、统计图表时都靠它们。4. 后端落地细节从登录鉴权到预约链路完整走通后端开发是重头戏也是代码量最大的部分。我不打算给你贴完整项目代码那纯属浪费时间我讲的是几条核心链路的思路和源码关键点把这些想明白代码就是水到渠成的事。4.1 微信小程序登录流程的三方会话问题登录这块是新手必卡的一个点。要知道微信小程序的登录不是传统意义上的“用户名密码登录”而是“静默获取用户身份标识”的流程。整个过程是这样的小程序端调用wx.login()拿到一个临时code。小程序把这个code发给你的后端接口比如/auth/login。后端拿着这个code调用微信的code2Session接口换取openid和session_key。后端拿着openid去你的user表查用户查不到就自动注册一个新用户这是第一种用户来源。生成一个自定义登录态比如JWT令牌返回给小程序端。这里有三个容易被忽略的点code只能用一次且有效期五分钟所以后端拿到code必须立刻调微信接口不要做任何中间缓存。不要在前端用openid当登录凭证因为小程序前端的数据是可以被伪造的一定要让后端来换取并签发自己的令牌。在控制台里把“未获取用户头像昵称”的旧能力停掉改用新版button open-typechooseAvatar和input typenickname组件获取用户信息这也是审核要求。4.2 景区查询与列表筛选的接口设计景区相关的接口是最基础的但基础不代表随便写。我给你的一个建议是列表接口一定用“分页条件查询”的组合不要写那种一把梭查全表的接口。路径示例GET /api/scenic/page?pageNum1pageSize10region喀什categoryId1keyword湖后端的Controller接收这些参数以后用MyBatis-Plus的LambdaQueryWrapper动态拼条件再套一个Page分页。有条件就过滤没条件就返回全部这就是动态查询的核心逻辑。这边要注意一个细节状态为“下架”status0的景区不能出现在游客端列表里。这个过滤条件要放在查询层统一处理不要漏掉否则你后台测试上传了一堆草稿景区小程序端全露出来了演示现场就不好看了。4.3 预约单的状态流转与并发防重预约模块是这个系统的业务中枢也是答辩时最可能被追问的地方。预约单的状态我设计了四个待确认、已确认、已取消、已完成。游客提交预约后进入“待确认”管理端在后台点“确认”状态变为“已确认”表示这个预约被接纳到期入园后手动或者在定时任务里变为“已完成”。这里有一个比较尖锐的问题同一个用户在同一个景区能不能重复提交同一日期的预约如果完全不限制那用户手滑多提交几个预约单管理端的待办列表里就会堆出一堆垃圾数据打回重做包括哪些方面所以后端在接收预约提交时先做一个幂等检查按user_idscenic_idreserve_date 状态必须是“待确认或已确认”这三个条件查一条已经存在就直接返回“您已预约过该日期的行程”。为了保证并发安全在插入之前也用这条查询做防重虽然极端并发下两个请求可能同时通过但那需要一瞬间发出两个相同请求在小体量的毕设系统里这一层已经足够防御绝大多数手误操作。真要做到极致你可以在表上建一个联合唯一索引彻底从数据库层封死重复。这个思路一提出来评委就知道你考虑过并发问题。5. 小程序端从零到能演示页面骨架与组件避坑小程序端是最容易出视觉效果的地方也是最容易藏坑的地方。很多后端写得很稳的同学到了小程序端反而被各种细节卡住我挑几条最关键的路给你指清楚。5.1 页面结构怎么划分最合理我的建议是底部TabBar四个页面首页index顶部搜索框 Banner轮播位 分类快捷入口 推荐景区列表景区列表页scenic/list条件筛选栏按地区、按分类 景区卡片列表 触底分页加载预约记录页order/list用户的预约单列表每个卡片显示景区名、日期、人数、状态个人中心页mine用户头像昵称、我的收藏、关于系统这个页面划分是有讲究的首页承担“逛”列表页承担“筛”预约页承担“查”个人页承担“我的数据”。功能入口既不重不漏又能在演示时用最短的路径展示核心闭环。5.2 微信小程序地图组件与定位权限的坑新疆旅游系统天然绕不开一个东西地图。你肯定想在小程序里放一个景区位置展示。实现方式很简单在景区详情页放一个map组件latitude和longitude从后端景区表里读出来标记点用markers数组。再给地图组件加一个“跳转导航”按钮调用wx.openLocation用户就能直接拉起微信内置地图导航到景区了。这里有个大坑是权限问题。很多同学写完地图之后真机一预览发现地图上全是空白网格控制台报个getLocation:fail the api need to be declared in the requiredPrivateInfos field in app.json。这不是代码问题是你在app.json里没声明requiredPrivateInfos字段。具体的做法是在app.json里加一段{ requiredPrivateInfos: [ getLocation, chooseLocation ] }然后在manifest.json如果你用的是原生就是app.json和微信公众平台后台的“开发管理-接口设置”里同时申请开通wx.getLocation这个接口的权限。很多新人对这一步完全没概念代码写好了权限没开就卡在原地半天。这个我当年也踩过现在直接给大家提前知会了。5.3 让答辩观众眼前一亮的三个交互细节骨架屏列表页用微信自带的skeleton效果或自己用CSS简单模拟一个灰块占位加载数据时先显示骨架屏加载完再显示真实内容。让页面看起来“高级”不少。下拉刷新和触底加载首页和列表页都加上。下拉刷新调接口refresh触底加载下一页用onReachBottom事件。这两个交互是移动端产品的标配做了以后答辩老师会觉得这个系统“像个正经产品”。空状态设计预约记录为空时不要让页面白花花一片放一个插图和“你还没有预约记录快去逛逛景点吧”的提示。不要小看这种细节体验的差距就是在这些地方体现出来的。6. 部署上线从本地跑通到公网可访问毕业设计到了5月份很多人的状态是“代码写完了但只在本地能跑”。然后答辩那天开个热点打开localhost给老师看——这倒也能演示但观感真的差一大截。你能让老师用自己的手机打开小程序看到你的系统真实运行在公网上这本身就是一个印象分拉满的操作。6.1 服务器、域名与HTTPS的三件套小程序有一个硬性的规则正式上线发布版本时所有请求的域名必须是HTTPS且已在后台配置。这个问题有两种解决路径路径一省心用微信云开发的云托管。云托管可以直接托管你的SpringBoot后端和数据库自带域名和HTTPS不需要你自己配SSL证书。缺点是云托管按量计费毕设期间注意控制流量。路径二传统自己买一台云服务器2核4G装好JDK、MySQL、Redis把项目打成jar包用nohup java -jar启动。再买一个域名用Nginx做反向代理配置免费的SSL证书比如Lets Encrypt然后在微信公众平台的后台把域名配置到request合法域名里。关于路径二我必须提醒一个很隐蔽的坑你在微信公众平台后台配置的域名必须要把根域名也写上比如配置了https://api.example.com那example.com根域名也要配置否则部分机型上可能出现请求失败。另外注意ssl证书要选“证书类型为TLS”不要选成那种仅用于邮件服的奇怪证书。6.2 常见部署报错与解决思路我每年帮人排查的部署问题无非这几类报错现象原因解决方案小程序请求tunnel报404请求不通后端服务未启动或端口没开检查 ps -ef后端日志报“连接数据库失败”服务器的数据库账号权限没配好给新账号授予远程连接权限GRANT ALL PRIVILEGES ON静态图片请求404SpringBoot静态资源配置漏了上传路径映射配置一个addResourceHandlers把本地目录映射到/files/**路径小程序请求提示“域名不在合法域名列表中”后台config未配置或未生效配置后记得保存并关闭开发者工具的“不校验合法域名”开关单独测试这里的核心心态是部署不是玄学报错一定要看日志。tail -f nohup.out是毕设期间最常用的命令没有之一。定位不了问题就逐层排查先确认服务在跑、再确认端口开放、再确认数据库通、最后确认域名证书和后台配置一层层往下走。7. 答辩前必须做的三件事数据、演示脚本、扩展点代码写完了、部署上线了不代表万事大吉。答辩这件事很多同学挂掉不是因为项目不行而是因为不会“展示”。我从过来人的角度给你列三件扎实的准备。7.1 数据准备让系统看起来像个“运行了几年的产品”新系统最致命的破绽就是“数据为空界面空空”。你打开首页后只有一条测试景点、零个预约单老师一眼就看穿这是个刚搭好的demo。建议做以下数据填充至少录入20个景区数据覆盖新疆的主要旅游地区天山天池、喀纳斯、那拉提草原、喀什古城等每个景区都要有真实的简介、门票价格、开放时间、3张以上清晰的封面图。至少3条公告内容用真实的旅游提示比如“旺季预约提醒”“区间车运营时间调整”让公告栏不空。预约单要有不同状态的数据至少各来2条“待确认”“已确认”“已完成”让管理端列表页展示效果饱满。7.2 设计一条30秒的演示主链路答辩时你大概率只有五到八分钟的项目演示时间你要准备好的不是“把所有页面逛一遍”而是“设计一条能讲故事的演示路径”。我用的故事线是打开小程序首页展示“新疆旅游”的Banner轮播和推荐景区列表一句话介绍系统定位。点击进入喀什古城的详情页展示图文介绍、门票信息、开放时间点击“立即预约”。选择日期和人数提交预约演示预约成功后跳转到预约记录页看到“待确认”状态。切换到管理端后台找到这条预约单把状态改为“已确认”。切回小程序刷新预约记录页面状态已变成“已确认”。这条链路完整展示了“用户端-后端-管理端”三端的数据联动正好把整个系统的闭环逻辑讲完了。而且每一步都是“实物表演”不需要画饼。7.3 能加的扩展点给“预期功能”留一手答辩最常被问的一句话是“你这个系统还能加什么功能”。这个问题问出来不是要难为你而是想看看你有没有“产品思维”。我的建议是准备好两个真实可落地的扩展方向基于协同过滤的景区推荐用户在收藏和预约的景区数据累计以后可以按地区或分类维度算一个“和你喜欢相似的景区”的推荐列表逻辑不难但一说出来就显高级。PDF行程单生成后端在确认预约后生成一份PDF行程单供用户下载/查看用于入园核验或旅游备案。这个用Java的itext或POI就能实现代码量大概三天但功能却超级显眼。这两个扩展点属于“方向明确工作量可控”的范畴真要做可以不做也能作为“我接下来的计划”来谈。答辩老师问起来你胸有成竹地讲出实现思路比支支吾吾说“还没想好”要强出十倍。最后再分享一个我踩过三次的坑用Git做版本管理时别把target/目录、node_modules/、上传的图片文件夹整个丢进去。提交代码前一定要配好.gitignore不然你的仓库会越来越臃肿而且一旦不小心提交了包含着旧密码的配置文件再推上去后期清理起来会异常痛苦。就这一条你后面就能少掉不少头发。
![打卡信奥刷题（3644）用C++实现信奥题 P12027 [USACO25OPEN] Ski Slope S](http://pic.xiahunao.cn/yaotu/打卡信奥刷题（3644）用C++实现信奥题 P12027 [USACO25OPEN] Ski Slope S)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
