简介微信小程序开发已成为计算机毕业设计的热门方向其轻量、跨平台、易传播的特性非常适合校园场景下的工具类与社交类应用。一个完整的毕设项目不仅需要前端页面与后端接口的打通更要在功能设计、数据库建模、GPS轨迹采集与地图绘制等核心技术上体现工程实践能力。本文以“跑鸭”校园跑步社交小程序为例阐述如何利用Spring Boot搭建服务端、通过微信原生API实现跑步记录与好友互动并说明论文撰写、答辩展示及常见环境问题的应对思路。该项目融合了运动打卡、排行榜、动态发布等真实需求是一套能演示、能答辩、能上线的完整毕业设计参考范本。 毕业设计做到一半才明白选一个“能落地、能答辩、能演示”的题目有多重要。“跑鸭”这个基于校园跑步的社交微信小程序是我去年带过的学生项目里完成度和答辩效果都不错的一个源码、论文、答辩PPT、开题报告、任务书齐全而且整套东西的逻辑非常完整。今天不聊虚的直接把题目背后的设计思路、技术选型、核心模块实现和毕设答辩的准备工作全拆开讲一遍给正在选题目或者正在赶工期的同学一个能直接参考的样本。先交代一下这个项目是干嘛的。“跑鸭”本质上是一个面向校园场景的跑步社交小程序把两个高频需求绑在了一起一个是高校里常见的校园跑打卡、阳光体育课外锻炼学生需要记录跑步里程和轨迹另一个是社交需求跑步太枯燥得有搭子、有排行榜、有互动才有动力坚持下来。整个小程序围绕这两条线展开核心功能包括跑步轨迹记录、运动数据统计、动态发布、好友关注、排行榜和成就系统。服务端采用Spring Boot MySQL前端是微信小程序原生开发支付、地图等能力调用微信生态的开放接口。这篇复盘适合在准备计算机类毕业设计的同学尤其是选题方向是微信小程序、前后端分离项目、或者带社交属性的工具类应用的。如果你手里已经拿到“跑鸭”这套资源正在改代码、写论文或者准备答辩这篇文章可以帮你把每个模块背后的设计逻辑讲清楚论文里“为什么这么设计”这种最容易被答辩老师追问的问题你都能答得上来。1. 项目定位为什么选“校园跑步 社交”这个切入口先从一个很现实的问题聊起毕业设计选题最忌讳什么最忌讳的是做一个“看起来高大上但根本做不完”的题目。人工智能、大数据、区块链这些方向听着唬人但如果没有扎实的算法功底和数据支撑做到最后往往是糊一个演示界面答辩时被问两句技术细节就露馅了。而“跑鸭”这个选题讨巧的地方在于它的技术栈非常经典功能需求非常明确又在社交这个点上做出了差异化既不会太简单显得没工作量也不会太难导致做不完。1.1 需求从哪来不只是“拍脑袋想功能”校园跑步社交这个点不是凭空编的。高校里普遍存在跑步打卡的需求很多学校要求每学期完成一定里程的课外锻炼算入体育成绩。这就催生了几个痛点学生需要一款能记录轨迹、计算里程的工具但市面上的Keep、悦跑圈等App在校园场景下不够精准比如打卡范围限定、路线要求、配速要求这些校园特有规则在通用App里没法配置另一方面独自跑步很难坚持如果有好友之间的互动、排行榜的竞争完成率会高很多。所以“跑鸭”的功能雏形就可以拆成两条主线和几条支线主线一工具属性。跑步记录、轨迹绘制、配速/里程统计、打卡规则校验。主线二社交属性。发布跑步动态、好友关注、点赞评论、排行榜、成就徽章。支线个人中心。历史记录、数据总览、设置、意见反馈。这样拆完整个项目的功能边界就非常清楚论文的第二章“需求分析”也能顺理成章地写出来。1.2 为什么选微信小程序而不是App这个问题答辩老师大概率会问必须提前准备好答案。微信小程序相比原生App有几个非常明显的优势尤其在校园场景下第一零安装成本。在校园里让人下载一个App并注册这个门槛比想象中高很多但小程序扫码即用用完即走非常契合低频工具加高频社交的组合场景。第二开发成本低。小程序前端使用WXML和WXSS语法类似HTML和CSS前端基础好的同学很快就能上手。而且微信官方提供了丰富的组件和API定位、地图、登录等能力不用自己从零实现。第三便于社交裂变。小程序天然支持分享到微信群和好友这和项目的社交属性高度契合。跑完步可以把战报分享到群里好友点开就能看到排行榜这种传播路径在小程序里是闭环的。第四账号体系现成。微信小程序可以直接用wx.login获取用户身份不需要自己构建繁琐的注册登录流程这对学生项目来说节省了大量时间。1.3 这项工作量的合理分配拿到题目之后第一步不是写代码而是把工作量摊开看。我给这个项目分的模块占比大概是前端页面和交互占三成后端接口和数据库设计占三成跑步轨迹和地图相关占两成论文和答辩材料占两成。前两个模块是基础第三个模块是技术亮点最后一个模块是毕业设计分数的保障。很多学生容易在前端页面上花太多时间一个按钮的样式调半天结果后端接口没写几个。这个项目一定要控制好节奏第一优先级是把核心业务流程打通用户登录开始跑步记录轨迹结束跑步保存数据查看跑步记录。这条链路通了项目的骨架就立住了。2. 技术方案选型一次跑通前后端的设计决策技术选型决定了开发的舒适度和答辩的含金量。“跑鸭”这套项目选用的组合是微信小程序原生前端 Spring Boot后端 MySQL数据库 微信云开发的部分能力。这套组合是我个人非常推荐的毕业设计搭配原因很简单每一层都有成熟的学习资料和现成的解决方案出了问题网上一定有人踩过同样的坑。2.1 前端原生小程序还是Uniapp做微信小程序有两条主流路线原生开发和使用Uniapp等跨端框架。原生开发虽然写起来代码量稍多一些但优势是直接使用微信官方API没有中间层的性能损耗调试工具里的报错信息也最直观。Uniapp的优势是可以一套代码多端复用但如果是毕业设计精力只放在微信小程序上就够了没必要为了“多端”这个华而不实的卖点增加框架学习的成本。“跑鸭”前端主要用到的能力包括wx.login和wx.getUserProfile实现登录和用户信息获取wx.getLocation和wx.startLocationUpdate实现定位和轨迹采集map组件配合polyline绘制跑步路线canvas或ECharts绘制配速曲线和里程统计图常规的页面栈、组件间通信、数据绑定2.2 后端Spring Boot是这个体量的最优解后端选型上Spring Boot几乎是计算机专业毕业设计的不二之选。它的生态足够成熟网上能找到大量现成的代码片段和踩坑记录而且Spring Boot本身就是主流的工业级框架答辩时提到“使用了Spring Boot MyBatis Plus RESTful API设计”能让评分老师觉得这个项目是正经工程而不是玩具。“跑鸭”的后端结构是典型的Controller-Service-Mapper三层架构。Controller层负责接收请求和返回结果Service层处理业务逻辑Mapper层操作数据库。用户登录后拿到openid后端用openid作为用户唯一标识生成JWT token返回给前端后续请求在请求头中携带token通过拦截器校验登录态。另外这个小程序的跑步数据采集涉及到坐标点的连续上传所以接口设计上需要区分“开始跑步-上传轨迹点-结束跑步”三个阶段。开始跑步时后端生成一条跑步记录状态为进行中跑步过程中前端每隔几秒上报一批轨迹点后端批量插入轨迹点表结束时前端调用结束接口后端计算总里程、时长、配速更新跑步记录状态。2.3 数据库设计六张表撑起所有功能数据库设计是整个项目的地基地基没打好后面全是坑。论文里“数据库设计”这章表格画得好看是加分项但表之间的关系一定要合理。“跑鸭”的后端数据表主要围绕几个核心实体展开整体设计思路比较清晰。用户表存用户的基础信息包括微信openid、昵称、头像、性别、所在学校、当前积分等。跑步记录表是核心业务表记录每一次跑步的起止时间、时长、里程、平均配速、轨迹点的条数、数据创建时间。轨迹点表存储GPS坐标点包含经度、纬度、记录时间和所属的跑步记录ID跑步结束后前端展示的路线就是根据这些轨迹点画出来的。动态表是社交功能的数据基础用户在跑步结束后可以发布动态动态内容包含文字描述和若干张图片。好友关系表用来维护用户之间的关注关系A关注B就在这张表里插入一条记录。评论表和点赞表分别为动态提供评论和点赞功能其中点赞表有用户ID和动态ID两个字段做联合唯一索引防止重复点赞。这几张表合在一起就能支撑起跑步、社交、排行三大核心业务。3. 核心功能模块跑步轨迹与社交互动怎么落地很多人拿到项目源码后最容易卡住的是跑步轨迹相关的那部分代码因为这里面涉及到GPS定位、坐标处理、地图绘制等一系列相对陌生的概念。这也是答辩时最值得讲的亮点。下面逐个把核心模块拆开讲清楚。3.1 跑步轨迹记录距离和配速的算法逻辑跑步记录的核心是轨迹采集。前端在用户点击“开始跑步”后通过wx.startLocationUpdate开启持续定位每隔一定时间间隔获取一次当前坐标把坐标点存到一个数组中同时在地图上绘制出来。这里有几个细节需要特别注意。定位精度的问题。微信小程序的wx.getLocation返回的坐标精度通常在10到50米之间这个误差在校园里会导致轨迹偏移到马路对面甚至楼里。解决办法是一方面开启GPS高精度模式另一方面在绘制轨迹时不把原始坐标点直接连线而是通过清理漂移点、合并近距离重复点等方式做一些预处理。轨迹点之间的间距不均匀也会影响距离计算如果两个相邻点间隔时间较长它们之间的距离会偏大。距离计算不要直接使用两点之间的球面距离公式而是把一系列GPS点当作折线逐段计算两个相邻点之间的球面距离然后累加。球面距离公式可以用Haversine公式计算计算量不大但比直接用欧氏距离准确得多。在“跑鸭”项目里我记得后端在计算总距离时也是用的这个公式前端在跑步过程中显示的是估算值以服务端结算的数据为准。配速的计算是总用时除以总里程常见单位是分钟每公里。这里要特别处理好跑步中暂停的情况如果跑步过程中用户点击了暂停暂停期间的时间不能计入总时长否则配速会异常。3.2 地图轨迹绘制polyline和map组件怎么配合轨迹绘制使用的是微信小程序的map组件。前端在跑步过程中持续更新地图上的polyline线段polyline的points属性接收一个坐标点数组把当前已经采集到的所有轨迹点传进去就能画出路线。绘制时要注意strokeWidth线宽和color颜色可以自定义让轨迹更显眼。一个比较实用的技巧是使用include-points属性来自动缩放地图视野确保整条路线都在可视范围内。如果没有这个设置用户跑远了之后路线会超出屏幕体验很糟糕。轨迹绘制还有一个细节——路线回放。跑步结束后在详情页中查看上一次跑步路线时是按时间顺序把轨迹点逐帧显示形成动画效果。实现方式是定时器每隔几十毫秒往polyline的points数组里追加一个点达到一种动态画线的效果。这个小功能在答辩演示时非常能抓眼球技术上又不复杂强烈建议保留。3.3 社交模块动态发布、点赞评论和好友系统社交模块设计相对标准但有几个坑值得说。动态发布时用户可以选择跑步战报自动生成一张带里程、配速等数据的卡片图也可以选择发布纯文字的普通动态。跑步卡片是用canvas生成图片画一个背景图再把跑步数据绘制上去。这个功能在答辩时看到的人都会觉得挺惊艳因为微信小程序里canvas绘制长图、转换成临时文件、再上传到服务器这个链路踩坑比较多。发布动态的流程是前端把文字内容和图片文件准备好先调用后端的文件上传接口把图片传到服务器的存储目录拿到图片URL后再连同文字一起提交动态发布接口。后端把动态记录存到数据库前端跳转到动态列表页。点赞功能要注意幂等性。用户反复点击点赞按钮前端要禁用按钮后端要对user_id和post_id的联合查询做判断已经点过赞就直接返回不要再往点赞表里插数据。取消点赞和点赞必须是同一套接口用一个type参数区分是添加还是删除。好友关注是典型的关系链功能。关注列表、粉丝列表、互相关注这几个概念要分清楚。跑鸭里的关注关系是单向的A关注B不代表B关注A这个实现起来比较简单。如果要做“互相关注才是好友”逻辑就要复杂一些。3.4 排行榜与成就系统用游戏化的思路留住用户排行榜是社交产品调动用户活跃度的重要机制。跑鸭的排行榜分了两种维度一种是全校园总里程榜一种是好友榜。总里程榜直接查跑步记录表按用户分组求和里程再排序好友榜的SQL稍微复杂一些要关联好友关系表和跑步记录表。为了降低数据库压力排行榜接口会加一层Redis缓存比如每十分钟刷新一次缓存不用每次请求都去全表聚合查询。如果还没引入Redis可以先在Service层加一个本地缓存效果也够用。成就系统是典型的游戏化设计。我在设计时定义了一批成就徽章比如首次完成3公里累计跑步里程达到10公里连续打卡7天在好友榜中成为本周第一等。每次跑步记录结束后后端统一检查这几个成就条件如果某个成就达成就生成一条系统的消息通知。这个逻辑可以抽象成一个独立的成就检查服务便于以后增加新的成就规则。4. 系统的性能优化与小程序的部署上线从本地到生产环境如果只是做个演示用的demo把代码跑起来就够了。但如果希望拿到高分或者小程序真实发布上线运营就必须考虑性能和工程化的一些细节。这部分的经验很多是常规教程里不讲但实际生产环境一定会遇到的问题。4.1 后端接口的并发与响应优化一个典型的毕业设计项目在并发量上其实压力不大但答辩时如果你能主动说出“这里做了XX优化”印象分会好很多。跑鸭后端在两个地方做了优化。数据库层面的索引优化跑步记录表的用户ID和创建时间加了联合索引跑排行榜和查历史记录时速度显著提升没有索引时数据量到两万条以上查询就会明显变慢。接口层面的缓存优化排行榜这类读多写少的数据增加了Redis缓存层。每次排行榜接口请求进来时先查缓存缓存不存在才查数据库并把结果写入缓存设置过期时间。MySQL本身也支持查询缓存但在数据更新频繁的业务中命中率不高所以Redis是更合理的选择。4.2 小程序的包体积优化与加载速度微信小程序主包有大小限制这是很多新手开发者容易忽略的问题。跑鸭项目里如果图片资源做得比较多主包体积很容易超限。解决方法就是拆分分包比如把“动态详情”、“排行榜”、“个人成就”这些二级页面放到分包中主包只保留核心页面。另外图片资源要尽量使用云存储或服务器上的外链而不是把大量图片塞进代码包里。小程序代码包里的本地图片非常占用体积而且无法做CDN加速加载速度也慢。4.3 从开发到上线注册、审核和灰度发布如果项目要正式上线运营还需要走微信小程序的注册、审核和发布流程。这里有一条避坑经验小程序的类目选择要准确否则审核会被驳回。在跑步社交这个场景下选择“工具-健康管理”或“体育-体育赛事”的类目相对稳妥。社交类的功能如果涉及到用户间的内容互动审核会更加严格甚至可能需要提供相关资质所以在设计功能时就要注意规避风险。凡是涉及用户生成内容的模块都要预留内容安全检测的调用在用户发布动态时对文本和图片做合规校验这是审核必查的点。真正发布版本之前强烈建议先通过体验版二维码在真机上跑一遍完整的业务流程用微信开发者工具的“真机调试”功能检查接口请求在真实网络环境下的表现。开发工具里的模拟器环境和真机差异很大尤其是定位、地图、相机这些硬件能力相关的功能在模拟器里一切正常一到真机就容易出问题。5. 论文与答辩材料代码之外的半壁江山毕业设计的成绩由两部分决定代码做出来的系统和写出来的论文及答辩表现。很多学生代码写得不错但论文写得像流水账答辩PPT做得像产品说明书最终得分大打折扣。这套跑鸭项目的论文、答辩PPT、开题报告和任务书都整理完了我按框架讲一下每份材料的组织逻辑。5.1 开题报告和任务书别把目标写得太空开题报告的核心是说明“我要做什么、为什么做、怎么做”。很多学生写开题报告时喜欢堆砌宏大词汇比如“基于互联网的智慧校园健康运动生态系统研究”这种题目把自己架得特别高答辩时老师随便问一个AI里没实现的功能你就下不来台。开题报告里写清楚目标、要解决的核心问题、技术路线和预期成果就行了。在编写时可以按照下面的模板来填充内容项目名称“跑鸭”校园跑步社交微信小程序的设计与实现研究背景写校园跑步的痛点和社交需求研究内容包括微信小程序前端、Spring Boot后端、GPS定位与轨迹绘制、社交功能模块技术路线写小程序原生开发、Spring Boot框架、MySQL数据库预期成果是有完整功能的微信小程序系统加论文。任务书主要是把开发过程拆解成阶段性任务和时间节点比如第一到第二周完成需求分析和原型设计第三到第六周完成前端开发第七到第九周完成后端接口和数据库设计第十到第十一周进行系统联调和功能测试第十二到第十三周撰写论文和制作答辩PPT。这样的安排让老师看完就知道你有完整的项目管理意识。5.2 论文怎么写硕士论文的关键在框架毕设论文的核心框架大体是第一章介绍选题背景和意义第二章做需求分析和技术栈选型第三章是系统设计第四章是核心功能实现第五章是系统测试最后是总结参考文献致谢。这里面的重点是第三章和第四章篇幅要占全文的一半以上。写系统设计这章的时候除了数据库设计、接口设计这些常规内容强烈建议画出系统的功能结构图和业务流程图。功能结构图用树状图的方式呈现整个系统的功能模块业务流程图展示跑步、发布动态这两个核心流程的完整链路。论文里的图和代码注释也是加分项。写系统实现这章的时候关键代码要贴但不要贴大段的、像源代码一样的代码块。挑每个模块最核心的代码片段配上文字解释这段代码实现了什么逻辑、为什么要这么写。比如轨迹距离计算给出Haversine公式的实现代码讲解为什么用球面距离而不是平面距离。5.3 答辩PPT和演讲让老师跟着你的节奏走答辩PPT不要做得太长15到20页最合适。结构上按照这个顺序去组织封面页题目、姓名、指导老师目录页项目背景和意义需求分析系统架构图功能模块介绍核心功能演示关键技术亮点系统测试总结与展望致谢。功能演示这一部分最理想的是录一段真机操作的视频嵌入到PPT里如果条件不允许就准备一个二维码让老师现场扫码体验这种演示效果比放截图好一个档次。答辩演讲的节奏控制在8到10分钟。开场先用两到三句话讲清楚项目解决的问题演示环节是整个答辩的重头戏演示之前先把核心功能的操作路径理一遍保证每一步都不卡壳。到了评委提问环节被问到回答不上的问题要保持冷静坦诚地承认这一块没有深入然后强调项目的设计和实现已经围绕核心目标展开了这个问题可以作为未来优化方向。这种回答方式退一步反而更诚恳。5.4 答辩后的反思答辩结束之后我复盘了整个指导过程整理出几条经验给后续做类似项目的同学参考反复确认核心功能的稳定性和可靠性确保答辩演示的时候不出岔子这是基础系统设计时就要想到论文写作和答辩的展示点比如跑鸭的跑步轨迹和社交互动就是展示亮点提前模拟答辩把老师可能会问的数据库设计、登录鉴权、并发问题都过一遍做到心中有数。6. 运行环境与部署实操本地跑通和部署到服务器的完整记录如果是刚拿到“跑鸭”源码第一步不是急着改代码而是先把项目完整地跑起来。这个过程我能理解因为很多毕设项目给的说明文档不全光是把环境配好就折腾好几天。这里把我在实操过程中记录的完整步骤分享出来。6.1 前端项目的导入和配置用微信开发者工具导入项目时需要填小程序的AppID。如果有自己的小程序账号就用自己的没有的话点测试号也行。导入完成后首先要检查项目根目录下的app.js里的全局配置这里通常保存着后端接口的baseUrl。本地联调的时候这个地址要填成局域网IP比如http://192.168.1.100:8080真机调试时手机和电脑必须连同一个WiFi才能访问到局域网服务。正式上线时再改成服务器的HTTPS域名。在project.config.json中appid字段是必填的如果为空会导致编译失败。另外需要确认项目是否开启了“不校验合法域名”的选项这个选项在开发调试阶段要打开否则请求非HTTPS域名会被拦截。如果项目里使用了分包subpackages字段至少要包含一个分包目录并且主包页面和分包页面的路径不能有重复。6.2 后端项目的配置和启动后端是Spring Boot项目用IntelliJ IDEA打开后需要等待Maven自动下载依赖这一步耗时较长一定要保持网络稳定。核心配置文件application.yml里改三项配置数据库连接信息改成你自己MySQL的地址、用户名和密码文件上传的存储路径改成本地某个磁盘目录如果集成了Redis把Redis的连接配置也一起改掉。首次启动前要先用项目里提供的SQL脚本创建数据库和表结构。用Navicat或命令行执行sql文件注意执行时选择正确的字符集否则中文会乱码。后端启动成功的标志是控制台打印出Tomcat started on port(s): 8080。6.3 前后端联调和常见启动报错联调阶段最常遇到的问题有前端请求报跨域错误解决办法是在后端加一个CORS配置类前端登录失败检查后端日志里openid的获取是否正常小程序AppID和密钥是否匹配地图不显示检查小程序的隐私协议是否已经同意获取位置信息的授权。线上部署的话可以买一台轻量服务器安装JDK、MySQL、Redis、Nginx将后端项目打成jar包用nohup后台运行前端上传到微信公众平台走审核发布流程。如果要在手机上稳定运行后端域名必须备案且配置HTTPS证书这是微信小程序的硬性要求不满足的话真机调试都会受限。本地开发阶段可以跳过这步但临近正式上线时这些合规环节要提前安排好。6.4 数据库初始化与测试账号准备项目里提供一份测试数据会很加分。我在跑鸭的源码包里放了一些模拟的跑步记录和用户数据导入数据库后前端页面上就能直接看到排行榜、动态列表这些效果。如果没有测试数据第一次打开首页只有空荡荡的页面很难判断系统是否正常。要造测试数据直接写SQL脚本往表里插数据就行。比较重要的表是跑步记录表插入记录时要生成合理的时间范围比如一周内的数据里程从2到10公里不等这样才能在排行榜上看到明显的区分度。跑一个批量插入脚本能快速造出几十条数据。7. 个性化改进与功能扩展建议把毕设做出自己的亮点如果直接把源码原封不动交上去虽然能过但分数通常是中等偏上。想拿优秀毕业论文建议在原有功能基础上做一两个有辨识度的扩展。这一步的价值在于答辩时你能说“在这个项目原有的基础上我额外实现了XXX功能”这个表述会让老师对你的评价产生质的变化。7.1 低成本高回报的改进方向最容易做又最容易出效果的改进是视觉层面的。把默认的微信导航栏换成自定义的导航栏在页面上方加入品牌元素和个性化配色整个应用的质感会立刻提上来。另一种是增加一套浅色深色切换的主题模式技术上只是用CSS变量替换硬编码颜色代码量不大但答辩时展示一下效果会很惊艳。数据可视化角度可以增加周报生成功能。跑步记录按周汇总用Canvas生成一张包含总里程、平均配速、运动天数、燃烧卡路里等信息的卡片用户在周日晚上看自己的周报已经成为很多运动App的习惯。跑鸭里把这个功能做成用户主动点击生成和系统自动推送结合体验会非常舒服。7.2 功能层面的进阶扩展把位置定位和路线展示进一步延伸可以做校园跑步路线推荐。后台预先录入几条校园内适合跑步的路线用户选择路线后系统在轨迹绘制上提示偏离路线的情况这个功能在户外跑步场景中很有实用价值。如果后端有一定的算法基础可以增加一个运动状态分析模块。根据跑步过程中采集到的配速变化判断用户是匀速跑还是变速跑给出运动建议。这种基于数据的分析功能在答辩时很容易引起老师兴趣因为它不再是简单的CRUD操作而是有了数据分析和算法在里面。社交层面可以扩展跑团功能。用户可以创建或加入一个跑团跑团有自己的月度总里程目标成员贡献里程数团内有自己的排行榜。这个功能的难点在于跑团与成员的关系设计以及跑团数据聚合查询的性能优化但做出来后整个项目的社交属性就上升了一个层次。7.3 改动代码时的注意事项不管做哪个方向的扩展都建议遵循两个原则保留原有核心代码的稳定性扩展代码尽量以新增模块或新增接口的方式实现不要去动已经调通的模块否则一个小的改动可能导致整个系统崩掉做好版本管理用Git在动手改代码之前建立一个干净的版本标签这样改坏了可以随时回滚到上一版。8. 常见问题与排查技巧实录既然是毕业设计最后再来一部分实操排查的记录。这套东西在开发和测试过程中遇到了不少问题整理出来给后来者排雷。定位不准或者地图白屏这种问题通常会分两个方面去排查。一方面检查代码中是否在app.json中声明了permission字段并且配置了scope.userLocation的说明文字。如果声明缺失隐私弹窗就不会弹出定位权限拿不到。另一方面检查手机本身的定位服务是否打开以及在微信中是否允许小程序使用位置信息。有些手机还要注意如果使用了多个微信账号每个账号的授权状态是独立的。真机调试时接口请求失败最常见的原因是URL地址填错或者是把localhost写死在了代码里。真机调试请求必须填局域网IP地址。另外验证一下手机和电脑是否在同一WiFi下某些校园网和学生宿舍网络会有AP隔离设备之间互相通信不了。地图组件在部分Android手机上不显示这个问题玄学比较多但最集中的原因还是地图组件初始化时拿到的经纬度是空的或者在onLoad完成之前就去渲染地图了。解决办法是在拿到定位结果后再渲染map组件也就是用v-if或者wx:if控制map组件的显示时机。跑步过程中切后台再回前台轨迹断了这是因为小程序在切后台时可能被冻结。解决办法是在onHide里保存最后一个坐标点在onShow里恢复定位并根据时间差决定是否继续当前跑步记录。上传图片时提示“uploadFile:fail”检查上传的URL是否是HTTPS域名以及后端接口是否对文件大小有限制。Spring Boot默认的文件上传大小是1MB如果图片超过1MB会被拦截需要在配置文件中把spring.servlet.multipart.max-file-size和max-request-size改大。启动项目后页面空白控制台报“module xxx is not defined”这通常是引用了某些npm包但没在工具里构建npm或者是分包中引用了主包才能使用的依赖。去详情面板里看本地代码有没有构建npm这一项重新构建一遍。MySQL数据中文乱码检查数据库连接URL是否加了characterEncodingutf8参数以及数据表的字符集是否为utf8mb4。utf8mb4是必选项它能完整支持emoji等特殊字符如果用了utf8就存不进emoji。微信开发者工具导入项目时提示“找不到app.json”检查导入项目时选的是不是项目根目录如果选错了层级的文件夹工具就会找不到入口文件。这个看起来很简单但每年都有学生栽在这上面。登录接口返回的token一直失效检查后端JWT的密钥是否写死且长度足够。如果密钥太短或者每次重启服务都重新生成随机密钥老token自然就会失效。开发阶段把密钥固定下来能省很多事。注意以上环境问题大多涉及本地开发环境。如果换一台电脑部署先检查JDK版本和MySQL版本是否和项目要求一致这两项的版本不一致会导致很多奇奇怪怪的报错。9. 个人复盘与实操心得指导完这个项目之后有几句话想重新强调一下。在整个方案的推进过程中最让我欣慰的不是某个动画效果做得多好也不是排行榜功能用上了Redis缓存而是这套项目把“工具”和“社交”两条线清晰地贯穿到了每一个模块中。跑步记录不是单纯的数据存储而是动态分享的数据来源排行榜不只是一个列表而是驱动用户持续跑步的激励机制。对于正准备做类似毕业设计的同学我的建议其实很朴素先把主流程跑通再谈优化先把基础功能做扎实再做花哨的扩展。跑鸭这套思路里核心价值并不在于用到了多前沿的技术而在于每一步都是“需求驱动设计设计驱动实现”这一点在答辩时反而是最打动老师的地方。如果你手里已经拿到了源码和论文材料千万不要只是解压看一眼就放着。建议花两天时间把项目完整跑起来把每一张表、每个接口对着代码看一遍理解功能之间的数据流转再把论文里的核心章节和自己运行项目的实际体验对应起来。这样到答辩的时候你的从容和自信是会写在脸上的。本文还有配套的精品资源点击获取
