1. 项目背景与整体设计思路做这个“基于微信小程序的空巢老人健康管理系统”最初就是被一句话点醒的——社区网格员老周跟我抱怨他负责的片区有两百多位独居老人每天挨个打电话问平安电话打得嗓子冒烟还有几个老人明明有心率异常自己根本不当回事等出问题送到医院已经晚了。这话听着扎心但也把需求彻底说透了。空巢老人健康管理核心痛点从来就不是“缺一个表”或者“缺一个App”而是缺少一条从老人端到家人都监护端再到社区服务端的闭环链路。老人需要的是“我什么都不用会设备自己把数据传出去真有异常有人来管我”家人需要的是“我不用守在旁边也能随时知道父母今天身体怎么样、有没有出门、有没有按时吃药”社区和机构需要的是“我能批量盯住高风险老人把有限的精力集中在真正需要干预的个案上”。所以这套系统我选了三个层面的技术架构。底层是硬件感知层对接心率、血压、血氧手环以及门磁、紧急呼叫按钮这类轻量IoT设备中间是业务逻辑层跑在微信小程序里承载老人端极简模式、家人端数据看板、社区端任务工单这些不同角色入口上层是通知触达层通过订阅消息、短信、电话语音告警把“心率异常”“跌倒疑似”“长时间未出门”这类事件推给对应的联系人。选微信小程序而不是独立App说白了就三条。第一老人端不用教装软件微信就在手机上子女远程给添加上设备就能用第二小程序天然带了用户身份体系手机号一键授权比自建账号体系省一大截事第三微信的订阅消息和客服消息通道在告警触达这个场景上比推送SDK稳定可靠得多尤其是iOS后台限制的情况下小程序的消息触达反而是最省心的方案。UniApp在这个项目里承担的是编译框架的角色。一次开发编译到微信小程序、H5以及后续可选的安卓App。为什么要留H5和App这条路因为实际落地时你会发现社区服务端的工作人员更愿意用网页后台处理工单而部分老人家属用的是非微信生态的智能机。而且UniApp的Vue语法对团队后续维护成本很友好社区生态里现成的组件库也确实能省掉不少造轮子的时间。整套系统的数据流大概是这样的硬件设备通过蓝牙或扫码绑定后按固定周期上报体征数据到后端接口后端经过阈值判断和趋势分析把正常数据归档、异常数据标记小程序端轮询或收到推送后更新看板同时触发订阅消息给预设联系人。这套链路里老人端只负责“无声无息地把数据传出去”所有的判断和交互都放在后台和监护端这个设计原则从第一天就定死了。2. 核心模块拆解与关键技术选型2.1 设备绑定与硬件交互蓝牙、扫码与数据解析硬件接入是这套系统里最脏最累的活也是坑最多的部分。市面上能买到的老人健康手环通信协议五花八门有的走蓝牙BLE有的走NB-IoT有的甚至只支持厂商自己的App云端转发。我的建议是第一版先做两类接入方式一类是蓝牙BLE直连的设备老人端小程序通过微信蓝牙API直接读取体征数据另一类走扫码绑定设备本身自带2G/4G或NB-IoT模块自主上报数据小程序只需要扫设备上的二维码完成配对即可。蓝牙这条路检索设备是很直观的。uni.openBluetoothAdapter初始化蓝牙适配器uni.startBluetoothDevicesDiscovery开始扫描然后根据设备的name或广播数据里的serviceId过滤目标设备。真正麻烦的是数据解析。很多手环厂商的协议文档写得跟天书一样数据包是按字节切割的心率在第几个字节、血氧在第几个字节、校验位怎么算都要一遍遍对着文档调试。我当初调一个牌子的手环协议文档里写“心率数据为2字节小端序”结果实际发出来的包是大端序害得我排查了一天一夜。后来学乖了解析层单独封装成一个模块写几百条测试用例把各家设备的数据包都模拟测一遍再上线接真机。扫码绑定的逻辑稍微简单一些。设备上的二维码里通常包含设备的MAC地址或唯一设备ID格式可能是URL参数也可能是纯字符串。用uni.scanCode扫出来之后正则提取出设备标识调后端绑定接口把设备与老人档案关联。这里有个细节有时候扫出来的一串数字不带任何格式需要跟厂商确认编码规则不能硬猜。我在项目里就遇到过扫码扫出来一串纯数字的蓝牙秤后来问了厂商才知道那串数字前两位是产品型号中间八位是出厂日期后六位才是设备序列号规则不确认清楚根本没法做绑定。2.2 实时定位与电子围栏别小看这张地图独居老人最大的风险其实是“失联”早上出门买菜晚上没回来家人根本不知道什么时候出的门、去了哪里。所以这套系统把实时定位和电子围栏作为一级功能来做不是锦上添花是刚需。定位这块在UniApp里调用的是uni.getLocation底层是小程序的wx.getLocation拿到经纬度之后再通过腾讯地图的WebService API做逆地址解析把坐标转成“xx社区xx栋xx号”这种人类能看懂的文字描述。这里必须注意uni.getLocation在较新版本的小程序基础库中默认返回的是GCJ-02坐标系也就是火星坐标系这个坐标系跟市面上大多数地图SDK是一致的但如果后端用的是WGS-84比如某些海外服务器或GPS原始数据那就需要做坐标系转换不然位置会偏几十米到几百米电子围栏的判定直接失真。电子围栏的实现我选了GeoFencing的思路就是把一个地理围栏定义成多边形区域的顶点坐标数组使用射线法判断当前定位点是否在多边形内部。射线法这个算法不复杂核心思路是从当前点水平向右发射一条射线统计射线与多边形边的交点数交点数为奇数则在多边形内偶数则在多边形外。代码实现也就二三十行但边界条件很多顶点在边上、射线经过顶点这些情况都要特殊处理。我是直接用了一个开源库 geolib 把这块封装起来后端判断、前端展示都用同一套算法保证判定结果一致。实际使用中最实用的是“出门提醒”和“超时未归”两个规则。出门提醒是当老人的定位点从围栏内变为围栏外时触发超时未归是当老人离开围栏超过设定时间比如2小时仍未返回时触发这时候系统会向预设联系人推送一条带位置的告警消息联系人可以直接点开消息跳转到小程序的实时位置页。这块我踩过的一个坑是老人手机为了省电会把GPS关掉这时getLocation返回的可能是基于Wi-Fi或基站定位的低精度坐标漂移非常严重我后来做了一层置信度过滤定位精度低于某个阈值就标记为“粗略位置”不参与围栏判定防止误报。2.3 健康数据上报与可视化从原始字节到趋势图表设备上报的体征数据通常包含心率、血压、血氧、体温这几项偶尔还有睡眠质量和步数。数据到了后端之后第一步是清洗去噪。比如血压计偶尔会报出舒张压200这种离谱值手指没放好、袖带松了都会导致读数异常这类脏数据如果直接入库会污染后续所有的趋势分析。清洗规则我做了三层。第一层是物理合理性校验心率在30到220次/分之间、血氧在70%到100%之间超出直接丢弃第二层是相邻样本突变校验同一设备相邻两次上报的心率差值超过30次/分就标记为可疑数据需要人工确认第三层是设备离线校验超过24小时没有上报的设备自动给家人发一条提醒消息提醒检查设备是不是没电了或者被老人摘掉了。可视化这块用的是ECharts。UniApp项目里引用ECharts有两种方式一种是用renderjs在视图层运行另一种是用官方封装的echarts-for-weixin组件。我在这个项目里采用的是后者的思路把折线图和柱状图都封装成独立组件通过props传入数据、通过事件上报点击。图表这东西看着简单但真正做起来细节特别多。比如心率趋势图Y轴范围不能写死要根据历史数据的最大值和最小值动态调整不然老人心率一直在70到80之间波动Y轴却显示0到200波形会被压成一条直线完全看不出异常波动。还有一个实用的设计是把异常数据用不同颜色标注心率超过100或者低于50的点用红色标出正常区间用绿色标出家人打开小程序第一眼就能看到近期有没有“红点事件”不用盯着数字逐个比对。实测下来这种颜色编码的方式特别受老年用户家属欢迎他们大部分不具备看医学报告的能力但红色代表“需要注意”这个常识是通用的。2.4 告警通知链路订阅消息、短信与语音电话三级递进告警通知是整个系统的价值出口做得不好前面所有数据采集都是白费。我设计的通知链路是三级递进的。第一级是微信订阅消息。小程序通过uni.requestSubscribeMessage请求用户授权用户同意后后端在触发告警事件时调用微信的订阅消息接口下发通知。这里有一个在小程序里特别容易踩的坑订阅消息是一次性订阅也就是说用户每授权一次只能给用户发一条消息。所以我在授权弹窗里会让用户选择“持续监控”每次进入小程序都会自动重新拉起订阅授权保证长期有配额可用。这个交互设计要做好否则就会出现“家里人只收到了一次告警之后就再也没有消息了”的尴尬情况。第二级是短信通知。通过阿里云或腾讯云的短信接口发送内容大概是【xx健康】您的父亲王xx在10:25检测到心率异常数值128次/分请及时关注。短信的好处是到达率极高而且没有微信消息被折叠的问题。第三级是语音电话这个我接的是云呼叫中心的接口调用后自动拨打电话接通后播放一段TTS语音。语音电话只用于最高级别告警比如“摔倒检测触发”或者“连续3次心率超阈值”因为这个成本比短信贵一个数量级不能动不动就打。通知的策略也要费心思。同一个老人触发告警不能同时给多个联系人发同样的消息不然家人的解读是“出大事了”社区工作人员也会重复收到工单。我做了通知优先级排序第一联系人是紧急联系人第二联系人是子女第三联系人才是社区网格员。只有当第一联系人在设定时间内比如15分钟没有点击确认处理通知才自动升级到第二联系人。这个“逐级升级”的策略在真实运营中非常关键既能保证告警不漏又不会把所有人都轰炸一遍。3. 多端适配与性能优化实战3.1 老人端极简模式大字号、大按钮、少层级空巢老人群体里面会用智能手机的比例并不低但他们用手机的方式跟年轻人完全不一样。年轻人看图标老人看文字年轻人凭肌肉记忆操作老人每点一步都要读一遍屏幕上的字。所以小程序做了一个极简模式UI设计原则是“一屏只做一件事一个按钮能完成绝不用两个”。极简模式的首页只有三个大按钮一个是“报平安”老人每天早晨醒来点一下相当于签到家人端会收到一条“今日已报平安”的消息一个是“测量”点了之后跳转到蓝牙设备连接页自动连接手环或血压计测量完成后数据自动上传还有一个是“求助”长按触发SOS告警。这三个按钮都做成至少120rpx高、颜色对比强烈、带语音播报的样式实测下来老年人的点击准确率提升非常明显。这里有一个交互细节值得单独拿出来说。老人在使用过程中经常会不小心误触或者操作到一半不知道怎么继续所以极简模式做了“超时兜底”机制进入任何一个功能页超过60秒没有操作页面自动回到首页且不会触发任何数据变更。这个机制是为了防止“老人掏出手机随便点了两下就把状态搞乱了”的情况实际运营中能减掉至少三分之一的人工咨询电话。字体大小和对比度也是硬指标。小程序的默认字号是30rpx左右极简模式统一提升到40rpx以上关键数据的数字直接做到80rpx用黑体加粗。背景色用米黄色或浅灰色不要用纯白色纯白在强光下会刺眼老年人瞳孔调节能力下降看着累。3.2 家人端数据看板一屏看懂父母近况家人端的信息架构是“今天怎么样”优先而不是“历史记录”优先。页面从上到下的布局依次是今日健康状态总览心率、血压、血氧三个数字卡片绿色正常、橙色关注、红色异常、最近一次测量时间、实时定位及电子围栏状态、近7天趋势缩略图。历史记录折叠在二级页面毕竟家人打开小程序最关心的是“现在”而不是“上周二”。趋势分析这块我做了一个比较实用的功能叫“变化趋势评分”。系统会把近30天的数据切成三个时间段分别计算均值然后对比最近一段时间跟此前一段时间的差异。比如说收缩压前20天均值128最近10天均值142系统会提示“血压呈上升趋势建议关注”这个提示比单看某一次血压偏高的参考价值大得多因为人的血压受情绪、饮食、昼夜节律影响单次高点说明不了什么问题但趋势变化往往是躯体疾病的早期信号。家人端还有一个“远程协助”功能可以远程触发老人端的一些设置比如调整提醒音量、更新紧急联系人、修改测量提醒时间。这些设置如果让老人自己在手机上操作基本不可能教会但家人远程改就方便多了。远程协助通过消息队列实现家人端发指令到后端老人端下次冷启动时拉取待执行指令并执行执行结果再回传确认。我还做了一个“多老人管理”的模式。有些用户家里不止一位老人父母和岳父母都需要监控所以家人端的账号体系是支持绑定多个老人的一个账号可以同时查看多位老人的健康数据这在设计上相当于做了一层elderId的维度隔离所有数据查询接口都要求传elderId参数前端也有严格的路由守卫避免串号。3.3 性能优化与启动速度老人等不起转圈小程序包体积和启动速度是影响老年人使用意愿的第一道坎。老人不像年轻人有耐心等加载页面转圈超过3秒他们就会觉得“坏了”然后把小程序关掉再也不打开。所以性能优化这个环节我下了很多功夫。首先是包体积控制。UniApp打出来的包默认会把所有页面和组件都编进去但我实际用到的页面其实只有12个很多组件库的代码根本不会走到老人端的路径上。解决办法是开启UniApp的分包加载机制把极简模式、家人端、社区管理员端三个角色拆成三个分包首包只保留登录页和角色路由分发页。这样首包体积从1.8MB降到了400KB左右在4G网络环境下启动速度从原来的3秒多降到1秒以内体感提升非常明显。其次是图片资源的处理。项目里有大量健康科普类的插图和图标如果全部用本地静态资源包体积会膨胀得厉害。我做了CDN化改造所有非关键路径的图片都上传到对象存储小程序端用懒加载策略只有滚动到可视区域才发起请求。首屏三张关键图标则做成Base64内联省去网络请求往返。再有一个是数据缓存策略。体征数据这类变化频率低但查询频率高的数据用uni.setStorageSync做本地一级缓存拉取接口之前先读缓存缓存命中就不请求网络只在页面onShow的时候后台静默刷新。这样老人每次打开小程序看到的数据都是秒出的即使网络状况不好也能先展示最近一次的数据然后等请求返回再更新界面。实测下来页面数据渲染速度提升了一个量级几乎感觉不到等待。3.4 视频通话与远程关怀距离再远也能见面文字和语音沟通对老人来说还是有门槛的最直观的关怀方式还是视频。小程序里集成视频通话用的方案是同声传译服务商提供的音视频通话SDKUniApp插件市场里有现成的封装插件。视频通话的场景有两个一个是老人主动发起点极简模式首页的“看看家人”按钮直接拨打预设联系人的微信小程序视频通话另一个是家人主动发起家人端看到老人的健康数据异常想确认一下老人的精神状况于是给老人的小程序推送一条视频邀请。这两个场景的实现逻辑是一样的只是发起方不同。实现上遇到的最大坑是权限和通话时的生命周期处理。小程序切后台之后音视频SDK的连接会断掉而onHide和onShow之间的处理如果不做好通话会因为一个误触而中断。我最终的方案是在通话页监听onHide如果通话处于进行中弹窗提示“通话仍在进行返回后将中断”让用户二次确认后再返回同时把通话状态同步到后端。另外通话记录会保留在小程序里家人可以回看通话时间、时长、发起方这对后续如果需要人工核实老人的精神状态会有帮助。4. 从零到上线的完整实施路径4.1 开发环境搭建与工程初始化开发这个项目我用的IDE是HBuilderX版本是3.8UniApp项目的标准开发环境。如果你没有接触过UniApp这里简单说两句。HBuilderX是DCloud出的一个前端IDE它对UniApp项目的支持是最完整的新建项目、运行到微信开发者工具、打包上传这些操作在HBuilderX里都是图形界面操作基本不需要手动敲编译命令。初始化工程的时候我建议直接选“默认模板”而不是“Hello uni-app”模板后者自带的示例代码太多了堆在项目里既占空间又干扰思路。项目创建好之后第一件事是配置manifest.json。这个小程序端的配置项都要在这里面填包括小程序的AppID、项目名称、App图标、用户隐私保护指引等等。特别注意微信小程序现在强制要求配置用户隐私保护指引如果不在小程序后台声明收集了哪些用户信息比如位置、蓝牙、摄像头前端调用相关API会被直接拦截报错信息也不明显就是这个API没反应。然后是安装依赖。我用到的核心依赖有Vuex状态管理、uni-simple-router路由封装、echarts-for-weixin图表、mescroll列表滚动加载、lime-echart另一个ECharts封装等。安装方式有两种一种是用HBuilderX的插件市场直接导入另一种是用npm安装。npm安装之后需要在main.js里引入并挂载到Vue实例上注意一定要配easycom规则否则自定义组件都要手动import代码会非常啰嗦。还有一个建议是项目一开始就引入uni_modules规范。UniApp的插件都是以uni_modules的目录结构组织的这种结构的好处是插件自包含卸载或者升级都很干净不会污染项目核心代码。我的uni_modules里面分了三类一是官方插件比如uni-ui组件库二是第三方插件比如音视频SDK三是自己封装的业务组件比如健康数据图表、设备绑定卡片这些。这样划分的好处是后续维护的时候思路清楚哪个东西出问题能快速定位到对应目录。4.2 后端接口设计与数据模型规划后端我用的SpringBoot框架数据库选了MySQL缓存用的是Redis。这块不多展开重点说几个跟业务强相关的设计决策。第一老人档案表elder_profile是核心主表所有健康数据都挂在elder_id下面。我在设计这张表的时候特意加了一个high_risk_tag字段用于标记重点监护对象。社区管理员端会优先展示高风险老人这个字段后续还能跑算法自动更新比如连续一周心率波动超过阈值就自动标记为高风险。第二体征数据表vital_sign_record的写入压力非常大一个老人一天如果每5分钟上报一次心率就是288条记录100个老人就是28800条/天。所以我做了分表存储按月分表也就是vital_sign_record_202501、vital_sign_record_202502这种命名规则查询的时候通过表名路由定位到具体月份。另外为了减少数据库的写入压力数据上报接口用的是批量写入模式设备端攒了10条数据一次性提交后端批量insert。第三告警工单表alert_ticket承担的是“事件归档”的职责。每触发一次告警就生成一条工单包括告警等级、触发类型、处理状态、处理人、处理时间、备注这些字段。这个表是后续做服务质量分析的数据基础比如“平均响应时间”“告警漏处理率”这些运营指标都从这张表算出来。接口设计上我严格遵守RESTful风格统一返回结构是{ code, message, data }这种风格。前端在封装的request.js里统一拦截错误码并弹出提示不把错误处理散落在各个页面里。有一个细节是所有写操作的接口都必须做幂等处理防止请求重试时产生重复数据这个在健康数据上报场景特别重要——设备断网重连后经常会重发之前的数据包如果不做幂等数据库里就会堆满重复记录。4.3 微信开发者工具联调与常见报错处理UniApp项目写好之后通过HBuilderX的运行按钮会拉起微信开发者工具。这里有一个常见的坑HBuilderX点击运行后微信开发者工具没有任何反应或者报错说“当前工具未开启服务端口”。解决方案是在微信开发者工具的“设置-安全设置-服务端口”里打开端口监听并且关闭微信开发者工具的模拟网络环境——如果开了这个选项会导致所有网络请求都失败。联调阶段我遇到的其他高频报错还有几个一个是wx.getLocation接口调用失败报错信息是“getLocation:fail the api need to be declared in the requiredPrivateInfos field”。这是微信小程序在2022年之后的新规定开发者必须在app.json的requiredPrivateInfos字段中声明要使用的隐私接口小程序后台也要申请对应的权限。解决方案是在manifest.json对应的源码视图里加上requiredPrivateInfos: [getLocation, startLocationUpdateBackground]之类的声明。另一个是蓝牙接口报错10004意思是蓝牙适配器未初始化。这个错误通常是因为调用了uni.openBluetoothAdapter之后在success回调还没返回时就调用了uni.startBluetoothDevicesDiscovery。解决方法是把蓝牙初始化逻辑做成Promise封装确保初始化成功后再开始扫描。还有一个是“paused in debugger”导致页面卡死。这个其实是微信开发者工具的调试器临时断点问题不是代码报错直接点击继续或者关掉调试器就好。但如果频繁出现建议检查代码里是不是有debugger语句残留我当初就是因为调试完忘删了一个debugger导致线上版本在某个操作路径上也会停住极其尴尬。4.4 上架审核与隐私合规要点小程序提审被拒是几乎每个开发者都要经历的痛我做这个项目也踩了几次审核的坑把高频原因整理出来给大家参考。第一个高频原因是类目不符。健康管理类小程序需要选择“医疗-健康管理”类目如果没有对应的资质文件会被驳回要求补充。解决方案是提前准备好ICP备案号和相关资质比如医疗器械经营备案凭证如果涉及医疗器械销售的话或者只做“健康数据记录”功能避免涉及“诊疗”相关表述。我在这里特意把App名字和页面文案里的“医疗”“诊断”“治疗”这些词全部替换成了“健康管理”“健康记录”“数据监测”就是为了从产品定位上避开医疗资质审查。第二个高频原因是隐私政策。小程序的隐私弹窗必须明确列出收集的信息类型、使用目的、第三方SDK名称。我在代码里做了一个独立的隐私政策页面并在首次启动时强制弹窗让用户阅读并同意不同意则退出小程序。代码实现上是在App.vue的onLaunch里检查本地存储的privacyAgreed标识如果没有用uni.showModal弹出一个非模态的隐私弹窗点了同意才写入标识并放行后续逻辑。第三个高频原因是用户授权行为不规范。微信平台要求收集用户信息必须获得用户明示同意不能通过“拒绝即退出小程序”的方式强制授权。我的实现是在具体使用场景中才弹出授权请求比如用户点击“使用蓝牙连接设备”才发起蓝牙权限请求而不是在小程序启动时就一窝蜂把权限都要了。这个“按需授权”的交互模式也是微信官方推荐的做法。5. 常见问题速查表与避坑实录整理一下项目开发过程中遇到的典型问题用表格的方式分享出来方便大家对号入座。问题现象根因分析解决方案HBuilderX运行到微信开发者工具无反应开发者工具服务端口未开启设置-安全设置-服务端口打开端口监听getLocation调用失败缺少requiredPrivateInfos声明manifest.json源码视图补充声明字段蓝牙初始化报错10004适配器未初始化就调用了扫描接口用Promise封装初始化流程确保成功后再扫描订阅消息发送不出去用户授权已过期或配额用完每次进入小程序重新拉起订阅请求软键盘把查询框遮挡键盘弹出后页面未主动调整监听键盘高度手动计算输入框距底部的值iOS中swiper嵌套video全屏错位原生组件层级与swiper冲突全屏时通过cover-view或同层渲染处理popup弹窗后面页面可滚动弹窗没有阻止背景滚动设置弹窗page-meta的overflow:hidden或禁用touchmove小程序包体积过大导致启动慢未做分包所有页面压在主包按角色拆分包首包只留入口逻辑视频列表多个同时播放缺少播放状态管理设置currentVideoId切换时先停掉上一个安卓手机上定位漂移严重基站/Wi-Fi定位精度低按精度值过滤低精度的不参与围栏判定、只展示参考位置这里单独挑几个展开说一下。软键盘遮挡输入框的问题在小程序里非常普遍尤其是在医生问诊记录、健康备注这类需要键盘输入的页面上。微信小程序提供了一个adjust-position属性控制键盘弹出时页面是否自动上推但在一些Android机型上这个属性并不完全可靠。我的解决方案是监听uni.onKeyboardHeightChange拿到键盘高度后动态计算输入框bottom值让输入框始终浮在键盘上方。这个方法实测下来比原生行为稳定很多。iOS上swiper组件嵌套video组件导致全屏错位这个问题的本质是video是原生组件层级和渲染机制与普通View不一样。在全屏播放时我采用的方式是隐藏swiper里的video改成在页面顶层渲染一个全屏的video组件通过改变配置属性来控制全屏状态这样既保留了滑动的流畅度也避开了原生组件层级问题的雷区。视频列表限制一个视频播放这个需求核心是维护一个“当前播放ID”的全局状态。在video的play事件里记录当前正在播放的视频ID当另一个视频触发play时先调用VideoContext.stop()停掉之前的那个。这里要注意的是VideoContext实例的复用不要在play事件里频繁创建新实例否则会导致内存泄漏。还有一个容易被忽略的问题是小程序顶部导航栏高度的适配这个在小程序里没有统一的API可以直接拿到导航栏高度需要根据机型动态计算。计算公式是胶囊按钮位置信息.top 胶囊按钮高度 (胶囊按钮距顶部的间距 * 2)这里的胶囊按钮就是微信小程序右上角那三个点。代码实现上是这样的const getNavBarHeight () { const systemInfo uni.getSystemInfoSync() const capsule uni.getMenuButtonBoundingClientRect() const statusBarHeight systemInfo.statusBarHeight const navBarHeight (capsule.top - statusBarHeight) * 2 capsule.height return { statusBarHeight, navBarHeight, navBarTop: capsule.top, capsuleHeight: capsule.height } }自定义导航栏做好之后在pages.json里把对应页面的navigationStyle设置为custom然后按照计算出来的高度去铺设自定义的导航栏组件。这里要特别强调不同机型的胶囊按钮位置略有差异一定要用uni.getMenuButtonBoundingClientRect()实时获取不能写死固定间距不然iPhone和安卓上出来的效果会完全不同。6. 经验心得与后续扩展方向最后聊一些自己在实际做这个项目中沉淀下来的想法吧算是一个阶段性的记录。做面向老年人的系统最重要的原则就是“不要让他们感觉到自己是在用高科技产品”。界面越像普通电话、越像计算器老人越敢用界面越像互联网App老人越容易紧张。所以极简模式的三个按钮我做成了跟电话拨号键盘差不多的圆形大按钮文案也是直接了当的“报平安”“测一测”“救命”这种大白话而不是“今日签到”“数据录入”“SOS告警”这种业务术语。实测下来一个第一次用智能手机的75岁老人在看我用手机演示一遍之后基本都能独立完成签到操作。老人的学习能力并没有问题问题是交互设计常常把他们强行挡在门外。另外要说的是告警系统的可靠性永远比数据分析的深度更优先。老人家半夜摔倒了系统识别出来并且通知到了家属这比任何花哨的AI健康评估都有价值得多。所以在架构设计上告警链路的每一步都做了冗余设备断线了会触发离线告警订阅消息发送失败会降级为短信短信发送失败会降级为语音电话语音电话无人接听会自动升级并通知社区网格员。这套“永不放弃”的告警机制成了整个系统口碑最好的功能点。关于后续扩展方向我个人认为至少有三条路径值得尝试。第一条是接入更多的IoT设备品类比如智能药盒记录老人是否按时服药、跌倒检测雷达、睡眠监测床垫设备种类越丰富系统能覆盖的风险场景就越完整。第二条是引入大语言模型做智能对话式关怀老人可以直接对小程序说话比如“今天我该吃药了没有”“周末能提醒我儿子来看我吗”系统用语音交互的方式回答比传统的按钮操作更符合老人的使用习惯。第三条是数据的社区级整合一个社区所有老人的健康数据进行脱敏后汇总分析可以帮助社区掌握本区域老人的整体健康水平和风险分布做更有针对性的公共卫生干预。这些方向我在持续跟进和实践后续有新成果会再专门分享。做这个项目的最大感受是技术从来不是最难的最难的是把技术转化成真正让老人觉得“有用、好用、敢用”的产品。每次看到后台有老人连续60天早上七点准时点“报平安”我都有一种实实在在的成就感。希望大家在做类似项目的时候也能多去一线看看真实的使用场景只有站在用户身边才能做出真正有价值的东西。