做毕设最怕的不是代码写不出来，而是东西做完了，导师一问“为什么选这个方案”就直接卡壳。这个“基于物联网技术的宠物定位与监控系统设计小程序”属于典型的软硬结合方向，既能体现嵌入式端的数据采集能力，又能展示小程序端交互和云端的通信设计，整体完成度高、扩展空间大，在物联网毕业设计里一直是很稳的一个选题。这篇就围绕这个项目，把从硬件选型到小程序端开发，再到论文撰写和远程调试交付的完整链路拆开讲清楚。无论是准备开题、正在开发，还是已经写完代码准备补文档，都可以对照着查缺补漏。
1. 项目整体设计与技术选型思路
1.1 为什么是“物联网+小程序”的组合
先解决一个很多人会忽略的问题：为什么这套系统要拆成“物联网设备”和“微信小程序”两个部分，而不是做一个传统的App或者纯网页？
宠物定位与监控的核心场景是“随时随地看一眼”。以App为载体会被迫开发iOS和Android两套客户端，工作量直接翻倍；纯网页方案在手机端体验又不够顺滑，定位刷新也不方便。微信小程序天然跨平台，用户不需要额外下载安装，扫码就能用，对这个场景是体验和成本的最优平衡点。
物联网端负责数据采集和指令执行，解决的是“真实世界”的问题：GPS定位、温湿度采集、设备状态回传、远程开关控制。小程序端负责展示与交互，解决“人”的问题。两者通过云端MQTT服务连接起来，形成一个“设备→云端→小程序”的完整闭环。这个组合还有一个额外好处：论文里能写“端、云、边”三层架构，技术上更丰满，答辩时更好讲。
1.2 系统架构与数据流
整体架构可以拆成三层来理解。
感知层就是硬件端，包含主控芯片、GPS模块、温湿度传感器、按键、LED指示、电池电源管理。这一层干的事是“采集”和“执行”。
传输层是物联网通信的核心，我用的是MQTT协议。设备端通过Wi-Fi连接到网络，把位置、温度、电量这些数据打包成JSON格式，再发布到云端指定的Topic。小程序端和云端订阅这些Topic，数据就可以实时双向流动。
应用层就是微信小程序。用户在小程序里绑定设备后，可以查看地图定位、环境数据、设备在线状态，也可以反向发送指令，比如开启电子围栏、远程重启设备、调整上报频率。
数据流向分上行和下行两条。上行是设备定时上报位置和环境数据，小程序实时展示；下行是用户在小程序里操作，指令经云端下行到设备端，设备端解析执行后回传一个确认状态。这上下两条链路能跑通，系统才算完整。
1.3 关键技术选型对比
选型这块最容易踩坑，我把核心几个决策点列出来，都是实际对比过的经验。
定位方案，可以选GPS模块、Wi-Fi定位、基站定位。室外空旷环境GPS精度能到3到5米，但室内会丢星；Wi-Fi定位和基站定位适合城市和室内，精度几十米到几百米不等。这个项目我建议以GPS模块为主，配合小程序端腾讯地图的逆地址解析，在城市楼宇密集时会自动降级到Wi-Fi/基站辅助定位，体验会好很多。
主控芯片，ESP8266和ESP32是两条主流路线。ESP8266便宜、资料多、做毕业设计完全够用，缺点是IO口和运算能力有限。ESP32性能更强，自带蓝牙和更多外设接口，后期如果想扩展摄像头或者语音模块，空间更大。预算允许的话直接上ESP32，功耗控制和扩展性都优秀。
数据通信协议，我首推MQTT而不是HTTP。HTTP有大量冗余头，而且服务端不能主动推送数据，小程序端想看实时定位只能轮询，既浪费流量又不够实时。MQTT基于发布/订阅模式，消息体积小，支持QoS质量等级，服务端能主动推数据，天然适合低带宽、不稳定网络的物联网场景。
云端服务，很多人第一反应是自己搭服务器部署EMQX。毕业设计不建议这么做，因为需要域名备案和公网IP，麻烦还烧钱。更稳的方案是直接用微信小程序云开发的IoT能力，或者用EMQX Cloud免费版、阿里云物联网平台这类全托管的MQTT服务，免费额度完全够毕设演示。
2. 硬件端设计与实现
2.1 主控选型与传感器搭配
硬件端模块选型直接决定系统的稳定性。我在这套系统里用的主控是ESP32开发板，核心板选带USB转串口芯片的版本，方便烧录和查看日志。
GPS模块用的是ATGM336H，北斗和GPS双模，冷启动时间大概30秒左右，定位精度在2.5米以内，价格几十元，性价比很能打。如果你手头是NEO-6M或者NEO-8M也能用，需要注意NEO-6M冷启动比较慢，调试时要有耐心。
温湿度传感器用DHT11或者DHT22都可以。DHT11的精度是±2℃，湿度±5%，够用了；DHT22精度更高，功耗也更高。这个项目里温湿度是辅助监控数据，用DHT11完全足够。
显示模块属于加分项。手头有OLED屏幕（0.96寸I2C接口）就接一块，可以在屏幕上显示设备状态、定位信息、当前温度，实物演示时屏幕一亮，效果直接不一样。如果没有也不影响核心验收。
还有一个容易被忽略的模块是电源。整套系统的功耗大头在GPS和Wi-Fi模块。我推荐用18650锂电池加TP4056充电模块给设备供电，正常工作电流在80到150毫安左右，一块2000mAh电池续航十几个小时没问题。如果想做低功耗优化，后面单独讲。
2.2 核心代码实现（示意）
硬件端的核心逻辑很简单：初始化各模块，连接Wi-Fi，连接MQTT，进入主循环。在主循环里定时读取GPS坐标和温湿度，然后打包成JSON上报到云端。为了保障代码可读性，建议把各部分拆成独立模块。下面是一段示意结构，实际代码可以在此基础上拆得更细。
#include <WiFi.h> #include <PubSubClient.h> #include <TinyGPS++.h> #include <DHT.h> const char* ssid = "your_wifi_name"; const char* password = "your_wifi_password"; const char* mqtt_server = "your_cloud_mqtt_broker"; const int mqtt_port = 1883; const char* topic_pub = "device/pet_001/data"; const char* topic_sub = "device/pet_001/cmd"; WiFiClient espClient; PubSubClient client(espClient); TinyGPSPlus gps; DHT dht(4, DHT11); void setup() { Serial.begin(115200); dht.begin(); setupWifi(); client.setServer(mqtt_server, mqtt_port); client.setCallback(callback); } void loop() { if (!client.connected()) reconnect(); client.loop(); if (millis() - lastSend > sendIntervalMillis) { sendSensorData(); lastSend = millis(); } } void sendSensorData() { float lat = gps.location.lat(); float lng = gps.location.lng(); float temp = dht.readTemperature(); float humi = dht.readHumidity(); char payload[256]; snprintf(payload, sizeof(payload), "{\"deviceId\":\"pet_001\",\"lat\":%.6f,\"lng\":%.6f,\"temp\":%.1f,\"humidity\":%.1f,\"battery\":%d,\"ts\":%lu}", lat, lng, temp, humi, batteryLevel, millis() / 1000); // ts可替换为NTP时间戳 client.publish(topic_pub, payload); }这段代码有几个值得注意的细节。TinyGPS++库解析GPS数据是流式的，必须持续给feed数据才能获得有效坐标，所以loop里会有一个串口读取的gps.encode(Serial.read())操作，上面简化了但要补上。上报频率上，定位数据建议5到10秒一次，温湿度可以30秒一次，这个频率既满足监控需求，也不会给云端和小程序造成压力。
2.3 功耗与稳定性处理
硬件端最容易翻车的不是功能实现，而是供电和功耗控制。设备如果充电后一两个小时就没电，演示时断电或者重启，会被导师当场打低分。实测下来要注意这么几点：
第一，Wi-Fi连接稳定是省电的前提。ESP32的Wi-Fi在信号弱时会出现反复重连，功耗飙升。代码里要做好重连退避，比如重连失败后延迟5秒再试，而不是陷入死循环。第二，GPS天线不能和Wi-Fi天线靠太近，否则会互相干扰，定位时间明显变长。第三，长时间运行时SHT等待或阻塞串口会导致主循环卡死，如果发现设备几分钟后没数据，先在代码里加看门狗定时器自动重启。
低功耗优化是加分项。可以开启ESP32的deep sleep模式，每次唤醒后采集一次数据并上报，然后继续休眠。实测这种模式下平均电流能降到几十毫安，电池续航翻好几倍。论文里如果加一节“低功耗设计”，前瞻性会更好。
3. 小程序端核心功能开发
3.1 设备绑定与MQTT连接
小程序端的设计我分两个阶段来推进：先打通基础链路，再逐步加功能。基础链路是“打开小程序→绑定设备→收到第一条实时数据”。
设备绑定我用的是设备ID加一个自定义密钥，类似设备证书。用户在绑定时输入设备包装或硬件端OLED屏上显示的6位密钥，小程序把设备ID和密钥存一份到云数据库，同时建立映射关系。这样做的好处是：即使MQTT的Topic被其他人猜到了，没有密钥也订阅不到实时数据。
小程序端最核心的连接是MQTT over WebSocket。微信小程序本身不支持原生TCP Socket长连接，所以需要用MQTT.js库，通过WSS协议连接云端Broker。如果用的是微信云开发，可以直接用云开发自带的物联网能力，封装了设备端和小程序端的通道，开发量会小不少。下面是基于MQTT.js连接云端的示意：
const mqtt = require('mqtt/dist/mqtt.min.js'); const client = mqtt.connect('wxs://your-broker-url/mqtt', { username: 'your_username', password: 'your_password', clientId: 'wx_' + Date.now() }); client.on('connect', function () { console.log('MQTT connected'); client.subscribe('device/pet_001/data', { qos: 1 }, function (err) { if (!err) { wx.showToast({ title: '连接成功', icon: 'success' }); } }); }); client.on('message', function (topic, message) { const data = JSON.parse(message.toString()); updateMapMarker(data.lat, data.lng); updateTemperature(data.temp, data.humidity); updateBattery(data.battery); });这里有一点很重要：小程序端的WebSocket连接必须在真机调试时把域名加入白名单，否则大概率连不上。开发阶段可以在开发者工具里勾选“不校验合法域名”，但这只能应急，正式演示前一定在白名单里配好服务器域名。
3.2 实时定位与地图展示
定位信息展示用微信小程序的map组件。这个组件原生支持marker标记点、polyline轨迹线、moveAlong动画，基础功能足够，不需要再引第三方地图SDK。
地图页的核心逻辑是：监听MQTT消息中的经纬度，调用mapContext移动标记点，同时在大屏顶部显示当前的“详细地址”。经纬度转地址是通过腾讯位置服务的逆地址解析接口实现的，没有它，用户只看经纬度根本不知道宠物在哪儿。这里附一段关键代码：
const qqmap = require('../../utils/qqmap-wx-jssdk.min.js'); const demo = new qqmap({ key: 'your_tencent_map_key' }); demo.reverseGeocoder({ location: { latitude: data.lat, longitude: data.lng }, success: function (res) { that.setData({ address: res.result.address }); } });地图刷新频率要看具体场景。宠物在室外跑动时，5秒一刷的变化感很明显；如果静态展示，30秒一刷也够。建议给用户做一个“刷新频率”设置项，在小程序里可以切换低中高三档，这样既灵活又能在答辩时展示你的交互细节。
3.3 历史轨迹与远程控制
历史轨迹回放是毕业设计和普通课设拉开差距的功能点。实现思路很简单：设备端每次上报坐标时，云端数据库存一条带时间戳的记录；小程序端的历史轨迹页按时间范围查询记录，把坐标数组传入map组件的polyline属性，绘制一条完整轨迹。
我建议用云数据库的聚合查询，按时间升序取出某设备某天的所有坐标，最多保留2000个点。数量再多会影响小程序端绘制性能，可以在查询时做间隔抽样，比如每5条取1条。回放功能需要做一个进度条，点击播放按钮后定时器不断更新当前显示的坐标点，实现动画效果。这块答辩时演示效果极佳。
远程控制做三个功能就够：远程布防/撤防，远程重启设备，远程调节上报频率。实现路径是首页发送指令到下行Topic：device/pet_001/cmd，设备端订阅该Topic后解析指令并执行。指令格式统一用JSON，比如：
{ "cmd": "set_interval", "param": 10 }远程控制里还要加一个电子围栏功能。用户在地图上画一个以当前位置为圆心、半径500米的围栏。服务端判断设备上报的GPS坐标到圆心的距离，如果超出半径就推送告警通知到小程序端。距离计算用Haversine公式，误差可以控制在几十米内。这里放一段核心判断逻辑：
function getDistanceFromLatLon(lat1, lng1, lat2, lng2) { const R = 6371000; const dLat = deg2rad(lat2 - lat1); const dLng = deg2rad(lng2 - lng1); const a = Math.sin(dLat / 2) * Math.sin(dLat / 2) + Math.cos(deg2rad(lat1)) * Math.cos(deg2rad(lat2)) * Math.sin(dLng / 2) * Math.sin(dLng / 2); const c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)); return R * c; } if (distance > fenceRadius) { sendAlert('宠物已超出电子围栏'); }这个功能实现简单，但用户价值特别直观，非常适合写到论文的“系统功能设计”里。
4. 云端通信、数据存储与监控逻辑
4.1 为什么选MQTT而不是HTTP
很多人在答辩时会被问到一个很常见的问题：为什么设备上报数据要用MQTT，不能用HTTP发送POST请求吗？这个问题如果答不好，项目档次会被拉低。
核心原因有三个。第一是网络开销差异。HTTP每个请求都要携带Request Header和Response Header，动辄几百字节，而MQTT的固定报文头最短只要2字节，在嵌入式设备上优势非常明显。第二是实时性。MQTT是长连接加服务端主动推送，设备数据一变，小程序端毫秒级就能收到；HTTP只能客户端不断轮询，轮询频率高了浪费资源，低了就不实时，两头不讨好。第三是设备通信的异步性。设备上报一条数据后，并不需要关心有没有人“正在看”，MQTT的发布/订阅模型天然支持这类异步解耦。
如果导师问MQTT的QoS等级，你要记住：QoS 0是最多一次，适合温湿度等可丢数据；QoS 1是至少一次，会重发但可能重复；QoS 2是恰好一次，性能开销最大。定位数据一般用QoS 1，既保证不丢又不会太消耗带宽。
4.2 消息格式与生命周期设计
消息格式是系统设计里最容易被忽略却至关重要的一环。前后端数据结构不统一，代码联调起来就是灾难。我在这套系统里统一用JSON格式，设备端、云端、小程序端共用同一套字段定义。
设备上报的消息示例：
{ "deviceId": "pet_001", "type": "telemetry", "lat": 31.230416, "lng": 121.473701, "temp": 26.5, "humidity": 58.0, "battery": 78, "signal": -65, "ts": 1701314567 }控制指令的消息示例：
{ "deviceId": "pet_001", "type": "command", "cmd": "set_interval", "param": 15, "ts": 1701314600 }后缀“_data”的Topic承载设备采集数据，“_cmd”的Topic承载用户操作指令。这样分开后，权限管理更清晰：小程序用户只能订阅自己的设备Topic，不能订阅别人设备的Topic。云端做规则引擎时也可以按Topic前缀转发到不同业务处理模块。
消息的时序问题也要提前想清楚。设备重启后上报的第一条数据往往还带着上一次的旧定位，小程序端收到后如果直接展示，用户会看到定位“跳回原地”。解决办法是加一个上报时间ts，小程序端丢弃超过当前时间5秒的旧数据，或者用MsgId做幂等处理。这些小细节写进论文能看得出你考虑过生产环境问题。
4.3 数据存储与告警逻辑
云端数据存储的选型，毕业设计不用搞得太复杂。如果用的是微信云开发，直接使用云数据库的集合即可，每条定位记录对应一个document，字段包含deviceId、lat、lng、temp、humidity、battery、ts。如果自己搭建后端，用MySQL或MongoDB都行，MySQL需要提前设计表结构，MongoDB存JSON更省事。
我推荐一个成本低且答辩有说服力的存储方案：在云端采用“最新状态表+历史轨迹表”双表结构。最新状态表只存每个设备最后一次上报的坐标和电量，小程序首页打开时秒查秒显；历史轨迹表按时间序列存每次上报的位置。这个设计非常实用，首页不需要遍历历史表，响应速度快，而且能体现数据库设计功底。
告警逻辑上，除了电子围栏，还可以加低电量提醒和设备离线提醒。低电量提醒很简单，设备端电量低于20%时上报一条告警类型消息；离线提醒则是在云端做一个“心跳检测”，超过3个上报周期没收到设备消息，就判定设备离线，小程序端展示离线状态并推送告警到服务通知。实时定位、历史轨迹、离线和低电量告警全部到位后，这套系统的功能完整度完全可以支撑起一份优秀的毕设答辩。
5. 毕业设计文档与远程调试交付
5.1 文档要写什么才算完整
毕设项目交付时，源码只是其中一部分，更关键的是论文和设计文档。很多同学代码能力强，但文档写得一塌糊涂，最后分数被拉低，很亏。按照这套系统，文档至少需要覆盖以下几个章节：
第一章引言，写研究背景和意义。开头可以写宠物数量和智能硬件的发展，但不要空谈，要落到实际场景：现在城市养宠人群增长，宠物走失、独自在家时的安全问题突出，基于物联网的定位监控系统有明确的应用价值。
第二章系统需求分析，分功能需求和非功能需求。功能需求包括定位采集、数据上报、实时展示、轨迹回放、阈值告警；非功能需求包括实时性（数据延迟小于5秒）、可靠性（断线重连机制）、安全性（设备认证与权限隔离）。
第三章系统设计，画系统架构图、功能模块图、数据库表设计、通信协议设计。这一章是论文的核心，要把硬件端、云端、小程序端的设计思路全部体现出来。
第四章系统实现，按模块贴关键代码并解释实现思路。注意不要大段大段贴完整代码，贴核心函数加注释就够了，导师要的是你理解代码而不是会复制代码。
第五章系统测试，设计测试用例并附测试结果截图。包含功能测试（定位是否准确、告警是否触发、远程控制是否生效）、性能测试（上报时延、并发在线数）、稳定性测试（连续运行7天是否稳定）。这里如果能贴一组“设备离线恢复时间测试”的数据，会很有说服力。
5.2 远程调试的实战意义
“远程调试”这四个字看着简单，实际操作里是最考验项目完善度的环节。毕业设计交付时，开发者和客户或导师常常不在同一个局域网，甚至不在同一个城市。这时候远程调试能力直接决定你交付效率高不高。
这里的远程调试包含三个层面。第一个层面是代码级的远程调试：在你的开发环境下，通过端口映射工具把本地的调试端口暴露到公网，让远端设备连接到你的本地服务。这个方案适合调试小程序端和本地服务的交互，但要注意安全问题，用完立刻关闭映射。
第二个层面是设备级的远程调试：硬件端接入云平台后，通过云平台的日志服务远程查看设备上报记录和离线记录。这种调试方式不依赖物理位置，只要能联网就能查。实测中几乎80%的问题都能从云端日志里找到原因，比串口线方便太多。
第三个层面是云端的远程监控：把设备端和云端的关键日志统一打到日志服务里，再设置关键字告警，比如“error”“disconnect”。这样哪怕设备在千里之外，只要出问题你也能第一时间收到提醒并远程查看现场日志。
远程调试验证通过的另一个作用是“拔掉串口线测试”。很多同学依赖串口监视器调试，一拔串口线设备就罢工。建议在交付前做一次完全脱离串口线的测试，只通过Wi-Fi和云平台来确认设备是否正常工作，这一步能筛掉大量隐蔽问题。
5.3 源码管理是所有交付的基础
源码交付不是把文件夹打个压缩包发过去就完了。一份好的源码交付，需要满足“拿来就能跑、注释能读懂、文档能对应”三个标准。
首先用Git管理整个项目，仓库里至少分三个目录：hardware（硬件端工程）、miniprogram（小程序端源码）、docs（论文和文档）。提交时写好Commit Message，比如“feat: 增加电子围栏功能”“fix: 修复GPS冷启动时坐标跳变”，这些细节导师都看得到，也方便你后续回溯问题。
其次在源码里写清楚README。README要包括以下内容：项目介绍、系统架构图、硬件连接表、依赖环境配置（ESP32开发环境怎么装，小程序开发者工具怎么配）、部署步骤、常见问题。不要觉得README无所谓，答辩时导师给源码时，第一眼就是看README。
最后是环境依赖的说明。很多工程在别人的电脑上跑不起来，就是因为依赖没有固化。硬件端的Arduino库版本要在requirements里列清楚，小程序的npm包最好把package-lock.json一并提交，云端资源初始化脚本也要放到scripts目录下。做到这些，你的项目在导师机器上就能顺利复现。
6. 常见问题与排查技巧实录
6.1 硬件端典型问题
硬件端的坑数量最多，我把实际调试中高频出现的问题整理出来，有同类情况的可以直接对照排查。
第一类是GPS定位不到。常见原因有天线放置位置不对，GPS模块没有放置在窗户边或室外；模块冷启动时间不足；代码里没有正确解析NMEA语句。解决办法是先在串口监视器里看原始GPS输出，如果连$GPGGA这类语句都没有，说明模块供电或接线有问题；如果有数据但坐标始终显示0，多半是还没有完成定位，拿到室外等30秒到一分钟就正常了。
第二类是Wi-Fi频繁掉线。这个问题的根源就是模块或网卡供电不稳。解决思路是单独给Wi-Fi模块加一个100微法电容做去耦，同时检查手机热点是否开了AP隔离。建议调试期间用手机热点，现场环境有路由器就用路由器，信号稳定性差距很大。
第三类是设备温度异常值。DHT11在刚上电时会读到50℃以上的离谱数据，这是传感器的建立时间特性导致的。最简单的办法是上电后延迟5秒再读取温湿度，或者连续读两次取第二次的值。
6.2 小程序端典型问题
小程序端最容易出问题的是网络连接和权限配置。
第一个是WebSocket连接失败。开发工具里开着“不校验合法域名”能连上，但真机预览就是连不上。排查思路是检查后台是否配置了socket合法域名，并且要求域名必须为HTTPS/WSS且证书有效。另外MQTT.js在微信小程序环境下需要开启useExtendedPacketLength等兼容配置，部分参数需要针对小程序运行环境单独设置。
第二个是地图上标记点不移动。这个问题常见于DeviceId不一致。设备端上报时把deviceId写成了device_01，小程序端绑定的是pet_001，主题对不上自然没数据。所以我会在云端的调试日志页把上报的设备ID、Topic、时间全部显示出来，一眼就能定位是数据没上来还是解析出了问题。
第三个是逆地址解析失败。腾讯位置服务的Key在小程序端使用需要配置域名白名单，同时要在“腾讯位置服务”的控制台里开启“微信小程序”的合法域名类型。开发环境可以通过request合法域名设置绕过，但真机预览必须配置完整。
6.3 服务端与网络问题速查表
我把云端和网络相关的常见问题整理成一张速查表，开发时可以直接对照：
| 问题现象 | 可能原因 | 解决方向 |
|---|---|---|
| 小程序连不上Broker | WSS端口未开放 | 检查云平台控制台的安全组规则 |
| 设备长时间离线 | 设备端断网后未自动重连 | 增加自动重连和退避机制 |
| Topic收不到消息 | Topic越权或订阅不匹配 | 核对设备发布Topic和用户订阅Topic是否一致 |
| 历史轨迹有断点 | 设备多次重启导致数据缺失 | 开启设备端补报机制，上报前检查离线数据缓存 |
| 云端数据库增长过快 | 定位数据存太密 | 默认30秒一存，在设备端做“坐标变化超过阈值才更新” |
| 设备时好时坏 | 供电不稳或Wi-Fi信号弱 | 检查电池电压，使用低功耗模式或增强天线 |
排查问题时一个很给力的技巧是“分段定位法”。不要一上来就猜是硬件还是软件问题。先看设备端串口是否在正常上报，再看云平台日志是否有数据接入，最后看小程序端是否收到消息。哪一步断了就修哪一段，效率极高。我在交付阶段加了这些排查手段之后，远程沟通的成本至少降了一半。
还有一个容易被忽视的点是时间戳统一。设备端、云端、小程序端如果各自用了不同的时间基准，历史轨迹、告警比对、离线判断都会对不上。推荐在设备端通过NTP校时，确保上报消息里的ts是真实Unix时间戳；没有NTP时也要用uptime做相对时间差，不要在设备端直接生成“本地字符串形时间”。这个机制在远程调试时特别有用，因为只要时间统一了，云端日志和小程序展示的时间线就能完全对上。
写在最后的一点个人建议
这个项目做到最后，你会发现真正的难点不是某个技术点本身，而是如何把硬件、云端、小程序三块串成一个稳定运行的完整系统。我做类似项目时踩过最大的坑就是“只在本地Demo能跑”，一换网络环境就各种连不上、收不到、闪退。所以在这里也建议你从第一天开始就把模块化、日志、自动重连、时间戳标准化这些“看不见的工程素养”做进去，后期调试和写论文都会顺畅很多。
再多说一句：如果精力允许，可以在硬件端多加一个功能，比如通过蜂鸣器进行宠物呼唤提示，或者在小程序端加一个设备分享功能，把设备权限分享给家人。这些扩展不大，但会让项目在一堆同质化选题里显得更有想法。
