基于物联网的宠物定位监控系统：Spring Boot与微信小程序全栈实战

做毕业设计选题目，最怕的就是名字听起来复杂，做起来更复杂。“基于物联网技术的宠物定位与监控系统设计小程序”这个题目，光看名字就知道覆盖了三块东西：物联网设备端、Java后端、微信小程序前端。对想走Java方向毕设的同学来说，它确实是一个能展示完整前后端能力的好题目，但正因为它横跨了硬件通信、后端服务和前端界面，第一次做的人很容易在“不知道从哪里下手”和“以为很简单结果到处是坑”之间反复横跳。

我现在把这个项目从需求拆解到落地的完整过程梳理一遍，包括技术选型、数据库设计、接口实现、小程序对接、文档整理和常见问题排查。不管你是准备自己开发，还是想拿一套现成的前后端代码改造，这篇文章都能帮你少走不少弯路。

1. 项目全貌与需求拆解

1.1 这个题目在解决什么实际问题

养宠物的人越来越多，但宠物走丢、散养时找不到、上班时不知道宠物在家什么状态，这些都是真实痛点。宠物定位与监控系统的核心目标很直接：让主人能随时知道宠物在哪儿、去过哪儿、有没有离开安全区域。

放到毕设场景里，这句话要被拆成几个具体功能。首先是设备端，需要一个能获取经纬度的定位模块，定时把坐标传回服务器。其次是后端，要接收设备上报的数据，做存储、查询和异常判断。最后是小程序端，用户打开小程序能看到宠物的当前位置、历史轨迹，还能设置一个电子围栏，宠物一旦跑出去就立刻收到提醒。整个链路走下来，Java后端在中间承担了所有业务逻辑和数据处理，物联网技术则承担了“设备与服务器通信”这一层，小程序负责最终的用户交互。

1.2 功能需求边界与角色划分

别一上来就想着把系统做大，毕设最重要的是把边界划清楚。这个题目下通常只需要两类角色：普通用户和管理员。

普通用户端主要做宠物和设备绑定、查看宠物实时位置、查看历史轨迹、设置电子围栏、接收越界告警。管理员端则是用户管理、设备管理、系统日志查看。设备端则需要完成定位、联网、定时上报、低电量上报等动作。如果把这些都做扎实，已经足够支撑一篇有分量的毕业设计了。

有一点容易忽略：设备绑定环节要设计设备编号和设备密钥。宠物定位设备不能随便被人绑定，否则隐私和安全都是问题。我在实际项目中就见过只用一个设备号绑定的案例，结果谁都能查到那个设备的位置，这在校辩时是会被老师抓住扣分的点。合理做法是每个设备出厂时有一个唯一编号和随机密钥，用户通过小程序扫码或手动输入后，后端校验密钥再完成绑定。

1.3 选这个题目的优势与风险点

优势很明显：题目有实际应用场景，技术栈覆盖面广，Java、物联网、小程序、前端后端全都能涉及，写文档时素材也丰富。风险点同样明显：如果学校不提供真实硬件，设备数据怎么做模拟是一个很现实的问题。

我的建议是先把硬件抽象成“数据源”，不依赖真实GPS模块也能把系统跑通。你可以用一个简单的Java程序循环生成经纬度数据，通过MQTT或HTTP模拟设备上报。等系统通了以后，再决定要不要接入真实定位模块。这样既避免了硬件采购周期长的问题，又能把精力集中在核心代码和文档上。

2. 技术选型与核心架构设计

2.1 后端为什么选Spring Boot + MyBatis Plus

Java后端目前最主流的组合就是Spring Boot + MyBatis Plus，毕设选这套方案最大的好处是资料多、社区成熟、遇到问题百度一下就能找到答案。Spring Boot负责接口、事务、参数校验这些基础能力，MyBatis Plus负责数据库操作，尤其是单表CRUD几乎不用写SQL。

