智能手表健康监测小程序是一套「穿戴设备 + 手机端 + 后台」的健康数据通道：手表通过蓝牙把心率、血氧、睡眠、步数报给手机，小程序落在本地库里展示，再按阈值触发预警推给本人与家属。它的技术重心不在图表好看，在「绑得上、连得稳、报得准」。
这类产品的买方通常是两类：一类是硬件厂商要做配套 App，卖表的时候得有个能看数据的入口；一类是养老、康养、企业健康管理的运营方，要用手表做远程看护。
智能手表健康监测小程序是一套什么系统？
是一套三段式的数据链路：采集在手环、中转在手机、呈现与规则在小程序。
三段各有各的约束：
采集段由手表固件完成，测心率用光电容积脉搏波、测血氧用双波长、测睡眠靠体动加心率变异性。这一段的精度由硬件决定，软件改不了。
中转段在手机上，靠蓝牙低功耗协议把手表的数据读出来。这一段是最容易出问题的地方——不是软件写错了，是手机系统的省电策略会杀掉后台连接。
呈现与规则段在小程序里，负责存储、画图、算预警。看起来最复杂，其实最好做，因为全是常规的数据处理。
很多团队把精力全放在第三段，做了一堆漂亮的图表，结果前两段不稳，用户打开一看「暂无数据」，产品就废了。
为什么必须先做蓝牙绑定？
因为手表的数据不上云，只能由手机去读。
这类产品有个反直觉的点：手表本身通常不联网（不插卡、不连 WiFi），它只是把数据存在本地。手机是唯一的出口。
所以绑定是整个产品的前置条件，绑不上就等于产品不可用。绑定流程一般是：小程序打开蓝牙 → 扫描周边设备 → 列出候选 → 用户选择 → 配对 → 校验设备身份 → 写入本地绑定关系。
小程序端的限制要提前知道：微信小程序的蓝牙接口只能连低功耗设备，且不能在后台长时间维持连接；iOS 与安卓的扫描行为差异明显（iOS 拿不到设备的 MAC 地址，安卓能拿到），所以不能用 MAC 做唯一标识，要用设备广播里的自定义服务 UUID 加序列号。
蓝牙绑定的难点在哪？
在「同名设备一堆」和「断了要自己接回来」这两件事上。
同名问题：同一批出厂的手表广播名完全一样，一个办公室里二十块表，扫描列表里全是同一个名字，用户没法选。解决办法是让固件在广播包里带上后四位序列号，列表显示成「XX 手表 · A3F2」。
重连问题：手机蓝牙断开是常态——用户走出范围、手机重启、系统清理后台。小程序要在每次打开时自动尝试重连上次绑定的设备，而不是让用户重新走一遍扫描流程。重连失败时给出明确原因（蓝牙关了 / 设备没电 / 距离太远），而不是一句「连接失败」。
多设备问题：一个用户可能有多块表（家里一块、公司一块），或者一块表要绑多台手机（本人一台、子女一台）。系统要支持一对多与多对一两种绑定关系，并且能标记「主设备」。
数据是怎么从手表到小程序的？
走「手表存 → 手机读 → 小程序取」的接力，中间有断点要补。
手表端的策略通常是「定时采样、批量存储」：心率每几分钟测一次，攒够一段再等手机来读。这样省电，代价是数据有延迟。
手机端拿到数据后，先落在手机的本地存储里（不是直接上云），小程序再从这里读。这个设计的价值是离线可用——老人家里没网，数据也不会丢，等联网了再同步。
同步策略要设计成「增量」而不是「全量」：按时间戳拉取上次同步之后的数据，而不是每次把整天的记录重传一遍。全量同步在数据攒了几个月之后会明显变慢，用户会以为卡死了。
预警规则该怎么定？
定「持续时长」和「组合条件」，不要用单点阈值。
单点阈值是最省事也最没用的做法：心率超过 120 就报警。问题是走路、爬楼、情绪激动都会超 120，一天报二十次，用户第三天就把通知关了。
有效的规则是多条件的：
持续型——静息心率连续十分钟高于某个值；对比型——今天的同时段心率比过去七天的基线高出一定幅度；组合型——血氧低于某值且伴随心率异常；事件型——检测到跌倒、长时间无体动。
规则引擎要能在后台配置，不能写死在代码里。老人与年轻人的阈值不一样，慢病人群与健康人群也不一样，写死了就只有一个场景能用。
还有一条必须做：预警要有分级与去重。 同一个异常在半小时内只推一次，不同等级的异常走不同通道（轻微只在 App 内提示，严重才发短信打电话）。预警轰炸比不预警更糟。
家属共享怎么设计才不越界？
让被监测的人自己决定谁能看，而不是默认全部可见。
健康数据属于敏感个人信息，共享给家属这个动作在法律上需要单独同意，不能拿「注册时的总协议」糊过去。
设计上的做法是：主账号（被监测者）发起授权，生成一个邀请码或分享链接给家属；家属扫码后只获得「查看」权限，不能改设置、不能删数据；授权可以随时撤回，撤回后家属端立刻看不到新数据。
权限还要分级：家属能看心率、步数、睡眠，未必需要看全部原始波形；医生或护理人员能看更细的，但需要另一套授权。
这套权限模型和人体行为姿态识别系统里的看护场景是一致的：谁能看、能看多少、能看多久，三个维度都要显式配置。
健康数据的合规边界在哪？
在「描述」与「诊断」之间。
设备能做的：记录心率、血氧、睡眠时长、步数、体温趋势，做统计与趋势描述，在数据异常时提示「建议关注」。
设备不能做的：给出疾病判断、给出用药建议、宣称能筛查某种疾病。一旦跨过这条线，产品就从消费电子变成了医疗器械，需要注册证。
这条边界在文案上最容易破：图表旁边写一句「您可能存在心律失常风险」，性质就变了。安全的写法是「本次心率波动较大，建议休息后复测；如持续异常请就医」——描述现象、建议就医，不下结论。
和AI 四诊健康管理平台的处境一样，这类产品真正的门槛不在技术，在「说什么、不说什么」。
选型时要看什么？
看四件事：固件协议是否开放、绑定成功率、离线能力、后台规则是否可配。
固件协议是第一道门。手表厂商愿不愿意提供蓝牙服务定义文档、能不能改广播包加序列号，决定了绑定能不能做好。拿不到文档，只能靠抓包猜，做出来必然不稳。
绑定成功率要实测，尤其在多设备环境里测。
离线能力决定产品在弱网场景能不能用——老人家里、健身房地下室、医院病房，网络都不好。
后台规则可配决定这套系统能不能卖给第二个客户。规则写死的产品，只能做一个场景。