每年毕设季后台都会收到一堆类似的问题基于Springboot的民宿预订小程序这个题目到底好不好做后端要写多少东西标题里那个LW是什么意思说实话这个选题每隔几年就会出现在各大学的毕设选题表里热度从来没降过。原因很简单——民宿预订的业务边界清晰、功能点完整、用户角色明确既不像电商秒杀那样要处理高并发也不像纯管理系统那样缺乏亮点刚入门的同学在几个月时间内是真能做完的。LW其实就是论文的缩写也就是说这个题目不仅要交付小程序和后端代码还得交付一篇配套的毕业设计论文。SpringBoot负责后端接口微信小程序负责用户端再加上一个后台管理页面或者民宿主端小程序整个闭环就完整了。这篇文章我按实际做项目的顺序来写从选题逻辑、数据库设计、后端接口、小程序页面一直讲到最后部署上线的坑尽量把代码之外的经验也交代清楚给准备做类似题目的同学一条可以直接参考的完整路径。1. 选题逻辑与技术栈定版为什么民宿预订是毕设的稳妥牌1.1 业务复杂度刚好卡在能做完和有东西写之间选毕业设计题目有个很现实的标准功能太少撑不起论文篇幅功能太多做不完或者答辩时被追问到崩。民宿预订系统刚好卡在中间位置。从用户角色看小程序端有游客搜索房源、查看详情、注册用户收藏、下单、支付、评价民宿主端有房源管理、订单处理、房态维护后台管理有用户审核、数据统计。三类角色下来用例图就能画十几条论文的需求分析章节不会干巴巴。从业务链路看民宿预订天然包含一条完整的主线搜索房源→查看房型与房价日历→选择入住离店日期→提交订单→支付→入住→退房→评价。这条链路覆盖了增删改查、状态流转、金额计算、权限控制这四类核心编程考点而且每条都有真实业务含义。比那些硬凑出来的XX管理系统自然得多演示的时候也容易讲清楚——每个功能都能说出一个用户场景。还有一个隐性优势民宿预订系统天然适合做创新点。比如按地图选房源、日历房价随旺季浮动、优惠券满减、房东评分体系这些都可以作为论文里的特色功能章节。哪怕你只实现了其中两三个也足够在答辩时回答你的系统有什么亮点这个问题了。热搜词里那些基于springboot vue商品管理系统的设计与实现之类的题目反而不好发挥——商品管理系统太通用很难讲出差异化。1.2 SpringBoot 2.7.x JDK8毕设别当版本实验品技术栈定版这事我见过太多人栽跟头。很多同学一上来就装最新的Spring Boot 3.x结果跟着B站教程一路踩坑光是javax和jakarta命名空间的问题就能卡一整天。这里给个明确建议如果没有人逼你用最新版老老实实选Spring Boot 2.7.x JDK8 Maven MySQL 8.0这套组合。为什么这么选首先绝大多数教学视频、开源教程、毕业设计参考资料都是基于这套组合写的你遇到问题搜索时能直接找到答案。其次微信小程序的SDK和第三方支付SDK对Spring Boot 3的支持晚了好一阵子适配成本高。最后毕业论文里的技术介绍章节也好写——Spring Boot 2.7的自动配置原理、Starter机制参考资料一大堆。项目构建工具我建议用Maven而不是Gradle。理由很朴素Maven的中央仓库依赖下载稳定IDEA对Maven工程的支持成熟而且毕业设计免不了要交那种从零构建的过程记录Maven的pom.xml结构比Gradle脚本更容易在Word文档里排版讲解。热搜词里那条springboot gradle项目搭建的搜索热度不低但那是出到社会之后的事毕设阶段没必要给自己加戏。建工程的时候顺手把这几件事办了设置maven-compiler-plugin的source和target为1.8配置Spring Boot的finalName为项目英文名加上lombok依赖省掉setter/getter模板代码。这些小设置看起来不起眼但能让你后期少生很多气。1.3 小程序端选原生还是uni-app先想清楚论文里要写什么小程序端的技术选型会直接影响你论文里那个系统实现章节怎么写。原生微信小程序用的是WXML、WXSS、JS结构上贴近前端三件套图表和截图看起来也很微信风格。uni-app用的是Vue语法可以一套代码同时编译出微信小程序、H5和App适合那种还想着说不定以后要发一个App的想法。我的建议是如果论文需要展示小程序特色功能或涉及微信生态与后端交互逻辑选原生就够了代码量不大遇到问题也容易排查。如果你本身熟悉Vue或者还想多拿一个可运行的H5页面作为演示备用可以选uni-app。但你得接受一个代价——uni-app编译出来的小程序包体偏大有些原生接口需要条件编译处理讲明白这些细节又得占论文篇幅。这里有个很重要的配套决策你打算在什么设备上演示如果是毕设答辩大概率是电脑上的微信开发者工具模拟器。原生小程序在模拟器里的表现最稳定uni-app偶尔会出现样式偏移需要重启编译。小程序端开发时顺手装好微信开发者工具、开启接口调试模式域名校验在开发阶段可以先关掉后续上线再严格配HTTPS这个流程在后面部署章节会展开。2. 从ER图到建表SQL民宿订单系统最容易踩的设计坑2.1 七张核心表与它们的关联关系民宿预订系统的数据表设计说难不难但每年都有人设计出一张表存所有价格或者订单表里塞JSON字段存房型快照这种后期必炸的方案。我按做过并验证过的方案给你拆一下总共七张表user用户表字段包括id、openid微信唯一标识、nickname、avatar、phone、role区分普通用户和民宿主、create_timehouse民宿表字段包括id、owner_id关联user、title、address、longitude、latitude、cover_url、description、audit_status后台审核状态room房型表字段包括id、house_id关联民宿、name、area、bed_info、max_people、daily_price_base基础价格作为房价日历的兜底值rate_calendar房价日历表字段包括id、room_id、date、price、stock、is_sold_out这是整个系统最核心的一张表order订单表字段包括id、order_no、user_id、room_id、check_in_date、check_out_date、nights、guest_name、guest_phone、total_price、status、cancel_reason、create_timecomment评价表字段包括id、order_id、user_id、house_id、content、rating、image_urls、create_timefavorite收藏表字段包括id、user_id、house_id、create_time关联关系很好理解一个民宿下有多个房型一个房型在房价日历表里对应多条日期记录一个用户下单后产生一条订单订单结束后可以写一条评价。民宿主和管理员其实也放在user表里用role字段区分不要单独建两张管理员表和民宿主表那样登录逻辑和权限拦截都会变复杂。我要特别强调order表里的check_in_date和check_out_date是date类型不是datetime也不是字符串。用字符串会导致日期比较和计算晚数时出一堆bug用datetime会在跨天入住时产生时区偏移。date类型干净利落后端传参时统一按yyyy-MM-dd解析这点做对了能省掉后面一大堆麻烦。2.2 房价日历表别把价格做成固定的每晚单价很多人第一次设计民宿系统时会在room表里放一个daily_price字段然后用单价乘晚数计算总价。这个方案在演示阶段勉强能跑但一旦涉及周末加价、节假日调价、淡季促销订单金额就是错的。而且答辩时评委大概率会问民宿价格周末和节假日会浮动你的系统怎么处理你要是回答我们价格是固定的这题就凉一半了。房价日历表rate_calendar是解决这个问题的标准方案。它的逻辑是每个房型的每一天都有一条独立的记录记录当天的价格和可售库存。前端展示房价时直接查这个日期区间内的数据逐日累加得到总价。这样做的好处有三点一是价格调整只影响指定日期不影响其他日期二是可以基于日历做满房标记is_sold_out三是论文里可以名正言顺地写系统采用动态房价日历设计支持按日期精细化管理房价与库存这是实打实的亮点。初始化房价日历的逻辑要注意什么时候生成数据一般做法是民宿主上架房型时系统自动生成未来90天或180天的日历记录价格默认取room.daily_price_base库存取一个默认值。这个初始化动作要写成定时任务或者发布房源时同步执行不能等用户查询时才去补日历数据否则并发查询时会出现同一房型某些日期有记录、某些日期没记录的怪异情况。2.3 订单状态机从待支付到已完成的状态流转订单状态设计我建议直接用int字段加状态枚举不要用字符串更不要用多个布尔字段拼状态。推荐的状态值0待支付下单后生成1已支付/待入住支付成功后进入2已入住到店办理入住后民宿主端点击操作3已完成退房后4已取消用户主动取消或超时未支付自动取消5已退款支付后退款完成状态流转的规则要写清楚待支付可以取消、可以支付已支付可以申请退款已入住不能直接取消已完成可以发表评论。这些规则在service层写一个状态流转校验方法每次更新前校验当前状态是否允许跳转到目标状态不允许就直接抛业务异常。这样设计不是为了花哨而是防止那种用户已经入住了还能取消订单的低级逻辑错误。超时未支付自动取消这个功能毕设阶段实现起来有两条路一是用定时任务扫描超过30分钟未支付的订单并置为取消二是用RabbitMQ延迟队列。定时任务在单机部署下够用也好写延迟队列可以写进论文的技术展望当额外亮点。如果选定时任务记得加一个前提条件——只取消状态仍为0的订单不要误伤已支付订单。价格计算也是状态机之外要配套考虑的总价必须落在订单表里保存一个快照字段不要在下单后还去实时查房价日历累加因为中间的房价可能变了。这也是订单表存快照这个习惯的由来——订单确认那一刻的价格、房型描述、民宿地址都冗余一份进去后续无论房价怎么调整订单不受影响。3. 后端骨架搭建与三个关键接口的落地细节3.1 项目分包与统一返回结构SpringBoot工程的分包我建议按controller、service、mapper、entity、dto、config、common七层来组织。entity对应数据库表dto对应前端传输对象不要把entity直接返回给前端哪怕字段一样。等你加了字段校验、日期格式化、脱敏逻辑之后再回头会感谢自己当初做了这层隔离。common目录放Result类、异常处理器、常量定义、JWT工具类、拦截器。统一返回结构是必做的类名就叫Result字段包含code200成功其他为失败、message、data三个字段。接口成功时返回Result.success(data)失败时返回Result.error(code, message)。配合一个RestControllerAdvice全局异常处理器把参数校验异常、业务异常、未知异常全部转成统一结构返回。这样做的好处是在小程序端就只要处理一种后端响应格式不用每个接口单独判断数据结构也方便后续用统一拦截器做401鉴权处理。很多同学前期图省事controller直接返回一个User对象或List 等到做小程序端时发现要么判断不了接口是否成功要么拿不到错误信息回头再来改就难受了。统一返回结构这件事属于典型的前期花十分钟、后期省十小时。3.2 微信登录与JWT别把openid丢给前端存小程序登录是一个高频考点答辩时几乎必问。完整流程拆开是六步小程序端调用wx.login()获取临时code这个code有效期五分钟且只能用一次小程序把code通过请求发送给后端接口比如POST /api/auth/login参数就是code后端拿code 小程序appid 小程序secret调用微信服务端的jscode2session接口微信返回openid用户在微信生态里的唯一标识、session_key、unionid如果你没申请开放平台就为空后端拿openid查user表用户不存在就自动注册一个新用户存在就直接登录后端生成一个JWT token返回给小程序token过期时间建议设7天这里有几个细节你必须在代码里处理对。第一小程序secret绝对不能返回到前端整个登录链路中前端只能拿到code和tokenopenid、session_key这些只允许在后端流转。第二后端必须校验code参数不能为空jscode2session接口本身的错误响应要处理不能盲目信任微信返回结果。第三生成的token用JWT标准格式payload里只需要存userId和role两个字段不要塞openid进去因为业务代码里根本不需要直接操作openid。JWT的密钥要配置在application.yml里不要写死在代码中答辩时可能被问到秘钥泄露怎么办——到时候回答生产环境下密钥通过环境变量注入就过关了。拦截器侧写一个LoginInterceptor从请求头Authorization里提取Bearer token并解析解析成功就把userId放入ThreadLocal上下文业务代码里直接能用。3.3 提交订单的并发控制乐观锁在民宿场景的够用性民宿预订虽然不像秒杀系统那样万人同时抢购但同一房间同一天被两个人同时下单的并发问题一定要处理因为答辩的评委有好几年都对这个问题追问过。处理思路分三层你可以按需要选。第一层是数据库约束。下单时执行一条原子更新的SQL核心语句是这样的逻辑UPDATE rate_calendar SET stock stock - 1 WHERE room_id ? AND date ? AND stock 0。MyBatis的update返回值就是影响的行数如果影响行数为0说明库存已经被扣完或日期不存在直接给前端返回所选日期已满房即可。这一条看着简单但很多人的实现是先SELECT再UPDATE中间就产生了并发窗口。第二层是事务控制。订单表和房价日历表的更新需要在同一个事务里用Transactional注解包住。注意事务方法不要通过同类内部调用this.method这种方式触发否则注解不生效这是个经典坑点。正确做法是通过注入的Service对象调用或者拆成两个方法由Controller层组合调用。第三层是Redis分布式锁。在毕设场景下层不需要但论文的系统优化章节里可以写本系统在高并发场景下可引入Redis分布式锁以setIfAbsent命令实现房间粒度的互斥锁定并结合Redisson框架实现可重入锁进一步保障极端并发下的数据一致性。这句话写在论文里答辩时能回答你这个系统抗不抗压实际操作里用不到也没关系。3.4 支付回调与退款毕设演示阶段的务实方案微信支付对接是民宿预订系统里最敏感也最耗时的环节。真实对接微信支付V3需要商户号、API证书、回调地址公网可访问等一系列条件个人毕业设计很难全流程走通。我的建议是做一个模拟支付流程把真实支付的坑留给论文的不足与展望章节。具体做法是订单状态为待支付时小程序端展示微信支付按钮点击后不真正唤起支付而是弹窗提示演示模式点击确认模拟支付成功然后把本地生成的一个模拟支付标识传给后端后端将订单状态从待支付改为已支付并记录支付时间和支付单号自己用UUID生成。退款同理民宿主点击同意退款后端直接把订单状态改成已退款不涉及真实资金流转。这不是投机取巧而是毕设场景下最合理的取舍。你完全可以在论文的相关技术章节介绍微信支付官方流程统一下单、调起支付、支付回调、退款在系统实现章节写明由于个人主体无法开通微信支付商户号系统在演示环境采用模拟支付策略生产部署时只需替换PayService实现类即可对接官方API。把接口设计成PayService接口模拟和真实是两套实现这句话一旦写上反而变成你设计上的亮点。后端接口文档用SwaggerSpring Boot 2.7对应springfox或springdoc版本注意别配错加上因为论文里要截接口测试的图而且答辩演示时可以直接用Swagger页面代替Postman观感更整洁。4. 小程序端开发实录日历选房、价格计算与登录态4.1 首页与房源列表的加载策略小程序首页的经典组合是顶部搜索框、功能入口图标、Banner轮播图和房源瀑布流列表。房源列表接口设计成GET /api/house/page入参包含pageNum、pageSize、keyword、sortType这几个字段返回分页数据。分页这件事不要偷懒用LIMIT加偏移量直接糊弄过去你在后端要封装一个PageResult类包含records、total、pageNum、pageSize四个字段前端列表加载更多和论文的分页查询章节都需要它。列表页的数据量大不大取决于你有没有在开发阶段造足够的演示数据。强烈建议写一个SQL脚本用存储过程或者Python脚本生成20家以上民宿、每家3到5个房型、每个房型未来90天的日历数据。数据越真实小程序里翻页、筛选、详情页展示的效果越好答辩演示的观感完全不一样。前端列表要做触底加载更多对应小程序原生的onReachBottom事件。每次触底时pageNum加1请求新数据后通过setData追加到现有列表尾部。这里有一点setData的数据量要控制一次追加20条没问题不要一次性把几百条全部setData小程序会卡。请求函数里加一个isLoading标记防止触底事件被连续触发导致重复请求——这个防重复逻辑在演示时非常明显不加的话快速滚动时列表会闪烁、跳数。4.2 选房日历与连住价格计算的边界条件房源详情页是整个小程序的核心它必须包含民宿图集、房型列表、日历控件、价格明细和立即预订按钮。日历控件要支持开始日期和结束日期两个值的选择选完开始日期后自动高亮结束日期之前的所有日期。这里的关键逻辑是所选日期区间内每天都必须有可用房间对应房价日历表里的stock 0中间任何一天满房整个区间就不能下单。价格计算的代码不要想当然地写成totalPrice dailyPrice * nights。正确做法是根据checkInDate和checkOutDate遍历日期区间内每一天的房价日历记录累加每天的price。为什么要逐天累加因为周末和节假日的价格不同每晚价格可能都不同。连住3晚可能是300350300950而不是固定的单价乘以3。这个逻辑会在接口层实现前端详情页的日历选中后立即向后端发送价格查询请求比如GET /api/room/price?roomIdxxstartDatexxendDatexx后端返回每日价格明细和总价前端渲染出来给用户确认。边界条件要单独处理开始日期不能早于今天结束日期必须大于开始日期单次预订最多不能超过30天你可以自己定日历控件禁用已满房的日期。这些校验前后端都要做——后端是最终防线前端是用户体验。我见过有人前端做了校验就以为万事大吉结果用Postman直接调接口下单把已满房日期都订进去了答辩当场翻车。日期格式化是毕设阶段最容易出的bug。MySQL的DATE字段、Java的LocalDate、小程序的Date对象三者之间传递要统一用yyyy-MM-dd字符串不要用时间戳。用时间戳会导致跨时区计算偏差特别是线上服务器部署在非东八区的时候但谁让你用国内服务器的话倒没这个问题。4.3 登录态维护token过期从不该弹请重新登录小程序端登录态的常规方案是首次打开调用wx.login获取code换到token后存入wx.setStorageSync(token)后续所有请求在统一的request工具里自动带上Authorization头。这个request工具要封装成Promise风格内部统一处理code为401的情况——401就是token过期或无效此时清理本地token并跳转登录页。太多人的小程序在token过期后体验很糟糕用着用着突然弹窗请重新登录用户点完登录又得重新操作一遍。正确的体验应该是静默登录App启动时先检查本地token没有就静默调wx.login换token请求过程中遇到401调用一个刷新token的机制或者直接静默重新登录一次然后重放当前请求。毕设项目用静默登录请求重放这套方案代码量不大但在答辩演示时给人一种很成熟的感觉。登录时机要讲究不要一进小程序就强制用户登录先让用户浏览房源、看详情真正要下单时才弹出登录提醒。这样既不影响体验也能避免用户因刚进来就被要手机号授权而关闭小程序。微信的getUserProfile接口已经改版多次现在拿头像昵称的流程和早期不一样了你写代码前先确认基础库版本别照抄旧代码。刷新Token这里顺便说一句JWT是无状态的token一旦签发只能等它自然过期要让退出登录真正生效需要后端维护一个黑名单或者缩短token有效期。毕设阶段token有效期设短一点比如2小时配合静默登录效果就足够了不折腾黑名单。4.4 民宿主端房态管理与订单处理的权限划分民宿主端可以做成同一套小程序里的角色切换模式也可以单独做一个Web管理后台页面。角色切换的模式在毕设答辩时更惊艳因为你打开同一个小程序给评委看用户身份进去是预订页面切换到民宿主身份进去就变成房源管理后台。实现方案是在登录时通过user表的role字段区分菜单栏根据角色动态渲染。民宿主端的核心功能是房源管理、房态日历和订单处理。房源管理就是CRUD新增房源时要填写基本信息、上传封面图、添加房型提交后状态是待审核管理员后台审核通过后才会在小程序端公开展示。房态日历视图是一个按月展示的日历每天标记已售可订满房民宿主可以手动修改某一天的房价和库存也可以批量设置未来一个月周末加价。订单处理列表显示自己房源的订单可以对已支付订单进行确认入住和确认退房操作。这个角色权限的隔离要在后端严格处理民宿主只能操作house表中owner_id等于自己id的记录后端service层做数据权限校验不只是前端隐藏按钮。答辩被问民宿主能不能越权改别人的房源时代码里是真有这个校验的。5. 论文LW结构与答辩被追问时的应答预案5.1 论文目录怎么排工作量才能撑起毕业设计毕设论文的黄金结构是摘要、Abstract、目录、1绪论、2相关技术介绍、3系统分析、4系统设计、5系统实现、6系统测试、7总结与展望、参考文献、致谢。这个骨架基本是各学校的通用模板你按它填充就好重点是每章不能写太薄。第1章绪论里国内外研究现状这个部分最容易空建议从民宿行业在线预订的发展微信小程序生态在生活服务领域的应用SpringBoot框架在企业级开发中的普及三个角度各写一段每条参考文献都要真实读过不要瞎编查重系统会查的。第2章相关技术可以写SpringBoot核心机制、SpringMVC请求处理流程、MyBatis持久层原理、MySQL事务机制、微信小程序框架、JWT身份认证。每小节保证一页以上的篇幅截图架构图或放一段核心配置。第3章系统分析必须包含可行性分析技术可行性、经济可行性、操作可行性和需求分析功能性需求、非功能性需求然后配用例图。用例图用draw.io画清楚即可包含用户、民宿主、管理员三个角色。第4章系统设计包含总体架构图、功能模块设计按用户端、民宿主端、后台管理端三个模块展开、数据库设计ER图加核心表结构说明。第5章系统实现是全篇最长的章节按功能模块一个一个写每个模块配2到3张运行截图附上关键伪代码。第6章系统测试写测试环境、功能测试用例表、部分性能测试结果。全篇下来60页上下是正常体量。5.2 三张图的绘制规范用例图、E-R图、系统架构图论文里最出效果的三张图你最好提前绘制并且保证风格专业。第一张是用例图角色是用户、民宿主、管理员用户用例包括注册登录、搜索房源、查看详情、下单支付、取消订单、发表评价、收藏房源民宿主用例包括房源管理、房型管理、价格管理、订单处理管理员用例包括用户管理、审核房源、数据统计。第二张是E-R图核心实体包括用户、民宿、房型、房价日历、订单、评价、收藏用标准的菱形菱形连线画清楚。注意E-R图不要直接截图数据库工具生成的图那是给开发看的视觉比较糙最好自己在draw.io里重新画一张美观的。第三张是系统架构图从下往上画清楚五层MySQL数据库层、MyBatis持久层、SpringBoot业务层细分为Controller、Service、Mapper、微信小程序表现层、第三方服务微信登录API。这张图在论文的系统总体架构小节里必不可少同时也是答辩PPT的第一页技术底图。5.3 答辩追问Top5与回答思路答辩时间一般每人10到15分钟5分钟讲PPT5分钟演示系统剩余时间评委提问。我根据观察整理出高频问题清单为什么选SpringBoot而不是SSM——回答SpringBoot简化配置、内嵌Tomcat、自动装配机制开发效率高并补充说明SpringBoot并不是取代Spring MVC而是整合它。要让评委知道你不是只会背概念而是确实用它搭过项目。你的系统怎么保证并发下单不会超卖——回答数据库乐观锁UPDATE原子操作和事务控制延伸可加Redis分布式锁。这个问题在民宿预订题目里几乎是必问的你提前把关键代码截图放在论文或PPT里备用。价格为什么设计成房价日历而不是统一单价——回答民宿定价随淡旺季、节假日浮动房价日历可以精确到日期维度的价格与库存管理展示民宿主端手动调价的截图。JWT和传统Session有什么区别——回答无状态、服务端不需要存储会话、适合分布式部署同时承认JWT的主动失效劣势说明本项目通过短有效期加静默登录规避。你的密码存在数据库里吗——这个一般不涉及小程序用户没有密码但如果你想加一个手机号密码登录入口说明必须用BCryptPasswordEncoder加盐哈希绝不存明文。答辩态度的核心是不要和评委争论承认系统有不足并说明改进方向即可。说这块我确实没考虑到位后期可以通过XX方案来解决永远不会错。6. 部署上线的完整路径和常见坑清单6.1 从jar包到服务器宝塔面板快速部署毕设作品是要现场展示的稳妥起见你要有一套能跑起来的线上部署方案而不是只在本地IDEA里跑。我推荐的路线是购买一台国内云厂商的轻量应用服务器2核2G或2核4G即可学生优惠很便宜系统选CentOS 7或Ubuntu装宝塔面板非必须但对不熟悉Linux的同学能省大量时间然后在宝塔里装好JDK 8装1.8版本、MySQL 8.0、Nginx。本地打包的步骤是在IDEA右侧Maven面板双击package或者命令行执行mvn clean package -DskipTests。打包完成后target目录下会生成一个可执行的jar包比如house-booking-0.0.1-SNAPSHOT.jar。把这个jar包上传到服务器的/opt/app目录然后执行nohup java -jar /opt/app/house-booking-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod /opt/app/log.log 21 服务就跑起来了。这里要强调一个新手最容易犯的错打包前检查application-prod.yml里的数据库地址、账号密码、JWT密钥是不是正式值本地联调用的application-dev.yml和线上的prod配置千万别混否则上线后默默连错库数据一片混乱。两类配置里端口、日志级别都不同Spring Boot的加载规则是按spring.profiles.active指定的文件覆盖通用配置理解这个就好排查了。6.2 微信小程序真机调试的合法域名配置线上部署后小程序从开发工具切换真机预览会遇到一个经典问题request请求被拦截报request:fail url not in domain list。原因是你的小程序后台没有配置request合法域名。解决方法是在微信公众平台小程序后台的开发管理-开发设置-服务器域名里把request合法域名配置成你的后端HTTPS域名。这里有个前置条件是后端域名必须是HTTPS而且证书要有效。域名备案也需要时间建议提前两周准备。如果紧急演示可以临时用开发工具的不校验合法域名选项糊弄一下但这个选项在真机预览时不可用。服务器和域名这些资源早点购买这个环节是整个项目里时间不可控的卡住了会很被动。接口地址在小程序端不要写死IP用微信小程序的全局配置——在app.js的globalData或一个config.js里统一维护baseUrl比如https://api.yourdomain.com。开发时指向本地局域网IP加端口上线时改这一处配置即可。不要每个页面都写死不同的接口域名这是后期最容易翻车的低级问题。其实小程序端的API请求统一走一个request.js封装baseUrl也在那里统一管理这个习惯一定要有。6.3 一些值得写进部署总结的坑我把实操中见过和踩过的坑集中列一份你部署阶段照着排查MySQL的时区问题。数据库连接串加上serverTimezoneAsia/Shanghai否则Java端的LocalDateTime和数据库的DATETIME对不上订单时间的展示可能差8小时。MySQL的字符集问题。创建数据库时务必指定DEFAULT CHARACTER SET utf8mb4不是utf8。有人注册微信时昵称带emoji表情入库直接报Incorrect string value这个错误很隐蔽不跑真机数据根本发现不了。Tomcat的端口冲突。服务器上如果开了多套环境8080端口可能被占用。Spring Boot的端口在application.yml的server.port配置改成8081、8082均可小程序那边baseUrl同步改一下就行。微信小程序的界面层级问题。自定义弹窗的z-index要配合cover-view处理原生组件的层级本来就比普通view高。如果你做的是原生小程序写自定义日历弹窗时多研究一下cover-view和scroll-view的嵌套不然弹窗可能被地图或视频组件盖住。热搜词里还有一条微信小程序顶部导航栏高度如果你要在小程序首页做自定义导航比如把搜索框融进顶部背景色就需要用wx.getSystemInfoSync()获取状态栏高度再用wx.getMenuButtonBoundingClientRect()获取胶囊按钮位置这两个值一起算出导航栏的自适应高度。不同机型胶囊位置不同硬编码高度会导致某些手机上布局错位。日志是上线后最重要的排错手段。Spring Boot默认只输出到控制台要用logback配置输出到文件级别在生产环境设为INFO。小程序端请求失败的排查优先看服务端日志其次看小程序的Network面板。抓包工具之类的东西不是不可以但大多数场景下看日志比抓包快得多搜索小程序抓包之类的资料前先在服务端日志里确认接口是否被请求到。最后再分享一个很实在的长尾建议民宿预订这个题目的数据设计决定了你后续所有的进度。如果你现在还没动工先把房价日历表建好、把模拟数据脚本写好你就已经胜过一半进度落后的同学了。我在实际带毕设的过程中也常跟学生说精力分配要按数据库和登录接口花三成时间核心预订流程花四成前端美化加部署花三成来走这样时间紧的时候砍掉什么功能都能快速做决定。核心链路做扎实其他的功能都是锦上添花祝各位毕设顺利。