很多同学纠结用不用Spring Cloud或者微服务，我的看法是这个题目完全没必要。宠物定位监控系统属于典型的中小型业务系统，单体应用完全能扛住，而且毕设答辩时老师更关心的是你的逻辑是否清晰，不是你的架构是否炫技。用Spring Boot做单体，分模块写清楚Controller、Service、Mapper，反而更容易讲清楚。

MyBatis Plus还有一个很实用的功能是代码生成器，可以自动生成实体类、Mapper和Service。我第一次做这个项目时，光建宠物表、设备表、位置记录表就手动写了一堆重复代码，后来直接上代码生成器，十分钟就把基础架子搭好了。不过要注意，生成器生成的代码只能当基础，复杂的查询和业务逻辑还是需要自己手写。

2.2 设备端定位方案与数据上报链路

宠物定位设备最常见的定位方案是GPS模块，比如ATGM336H这类国产模块，精度在2到5米左右，价格也不贵。但在室内或者遮挡物多的地方GPS信号很差，所以很多商业产品会再加基站定位或WiFi辅助定位。毕设里如果没有实物硬件，可以直接模拟生成一组带经纬度的JSON数据上报。

数据上报链路有两种主流方式。第一种是设备直接通过HTTP POST把位置数据发给后端，优点是简单，缺点是设备电量消耗大，断线重传也麻烦。第二种是使用MQTT协议，设备保持长连接，按固定周期发布位置消息，后端订阅消息后写入数据库。MQTT是物联网领域非常常用的协议，在文档里能写的东西也更多，我建议优先考虑。

说一个实际经验：MQTT消息体最好直接设计成JSON，比如{"deviceId":"P001","latitude":31.2304,"longitude":121.4737,"speed":2.5,"battery":87,"timestamp":1710000000}。这样后端解析方便，小程序端拿到数据也可以直接使用。上报周期一般设置10秒一次比较合理，太频繁增加电量和带宽压力，太稀疏轨迹会有明显的拖影。

2.3 小程序端技术选型与权限申请

小程序端选择原生微信小程序即可，不用额外上uni-app之类的跨端框架。原因很简单：这个项目只需要运行在微信上，原生框架天然支持地图组件和微信授权，问题更少。地图方面可以直接用微信小程序的map组件，它支持将经纬度标记为位置点，也能绘制圆形覆盖物来表示电子围栏。

需要提前申请两个核心权限：位置权限和用户信息权限。位置权限用来获取用户当前所在位置，方便在地图上定位到自己和宠物；用户信息权限用来完成登录和绑定。这里要提醒一下，从微信官方调整之后，直接用wx.getUserProfile拿用户信息需要在用户明确点击按钮后触发，不能一进页面就弹窗，所以小程序页面要给一个“授权登录”按钮作为入口。

地图显示时还有一个容易被忽略的小问题：map组件的经纬度参数格式是“纬度在前，经度在后”，和后端很多接口习惯的“经度、纬度”顺序不一致。如果你在后端存的是经度在前，返回给小程序时一定要重新组装好，否则地图上的点会跑到完全不一样的位置。

2.4 整体架构的层级关系

这个项目的整体架构可以分成四层。设备层是宠物定位设备或数据模拟程序，负责采集位置信息。网络传输层使用MQTT协议将数据上报到消息服务。平台层是Spring Boot后端，负责接收数据、业务处理、数据库读写。应用层是微信小程序，负责展示地图、轨迹、告警信息。

四层之间的关系要理顺：设备不直接访问小程序，小程序也不直接连接设备，所有交互都通过后端转发。这样做的最大好处是责任清晰，同一份位置数据既可以被小程序读取，也可以被后端做电子围栏判断，还能在将来扩展短信通知、推送通知等提醒方式。答辩时把这个结构画出来，老师基本一眼就能看出你对项目的整体掌握程度。

3. 核心模块落地：从代码到调试

3.1 数据库表设计：一次建表踩坑经历

