1. 项目核心拆解：标题背后到底在做什么
1.1 这个项目真实的用户需求与交付目标
很多人拿到这类标题，第一反应是“又是毕设模板”。但说实话，我经手过不少类似的乡村游、景区预约、民宿管理类项目，这类“微信小程序+管理系统”的组合，在南宁以及整个广西的文旅市场里确实有真实的落地场景。
先说清楚标题里的三个关键词怎么理解。微信小程序是面向游客的轻量入口，用户不需要下载App，扫码即用，用完即走，这非常贴合乡村旅游“低频、临时、碎片化”的使用习惯。管理系统对应的是运营方后台，负责管理乡村景点信息、民宿房态、订单数据、用户反馈，本质上就是一套典型的业务管理系统。项目源码+论文说明这两个补充词，直白地告诉了我们这套东西是给谁用的——需要完成毕业设计的学生、需要交付完整工程的项目组，以及想快速搭建一套乡村游平台的中小团队。
所以这个项目的核心价值不是做一个炫酷的App，而是把“游客端小程序”和“运营端管理后台”打通，形成信息流和业务流的闭环。游客在小程序里浏览南宁周边的特色乡村、查看景点详情、预订民宿、生成游玩路线；运营方在后台维护内容、处理订单、查看经营数据。一个人数不多的小团队，就能靠这套系统把乡村文旅资源管起来。
1.2 技术栈选型：为什么偏偏是这些组合
微信小程序是个大方向，但落地时第一道选择题是：用原生小程序，还是用uni-app之类的跨端框架？我的结论很明确——如果只针对微信小程序一个平台，就用原生。
原生小程序开发框架的好处有几个。第一，工具链成熟稳定，微信开发者工具开箱即用，模拟器、真机调试、性能面板都是现成的，不用额外折腾。第二，组件和API跟微信平台深度绑定，比如wx.login、wx.request、wx.chooseImage这些接口，原生环境里就是最直接、无中间层的调用方式。第三，打包体积好控制，原生小程序没有框架转换的冗余代码，启动速度更快。我见过不少用uni-app写的小程序，明明只是面向微信一个平台，却背着整个跨端框架的包袱，得不偿失。当然，如果以后明确要同时出支付宝小程序、抖音小程序，那再上uni-app不迟，这是后话。
后端这块，我推荐过无数次的组合是Spring Boot + MyBatis Plus + MySQL 8.0，这套组合在高校里几乎快成“标准答案”了，不是没有道理。Spring Boot让Java后端起步快得离谱，一个Application类就能把Web服务跑起来；MyBatis Plus基本把单表增删改查包圆了，写代码的时间能省掉四分之一；MySQL对于这种体量的业务系统完全没压力，还方便导师看懂。有的同学想用Python写后端，Flask或者Django确实可以，但说实话，从论文可写性和后续就业方向考虑，Java后端的优势还是更明显，这也是我比较务实的一个建议。
管理系统后台我用的是vue3 + Element Plus + Vite。Vue3的组合式API写起来比Vue2更清爽，Element Plus组件库在后台界面这块覆盖了大部分场景，表格、表单、弹窗、卡片，看着就规整。Vite的启动速度我从Webpack时代过来的老同志真的感动到想鼓掌，几秒钟的热更新，效率根本不是一回事。
2. 系统功能设计与数据库建模思路
2.1 功能模块划分：游客端与运营端的边界
做这类项目最忌讳什么事情？一上来就堆功能。很多课设项目做出来功能表能写一整页，但真正跑起来全是半成品。我的做法是先划清边界，把角色、场景、需求理清楚，再做功能收敛。
游客端小程序，我拆成五个核心模块。
乡村导览模块是门面，收录南宁周边的特色乡村、景点、采摘园、农家乐等资源，以卡片列表展示，支持根据区域、标签、评分筛选，游客点进去可以看到详细介绍、实拍图、开放时间、联系电话和地图定位。民宿预订模块是最有含金量的业务闭环，游客浏览民宿列表，查看房型和价格日历，选择日期后提交预订订单，订单状态从待支付、已支付、已入住到已完成，整条链路要在小程序和后台之间同步。游玩路线推荐模块解决的是“怎么玩”的需求，后台运营人员可以配置一日游、两日游等主题路线，比如“上林大明山+鼓鸣寨一日游”、“武鸣伊岭岩+花花大世界周末游”，每条路线串起多个景点。农特产商城模块是把流量变现的手段，南宁周边的沃柑、火龙果、百香果、茉莉花茶都是很好的卖点，游客可以直接下单购买农特产品，后台处理订单和物流信息。个人中心模块管用户的是注册登录、订单列表、收藏夹、浏览历史和意见反馈。
运营端管理后台是给真正的管理者用的，模块划分要更干练一些。内容管理负责维护乡村、景点、民宿、商品、路线等所有内容资源，配置是否上架、排序权重、推荐位。订单管理是一个聚合视图，订单列表可以按状态、时间段、渠道筛选，对异常订单可以取消操作并触发退款流程。用户管理管会员信息、消费记录和账号状态，必要的时候可以直接禁用恶意用户。数据看板展示核心经营指标，今日订单数、本月交易额、热门乡村Top10、新增用户趋势，用图表呈现。系统设置收尾，管理管理员账号、角色权限、操作日志。
2.2 数据表设计：十一张表是怎么串起来的
数据库设计是论文里必须要展出的重头戏，也是系统能跑通的关键。这块我花了最多时间打磨，因为表结构一旦设计不合理，后面写代码的时候全是坑。这个项目我最终定了十一张核心表，我来逐个拆一下设计要点。
**管理员表(admin)**是后台的“看门人”，字段包括主键id、登录账号、密码（BCrypt加密存储）、昵称、角色、状态、创建时间。角色字段建议直接配一个，超级管理员和普通运营人员区分开，不是硬需要权限系统才做，而是让论文有东西可写，让答辩老师知道你有这个意识。
**用户表(user)**对应游客端的小程序用户，除了openid、昵称、头像、手机号这些基本信息，我额外加了性别、年龄、常居地几个字段。为什么加这些？因为后面数据看板和分析模块需要用户画像的支撑，哪怕只是统计一下年龄段分布，也比只存个openid强。整合注册时间和最近登录时间，还能看出用户的活跃情况。
**乡村信息表(village)**是整个系统的内容基石，字段比较多：乡村名称、所在区县、详细地址、经度和纬度、封面图、简介、特色标签、联系电话、开放时间、评分、浏览量、状态。经纬度字段要重点说，这是地图定位和路线规划的基础。推荐位标识可以存一个排序值，后台把想置顶的乡村排序值调小，列表自然就排在前面了。
景点表(attraction)和乡村表是多对一的关系，通过village_id关联。一个乡村下有多个景点是很正常的，比如一个村有自己的古建筑、果园采摘区和一个登山步道，这都要在数据库层面体现出来。景点表里同样要存经纬度，因为小程序里的地图标记点是根据经纬度渲染的。
民宿表(homestay)、房型表(room_type)、**订单表(order)**这三张表是一组业务铁三角。民宿表管基本信息，房型表通过homestay_id关联，存房型名称、面积、床型、可住人数、挂牌价、今日价、库存、封面图。订单表是这个系统的核心表，字段非常关键：订单号、用户id、民宿id、房型id、入住日期、离店日期、晚数、单价、总金额、下单时间、支付时间、状态、备注。尤其要说明的是，订单表里我没有直接存“房型名称”，而是通过房型id关联查询，这样房价调整了历史订单也不受影响。
商品表(product)和订单表之间，我建议单独做一张订单商品表(order_item)，做成经典的主从表结构。这是什么意思呢？一单可以买多件商品，每个商品在order_item里占一条记录，商品id、商品名称快照、单价快照、数量、小计金额都在里面。这里有个很重要的设计点，我在商品字段之外还冗余存了一份商品名称和单价快照，为什么？因为商品名称和价格是可以被后台修改的，如果订单建立后商品被删了，订单还能依据快照完成，避免关联不存在的东西。
最后是路线表(route)、路线景点关联表(route_attraction)和评价表(comment)。路线表和景点表是多对多关系，所以需要一张关联表存路线id和景点id以及顺序值。评价表关联用户、乡村或民宿，存评分和内容，评分字段我用整数1-5，简单好处理，不搞花里胡哨的星星半星逻辑。
这套设计的核心思路就一句话：每个业务实体都有自己的表，实体之间的关系用关联字段和关联表表达，关键业务节点做数据快照。跟在数据库课程里学的范式理论完全吻合，在论文里画ER图也顺理成章。
2.3 后端API设计：Restful接口怎么划分
后端接口设计是整个系统的骨架。这块要提前规划好，不然前端小程序这边一会儿用POST一会儿用GET，对接的时候就是灾难现场。
我按业务模块把接口拆分如下：用户模块包含登录接口、用户信息查询与修改接口。乡村模块包含分页查询、搜索筛选、详情查询、热门乡村排行。景点模块的接口跟乡村模块类似，多一个按乡村查询的接口，小程序端进入乡村详情页时，要一次性把该乡村的所有景点拉出来。民宿模块是核心接口组，包含列表查询、详情查询、房型查询、价格日历查询、提交预订。价格日历查询这个接口是我后来补上的，小程序端需要一个接口返回指定民宿在最近三十天每天的可用房量和价格，这样可以做成日历视图，用户一眼看出哪天有空房。商品模块包含商品列表接口和商品详情接口，对应的下单接口和我的订单列表、订单详情接口放在一起。路线模块包含路线列表和路线详情接口，详情里要返回完整路线的每个节点，包括每个景点的名称、图片、位置、推荐游玩时长。后台管理模块就多很多了，乡村管理、景点管理、民宿管理、商品管理、订单管理、用户管理、数据统计，各自有分页查询、新增、修改、删除、上下架的成套接口，这部分我统一用通用REST风格，路径清晰、返回结构一致。
接口返回结构我统一规定为{ code, message, data }格式，code为0表示成功，非0表示业务错误码。分页接口的data里包含records列表、total总记录数、current当前页、size每页大小。这个约定必须在项目一开始就定好，后端写一个统一响应类，前端写一个统一请求封装，后面所有模块都不用再纠结返回结构的问题。
3. 小程序端实战开发详解
3.1 项目结构与页面路径规划
小程序端工程的目录结构要按照业务模块组织，别全堆到一个pages文件夹里。
pages/ ├── home/ // 首页：乡村推荐、搜索入口、轮播图 ├── village/ // 乡村列表页、乡村详情页 ├── attraction/ // 景点详情页 ├── homestay/ // 民宿列表页、民宿详情页、房型选择弹层 ├── booking/ // 订单确认页、订单列表页、订单详情页 ├── product/ // 商品列表页、商品详情页 ├── cart/ // 购物车 ├── route/ // 路线推荐列表页、路线详情页 ├── user/ // 个人中心 ├── login/ // 登录授权页页面菜单配置在app.json里做，tabBar少放几个关键入口，首页、路线、购物车、个人中心这四个就够了，更多的入口让用户在页面里的导航区自己点进去。
需要注意的地方有一个，微信小程序的页面跳转有层级限制，用户点击路径太深会出现页面栈溢出的问题。我的处理方式是把一些中间的列表页用wx.reLaunch或wx.redirectTo来跳转，尤其是从个人中心跳到订单列表这种场景，别一直用wx.navigateTo叠路径，十个页面上限真的会碰到。
3.2 登录授权与Token管理：连不上后端时的本地调试方案
微信小程序的用户登录流程是标准三段式：wx.login拿到code -> 后端拿code去微信服务器换openid -> 后端返回自定义登录态token。这个流程本身不复杂，但很多新手在这里栽跟头，原因在于小程序的合法域名校验。
在开发阶段，如果你没在小程序后台配置request合法域名，在开发者工具里打开“不校验合法域名”就能调通接口。但真机预览时，不校验合法域名的开关是不生效的。解决这个尴尬局面的办法有这么几个：第一个，也是我最推荐的，直接用开发者工具里的“模拟器”调试，勾选不校验合法域名，开发调试都在模拟器里完成；第二个，要真机预览的话，在小程序后台把后端域名加到request合法域名里，需要后端有域名且配好HTTPS证书；第三个，临时急用可以打开开发版小程序的“开发调试”模式，但这毕竟不是长久之计。
登录态的管理要重点留意。用户请求token拿到后，我存放在globalData里，同时用wx.setStorageSync存一份。每次请求拦截器先检查token有没有过期，过期了或者干脆没登录，就自动走一遍wx.login静默登录流程刷新token。这个逻辑必须在项目初期就写好，不然做到后期每个页面都处理登录逻辑，人会被逼疯的。记忆深刻的一次，我头天晚上把所有页面的接口都接好了，第二天清缓存一看，接口全部401，就是因为token没做自动刷新。后来我把登录态封装到一个独立的auth.js模块里，所有请求统一走这个模块，问题才彻底解决。
3.3 地图与位置服务的接入细节
乡村旅游小程序是重度依赖位置服务的，用户搜东莞村在哪、大明山怎么走，都需要地图。微信小程序里接入地图有两个方案：用内置的<map>组件，或者用腾讯地图小程序SDK。
我的做法是用内置map组件 + 腾讯地图WebService API组合。小程序map组件的底层就是腾讯地图，可以展示marker标记点、polyline路线，不需要额外引入SDK就能满足大部分展示需求。但如果你需要做路线规划、关键词搜索附近乡村、计算两个景点间的驾车时间，就用腾讯地图WebService API，先配好自己的腾讯地图Key，通过wx.request调用对应接口即可。
这里有个经验要分享，地图相关的接口域名一般是apis.map.qq.com，必须在小程序后台的request合法域名列表里加上这个域名。腾讯地图Key需要在腾讯位置服务控制台申请，教程一大堆，不细说了。
数据层面，乡村、景点、民宿这些资源数据在录入时就要把经纬度存进去。后台管理界面里我建议直接用地图选点的方式，管理员在地图上点一下位置，经纬度就自动填充到表单里，别让人手输坐标，又慢又容易错。这个小功能虽然不起眼，但省下来的时间真的可观，录几十条资源信息时尤其明显。
3.4 民宿预订与支付闭环的实现
预订流程是小程序端最核心的业务链路，我详细说一下。
用户在民宿详情页选择房型，设置入住日期、离店日期后，页面会进入订单确认页。订单确认页要做三件事：展示用户选择的房型和日期信息；实时计算订单总金额；让用户确认入住人信息、联系电话和备注。金额计算必须由前端和后端各算一遍，前端展示用的金额是预估价，提交订单时以后端计算的最终价格为准。这么做是防止有人恶意篡改前端请求，把单价改成一毛钱然后下单，后端如果直接信前端传过来的价格，钱就亏大了。
提交订单的逻辑后端按照这样的顺序来：先锁房和校验库存；计算订单金额并生成订单记录，状态为待支付；返回订单号和应支付金额给小程序端。小程序端拿到订单号后再唤起微信支付。微信支付在这里有一个很现实的问题，个人主体的微信小程序无法开通微信支付，必须是企业主体或个体工商户主体。很多学生自己做毕设的时候没有公司资质，我的建议是做一个模拟支付接口，用户在订单确认页选择“模拟支付”，后端直接把订单标记为已支付，这样整个订单流程就完整了。论文里可以实话实说，微信支付对接需要企业资质，本文使用模拟支付完成业务流程验证。这套说辞在答辩环节完全站得住脚。
3.5 图片上传与渲染优化
乡村旅游内容的一大特点就是图片多，不管是乡村的风景图、民宿的房间图还是商品的实物图，都是要用图片说话的。小程序端发布评价、后台管理端上传图片，都要处理图片上传问题。
微信小程序上传图片用wx.uploadFile，这个API的格式比较古早，跟wx.request的格式完全不同。它接收的是一个本地临时文件路径，所以要先通过wx.chooseImage或wx.chooseMedia让用户选图片，拿到临时文件路径后再传给wx.uploadFile。后端接口要接收MultipartFile格式的文件参数，保存到服务器的某个磁盘目录，然后返回文件的访问URL。
图片渲染这块有一个大坑，就是图片懒加载。乡村列表页如果一次性渲染三五十张图片，内存占用非常厉害。小程序原生虽然有自己的图片懒加载属性lazy-load，但它只对<image>组件生效，而且效果一般。我的做法是列表页接口分页加载，每页十条数据，配合lazy-load属性，就不会出现长列表卡顿的问题。图片上传前在前端做一次压缩也很重要，手机拍摄的图片动不动就五六兆，上传一张图好几秒钟，用户早就溜了。用wx.compressImage压缩一下，两兆以内再上传，体验完全不一样。
4. 管理系统后台与核心业务实现
4.1 后台管理框架搭建与权限控制
后台管理系统的技术栈是vue3 + Element Plus + Vite，工程结构采用经典的src/views（页面视图）、src/router（路由）、src/store（状态管理）、src/api（接口封装）、src/components（组件）分层。这种分层方式每个做Vue的人都很熟悉，不用过多解释。
登录页和后端登录接口对接，成功后拿到token，存到localStorage里，并在Axios请求拦截器里统一带上Authorization请求头。这个token后端是用JWT生成的，我之前说过，JWT的签名密钥要放到服务器配置文件里，不要硬编码到代码中。每次请求到达后端时，通过拦截器校验token的合法性，如果过期则返回401状态码，前端收到401后统一跳转到登录页。
权限控制这块做的是基于角色的简单权限模型。管理员表里有个role字段，值为admin或operator。前端路由添加了路由守卫，根据用户角色判断当前路由是否允许访问，operator不能访问系统设置模块和数据看板模块。后端的每个管理接口都要求登录后才能访问，管理团队的操作都在操作日志里留痕。
4.2 数据看板与统计接口的实现
数据看板是管理系统里最容易被忽视又最出效果的部分。演示系统的时候，运营负责人打开后台第一眼就是看数据页面，图表出来的一瞬间印象分就拉满了。
我的数据看板展示了这些数据：今日订单数、今日交易额、本月交易额、本月新增用户数、各乡村访问量排行、订单状态分布。统计数据的接口我单独放在一个StatisticsController里，SQL层面用聚合函数实现。比如今日订单数，就是SELECT COUNT(*) FROMorderWHERE DATE(create_time) = CURDATE()，这种查询在MySQL里写起来非常简单。
图表渲染我用的是ECharts的Vue版本vue-echarts，要注意的是ECharts的包体积不小，用Vite构建时最好配合unplugin-vue-components做按需引入，只引入实际用到的图表组件，避免整个ECharts包打包进来，那样主包体积会爆炸。
4.3 后台内容管理的操作体验
后台做得让运营同学真的愿意日常使用，这是很多毕设项目没有考虑到的问题。我做项目时总结了几条让后台更好用的经验。
表单校验不能缺。乡村信息表单里有必填项，比如乡村名称、所在区县、简介、封面图，El-form组件的rules规则要配置好，提交时统一校验，没填的字段要有红色提示。日期选择用日期选择器，区间选择直接给个快捷范围。上传图片用El-upload配合后端接口，组件里限制文件类型为图片、大小不超过5M、最多上传9张，并把前端预览和回显做好。
列表页必须支持通用筛选条件，比如根据名称模糊搜索、按上架状态筛选。分页组件用Pagination，每页条数可以让用户自己选。删除操作要弹确认框，因为删除是不可逆的。这些看起来都是基本功，但做好了是真的省心。
列表和表单的布局尽量遵循一个模板，表格里带操作列，操作列按钮统一用图标加文字形式。整个后台的UI风格保持一致，用Element Plus默认主题就行，别花太多时间在主题定制上，那都是锦上添花的事，核心功能先跑顺。
5. 论文结构撰写与答辩实战要点
5.1 毕业论文的章节框架和撰写的先后顺序
论文怎么安排，是很多做完代码之后完全不知道怎么下笔的同学的共同困惑。我见过太多代码写得不错、论文却稀烂的例子，白白浪费了前面的努力。
这篇论文我建议按六章来组织：第一章绪论，写研究背景与意义、国内外研究现状、研究内容与目标、论文组织结构；第二章相关技术介绍，写微信小程序、Spring Boot、Vue、MySQL这些东西的核心特性和选型理由；第三章系统需求分析，写可行性分析、功能需求分析、非功能需求分析，用例图和用例说明表；第四章系统设计，写系统总体架构、功能模块设计、数据库设计，E-R图和表结构要全；第五章系统实现，按模块截图加文字说明，重点模块的关键代码片段和实现描述；第六章系统测试，写测试环境、测试用例设计、功能测试结果、性能测试结果，最后是总结与展望。
撰写顺序上我给一个建议：先画图表再写文字。先确定架构图、功能模块图、用例图、E-R图这几张图，图磨好了，论文的逻辑线索就清晰了，后面只是填肉。图表的工具我推荐ProcessOn，线上操作方便，出图美观，答辩老师看了印象分直接拉高。
5.2 图表怎么画：让论文显得专业的关键
论文里的图表质量直接决定审阅老师对本篇论文的第一印象。很多同学的图看着杂乱无章，问题不是画图技术不行，而是没有先想清楚要表达什么。
技术架构图要画分层结构，前端展示层列微信小程序和Vue后台，后端服务层列Spring Boot、MySQL、Redis这些，用清晰的箭头表示数据流。功能结构图用树状图展现系统模块，后台管理系统在根节点，分支依次是内容管理、订单管理、用户管理、数据统计等。用例图画三个角色：游客、管理员、运营人员，每个角色连出相应的用例，一组用例关系清清楚楚。数据库E-R图按照我之前讲的十一张表来画，主外键关系用连线标示，实体属性不要全部列上去，只列关键属性，否则图会大到根本放不下。
这些图每张图我都见过大量反面案例，最大的问题是边界不清、关系混乱。画好之后找个不熟悉系统的人来看一眼，3秒钟能看懂，这张图就算合格。
5.3 答辩高频问题与应对策略
答辩环节问的问题其实有很强的规律性，提前准备就能从容很多。
必问的问题是系统架构。老师会问整个系统的请求流程是什么样的，这时候要按这个顺序回答：游客在小程序点击页面触发请求，wx.request发出HTTP请求到后端接口，后端Controller接收请求、Service处理业务逻辑、Mapper操作数据库，返回JSON数据给前端渲染展示。把这个链条背到肌肉记忆，答着答着就顺了。
老师还爱问安全方面的问题。常见的坑是学生回答“密码直接存在数据库里”，这是大忌。我们系统登录密码用BCrypt加密存储，前端用HTTPS发送，后端对非法输入做参数校验，有这几个点，安全相关的提问就不会翻车。
数据库设计相关问题也不容忽视，老师会问订单表为什么这么设计。回答思路从主从表设计开始说，订单表和订单商品表分离是为了支持一个订单购买多件商品，商品名称和价格快照字段是为了保障订单历史数据不被商品修改影响，这就是一个合格的数据库设计思路。
不用过度紧张。答辩的本质是把系统讲清楚，你亲手做的系统，该知道的都知道，放稳心态就好。
6. 部署、联调与全流程避坑清单
6.1 从零到一的全流程步骤梳理
做完整套系统，剩下的事就是把自己做的成果完完整整跑起来。按照下面的顺序来部署，每一步都验证通过再走下一步，不要跳跃式操作。
环境准备阶段，装JDK 1.8+、Maven 3.6+、MySQL 8.0+、Node.js 14+，微信开发者工具也装到最新版。数据库执行项目里的init.sql脚本，创建数据库和所有数据表，导入部分测试数据，不然小程序前端没数据可用，点进去一片空白，很容易误以为系统坏了。
后端启动前修改application.yml配置文件，重点看这四项：数据库连接地址、数据库账号密码、JWT密钥、微信小程序appid和secret。后端启动后先试一下登录接口，用Postman调通了再继续。
管理后台前端工程在终端执行npm install安装依赖，然后npm run dev启动开发服务器，浏览器打开本地地址测试后台功能。小程序端把appid改成自己的测试号，在开发者工具里导入项目工程，勾选不校验合法域名，编译运行即可。
联调阶段重点检查这些流程：小程序登录是否能正常拿到token；首页乡村列表数据能不能加载出来；民宿预订流程从选中日期到提交订单再到点击支付是否完整跑通；后台的订单管理里能否看到小程序端下的订单。这几条链路都走通了，系统就真正闭环了。
6.2 那些年踩过的坑：高频问题排查实录
做这类项目一定会碰到的一些经典问题，提前写出来帮大家排雷。
问题一：登录时后端报错“code无效”。绝大多数原因不是代码写错了，而是你拿测试号AppSecret跑生产接口，或者反过来。还有可能是服务器时间和微信服务器时间偏差太大，导致code校验失败，这个情况比较少见但确实存在。解决办法是先核对appid和secret是否匹配。
问题二：小程序request域名报错。开发者工具里提示“不在以下request合法域名列表中”。运行环境的合法域名是在小程序后台配置的，前后端联调时直接在开发者工具右上角点击“详情” -> “本地设置” -> 勾选“不校验合法域名”，问题就解决了。真机预览时记得在小程序后台把域名配置好。
问题三：前端传JSON后端接不到参数。经典错误。后端用了@RequestBody注解接收JSON对象，前端却在请求头少了Content-Type: application/json，用wx.request时一定要把header设置成这个值。另外一种情况是后端接收的是单个参数，前端传的是整个对象，对应关系搞错了。排查方法很简单，后端Controller断点打上，看请求参数长什么样，一目了然。
问题四：民宿预订成功但订单列表查不到。大概率是订单状态字段写死了。用户下单后订单状态是“待支付”，而订单列表接口只查“已支付”状态，那当然查不到。这个问题提醒大家设计接口时把状态参数做成可选条件，前端列表页有全部状态切换按钮时，传空值就是查全部，灵活得多。
问题五：后台能登录但小程序端报401。这个通常是因为不同端使用了不同的token，小程序端请求带的小程序token，后台却用管理端token的密钥去校验，两个模块的JWT密钥没有统一，所以永远校验不过。解决方法是确认前后端所有模块只用同一个JWT签名密钥，或者干脆后端用一套统一鉴权组件。
6.3 从毕设到真实落地：系统还能怎么扩展
如果想把这套系统做得更完整、更有说服力，可以根据自己的时间和精力做一些扩展，几个方向我已经验证过可行。
推荐算法是一个受欢迎的扩展方向。基于用户的历史浏览记录、收藏、预订行为，做一个基于协同过滤的乡村民宿推荐功能，热度最高或浏览记录最多的优先推荐。这个方向讲起来高大上，往上做难度也合理，论文里占的篇幅不少。
Redis缓存往系统里引入，缓解数据库的压力。热门乡村列表、首页轮播图这些读多写少的数据，放进Redis缓存，设置过期时间，读写性能有可观提升。这个方向实现难度不大，却能让“系统性能设计”这一章有话可说。
微信订阅消息做订单状态提醒，是提升用户体验的有效手段。用户支付后、商家确认后，通过微信订阅消息向游客推送通知。微信小程序订阅消息的申请和使用流程我在官方文档里已经验证过了，效果良好，接入难度适中。
数据导出功能比较务实，后台把订单数据、商品销售数据导出成Excel表格。用EasyExcel或POI实现，运营团队做数据分析时直接拉Excel自己处理，买单意愿极高。在毕设答辩时给老师演示一键导出Excel，效果也是很好的加分项。
做这套系统最大的收获，其实不是写了多少行代码，而是完整走通了一个“需求分析 -> 架构设计 -> 编码实现 -> 测试部署 -> 论文输出”的闭环。把课本上的概念一个个落到了实处，这个过程本身就是最有价值的。我当时调试订单状态流转逻辑，前前后后改了三轮才弄顺，那种终于跑通的感觉，跟在学校里考试拿高分完全不是一个量级的。做工程就是这样，不踩坑不成活，踩过的坑才能变成你经验库里的底牌。
如果你正在做类似的系统，也是个不错的起点。先别贪多，把核心链路跑通，把论文框架搭好，再根据需要丰富细节。需要交流具体技术问题的，欢迎评论区留言，看到我会认真回应。