数据库表设计是这个项目的地基，我见过不少同学先写代码后建表，结果后面改字段改到崩溃。我建议先按以下核心表设计：用户表user、宠物表pet、设备表device、宠物设备绑定表pet_device、位置记录表location_record、围栏表fence、告警记录表alert。

位置记录表是最关键的一张表，字段至少包括id、device_id、latitude、longitude、speed、direction、battery、report_time、create_time。这里要特别强调一下索引。我第一次建表时只在主键上建了索引，结果查询历史轨迹时数据量大一点就明显变慢，后来给device_id和report_time加了联合索引，查询速度立刻上来了。建表SQL类似这样：

CREATE TABLE location_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id VARCHAR(32) NOT NULL, latitude DECIMAL(10, 6) NOT NULL, longitude DECIMAL(10, 6) NOT NULL, speed DECIMAL(5, 2) DEFAULT 0, direction INT DEFAULT 0, battery INT DEFAULT 100, report_time BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_device_time (device_id, report_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

经纬度字段一定要用DECIMAL(10, 6)，不要用浮点类型直接存。浮点的精度误差虽然看起来很小，但在地图上偏差可能达到几十米，位置数据最忌讳这种误差。另一个坑是温湿度这类传感器字段可以预留，但不要一开始就设计太多冗余字段，否则后面文档写起来会很乱。

3.2 后端关键接口实现与参数计算

后端接口按功能可以分成三大类：设备上报接口、小程序查询接口、围栏告警接口。

设备上报接口是数据入口，设计时要有设备鉴权。设备通过HTTP或MQTT上报时，携带设备编号和密钥，后端先校验设备状态是否正常，如果设备未绑定或密钥错误，直接返回错误并记录日志。校验通过后再解析位置数据，写入location_record表。这个接口可以用Spring Boot的@RestController实现，但需要注意异步化处理，避免高频上报时阻塞主线程。

查询实时位置时，小程序请求后端接口，后端查询该设备最新一条位置记录返回。有没有更快的方式？有，可以用Redis缓存最新位置，每次上报时除了写MySQL，同时更新Redis中对应设备的坐标。这样查询实时位置不需要走数据库，响应速度会明显提升，也方便扩展。很多商业定位平台都是这么做的。

电子围栏判定算法这里单独说一下。宠物不超出围栏的判断原理很简单：围栏是圆心加半径的圆形区域，计算设备经纬度和圆心之间的距离，如果距离大于半径就触发越界告警。两点经纬度距离用Haversine公式计算，公式不复杂，网上也有很多现成实现。我直接把关键逻辑封装成一个工具类：

public static double distance(double lat1, double lng1, double lat2, double lng2) { double R = 6371000; double dLat = Math.toRadians(lat2 - lat1); double dLng = Math.toRadians(lng2 - lng1); double a = Math.sin(dLat / 2) * Math.sin(dLat / 2) + Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * Math.sin(dLng / 2) * Math.sin(dLng / 2); return 2 * R * Math.asin(Math.sqrt(a)); }

这个方法的返回值单位是米。判断越界时还要加一个“缓冲距离”，比如围栏半径500米，实际触发阈值为520米。不做缓冲的话，宠物在围栏边界徘徊时会反复触发告警，一天能给你发几十条消息，这在演示时非常尴尬。

3.3 小程序端页面与逻辑

小程序端我按四个页面来规划：首页地图页、宠物列表页、围栏设置页、个人中心页。

首页地图页是核心页面，显示宠物当前位置，用户点击宠物头像可以切换查看不同宠物。小程序原生map组件支持多个标记点，把当前宠物设备的最新经纬度设为地图中心，再显示一个宠物图标和名称即可。历史轨迹可以用polyline组件实现，把一段时间内的坐标点按时间顺序连接成一条线，视觉上很直观。

围栏设置页需要用到圆形覆盖物。用户通过地图选点确定围栏中心，再设置半径，点击保存后请求后端接口写入围栏表。这里有一个交互细节：地图上的围栏最好要用拖拽式更新，用户拖到新位置再松手，而不是只能填写数字。拖拽交互在毕设演示时观感好很多，老师也会觉得你想得比较周到。

小程序端还要处理用户的登录和授权流程。我建议使用微信的wx.login获取code，然后传给后端换取用户身份会话。不要在小程序端把设备密钥明文写在本地，设备绑定和登录信息都要通过后端中转，这也是安全方面的加分项。

3.4 工程结构组织和交付物整理

一份完整的毕设交付物，通常包含三部分：Java后端工程、微信小程序工程、说明文档和LW。后端工程建议按标准Maven结构组织：controller、service、mapper、entity、dto、config、utils等包分开。小程序工程则按pages、components、utils、api等目录组织。

我踩过的一个教训是后端代码里千万不要写死数据库账号密码和MQTT服务器地址，这些应该放到application.yml配置文件中，并且至少在文档里说明如何修改。如果代码都写死，别人拿到的项目根本没法直接运行，调试定制也会很麻烦。

说明文档这里多说一句：很多同学把精力全放在代码上，最后文档只用了一天凑出来，这非常可惜。一份好的说明文档应该包含环境准备、数据库脚本、启动步骤、功能说明、接口文档、常见问题六个部分。写清楚这些内容之后，调试定制甚至二次开发都会快很多，后面我详细展开讲。

4. 从“能跑”到“能答辩”：文档、LW与演示的打磨

4.1 说明文档里必须有的四类内容

说明文档是这个项目交付物里最容易拉开差距的部分。我见过很多同学的说明文档只有一句话“运行main方法即可”，这完全不合格。真正让人拿到手就能跑起来的说明文档，至少要包含四类内容。

第一类是环境配置清单，包括JDK版本、Maven版本、MySQL版本、Redis版本、微信小程序开发者工具版本、MQTT服务端软件版本。这些版本信息看似啰嗦，但能解决大量环境冲突问题。第二类是启动步骤，要从克隆代码开始讲起，到导入数据库脚本、修改配置文件、启动后端、启动小程序、配置微信开发者工具的合法域名，一步步写清楚。

第三类是接口文档，可以按模块列出所有API，包括请求方法、路径、参数、返回结果示例。这个不仅方便自己调试，也是答辩时老师很喜欢看的内容。第四类是常见问题，把设备上报不到、小程序地图不显示、数据库连接失败这些典型问题写出来，体现你的问题排查能力。这四类内容加起来，说明文档基本上就完整了。

4.2 LW写作与代码实现的对应关系

LW这块每个学校要求不同，但大体上要围绕题目展开。毕设论文和代码不是两套东西，而是强对应的关系。写系统设计章节时，可以先画系统架构图，再对照着说明每层用了什么技术、为什么这么选。不要通篇都是理论，老师更想看到你结合宠物定位场景的具体设计。

有一个很实用的技巧：每完成一个功能模块，就顺手记一笔这个模块的逻辑、遇到的问题、解决办法。不要攒到最后统一写。比如电子围栏缓冲距离这个细节，当时在真实调试中发现误报很多，加了20米的缓冲之后告警才正常。这种“发现问题—分析原因—解决问题”的过程，写在论文里是非常加分的，也完全符合工程实践的真实逻辑。

4.3 调试定制与二次开发建议

很多的毕设项目代码拿到手后并不是一键就能跑，所谓的调试定制就是针对自己的设备、接口和需求做适配。首先要把配置和环境统一起来，尤其是数据库版本和小程序基础库版本。其次要把模拟数据改成真实硬件数据，如果学校给了定位模块，可能需要调整上报格式和解析逻辑。

二次开发的话，我个人建议优先做三个方向。第一个是告警通知渠道拓展，把单纯的站内消息升级为微信订阅消息或邮件通知。第二个是历史轨迹回放功能，用时间轴播放宠物的移动过程。第三个是设备离线判断，超过一定时间没有上报数据就标记为离线状态并提醒用户。这些方向实现难度不大，但能让系统的完整度提升一个档次。

5. 常见问题与排查技巧实录

5.1 小程序连不上后端接口

这是这个项目最高频的问题。打开小程序开发者工具，预览时能加载页面，但接口请求一直失败。问题基本出在域名和网络配置上。本地调试时，后端跑在本机，小程序请求地址要写成类似http://localhost:8080，但真机预览时localhost指的是手机本身，而不是你的电脑，所以要用电脑的局域网IP。

另外微信小程序要求请求域名必须是HTTPS且备案过的。开发阶段可以勾选开发者工具里的“不校验合法域名”，但真机预览需要把后端服务部署到云服务器，配置好HTTPS域名，或者至少保证局域网环境下网络互通。如果接口请求返回403或404，还要检查后端的跨域配置。Spring Boot里允许跨域需要在配置类中注册CorsFilter或使用@CrossOrigin注解，否则小程序请求会被拦下来。

5.2 位置上报丢失或定位明显偏移

位置上报丢失最常见的原因是上行消息QoS设置不对。MQTT有QoS0、QoS1、QoS2三个等级，QoS0最快但可能丢消息，QoS1保证至少到达一次，这个项目用QoS1就够了。还有一点是设备端的发送周期和后端接收处理要保持节奏一致，不要出现后端还没来得及写到数据库，设备连续上报了两条，导致其中一条被覆盖。

定位偏移则通常是坐标系问题。国内地图使用GCJ-02坐标系，而GPS设备输出的是WGS-84坐标系，两者之间相差几百米甚至更多。小程序的地图组件默认使用GCJ-02，所以后端或小程序端必须做一次坐标转换。我建议在后端统一转换后再存库，这样小程序端拿到的直接就是正确坐标。原始WGS-84坐标不要覆盖保存，方便以后做对比。

5.3 电子围栏频繁误报

围栏频繁误报除了算法缓冲距离不够之外，还有一个常见原因是位置数据本身抖动。设备在静止状态下，GPS坐标也会在一两米范围内来回跳，如果围栏边界很小，就很容易触发误报。解决办法是在围栏判断前加一个过滤：连续三次上报都超出围栏才真正触发告警，而不是每次只要越界就立刻告警。

还有一个思路是把围栏从圆形扩展成多边形，支持用户在地图上画出任意形状的安全区域。多边形围栏的判断算法相对复杂一些，但也能实现。我在做这个扩展时用的是射线法，把点位与多边形边界进行比较，代码量不大，但功能看起来专业很多。

5.4 环境与版本类问题

Java项目最容易出问题的就是JDK版本不匹配。Spring Boot 2.x一般要求JDK8或JDK11，Spring Boot 3.x要求JDK17，如果代码是用高版本写但本地装了低版本，启动时就会报UnsupportedClassVersionError。解决方式很简单，统一JDK版本，最好在pom.xml里明确指定java.version。

MySQL数据库也容易在字符集上出问题。中文乱码很多时候是数据库和连接串没有指定utf8mb4字符集。另外，如果使用的是MySQL 8.x，驱动类名和方言配置都和5.x不一样，我在第一次适配时也被这个坑过。检查application.yml里的driver-class-name是不是com.mysql.cj.jdbc.Driver，以及连接串是否带useUnicode=true&characterEncoding=utf8，大部分中文乱码问题都能解决。

5.5 避坑清单速查

下面这个表格是我在实际调试过程中总结出来的高频问题速查，建议直接保存下来对照检查：

这个表在做技术分享或写LW时可以直接复用，每一行都对应一个真实排查过程，比空泛的“提高系统稳定性”有说服力得多。

我个人在实际项目里的体会是，这类物联网毕设最难的不是某一个技术点，而是把设备、后端、前端串起来的过程。每一条数据从生成到上报，再到存储、查询、展示，链路里任何一个环节出错，结果都是功能不可用。但只要你把这条链路拆细，一层一层去验证，问题并不难定位。如果你也在做这个题目，希望这份踩坑记录能帮你省下几个通宵。