去年九十月份我接到一个让我印象特别深的任务给社区做一套老人服务的小程序。需求方给了一长串功能清单从健康档案到预约家政、从社区团购到在线问诊洋洋洒洒十几项。但当我回家把原型拿给我爸看他划了三分钟屏幕说了一句“这东西是给年轻人玩的吧”。我当时就反应过来——做老人服务系统第一个要解决的根本不是技术问题而是“老人敢不敢用、愿不愿意用”的问题。这个项目从设计到落地最终的载体选了微信小程序开发框架用了UniApp。微信小程序的好处是老人不需要额外装App子女帮他在微信里点开就能用UniApp则解决了我一直担心的多端复用问题——同一套代码以后要编译成安卓App或者H5版本都很方便。这一篇就围绕这套老人服务系统的设计与实现把从需求拆解、技术选型、界面适配到真机调试的完整过程写一遍重点讲我在实际开发中踩过的坑和觉得有价值的设计细节给同样在做类似项目的人做个参考。1. 先回答一个问题这套系统到底给谁用1.1 需求清单可以很长但老人的手指只有一个需求方最初给我的那份功能清单里健康档案、用药提醒、在线问诊、社区团购、预约家政、亲情通话几乎能想到的都列上了。从业务角度讲这些功能都合理社区养老确实需要这些服务。但是“功能合理”和“老人能用”是两回事。我当时做了个简单测试把第一版原型装到平板上让我爸从首页找到“预约助餐”他从找到入口到点进详情页花了两分多钟中间两次点错按钮退回了首页。老人用户有几个非常典型的生理和认知特点视力下降小字号小图标看不清手指灵活度下降小按钮容易误触对抽象的图标语义不熟悉一个“齿轮”图标在年轻人眼里是设置在老人眼里就是一个不知道干什么的图形。更关键的是老人的学习成本承受能力很低——教一次没学会他可能就再也不用了。所以项目的第一个设计决策是“砍需求而不是堆需求”。最终首页只保留了四个一级入口紧急求助、健康记录、服务预约、亲情联系。其他像社区公告、活动报名这些统一放进“更多”里甚至直接砍掉。这个决策看起来是产品层面的但实际上直接决定了后续的技术实现方向——tabBar怎么设计、页面层级多深、组件复杂度多高全由这个约束来定。1.2 拆成三个端老人端、家属端、服务管理端老人服务系统最容易犯的一个错误是把老人当唯一用户。实际上这个系统里至少有三类人使用系统的是老人真正做决策和监护的是子女家属后台提供服务的是社区工作人员或服务商。三类人的需求差异非常大。老人端要的是“极简”打开就是几个大按钮最好戳一下就有结果。家属端要的是“掌控感”老人今天的血压怎么样、有没有按时吃药、现在人在哪里、有没有发起过求助这些信息要一目了然。服务管理端要的是“流程”接到预约后怎么派单、怎么确认服务完成、如何记录回访。我在设计上做了角色区分处理。老人端的首页是极简大图标模式默认字体调到偏大而家属端通过同一个微信小程序里的角色切换进入可以看到更完整的数据面板和操作入口。后端用户表里用一个role字段区分前端根据角色控制页面渲染和按钮显隐。如果当初把所有功能混在一个界面里老人端根本不可能用起来。1.3 功能优先级排序经过反复权衡最终的核心功能模块收敛为下面这几块功能模块优先级核心逻辑对应角色紧急求助P0一键SOS自动定位、通知家属老人端健康记录P0血压血糖心率记录、趋势图表老人家属端位置共享P0实时定位防止走失家属端服务预约P1助餐、助洁、陪诊等服务下单老人端用药提醒P1按时间推送提醒记录打卡老人端消息通知P1订阅消息、状态变更提醒家属端P0是必须做扎实的P1可以简化但不能砍。这个排序贯穿了后续所有开发排期——我先用两周时间把P0功能跑通才动P1的内容。2. 为什么选UniApp被“跨端”反复拷打后的选择2.1 原生微信小程序 vs UniApp vs Taro技术选型阶段我其实犹豫了挺久。当时摆在面前的有三条路原生微信小程序、Taro、UniApp。我先说结论最终选了UniApp Vue3主要原因是团队的技术栈和这个项目的交付形态。先看原生微信小程序。它的优势是没有任何中间层直接调用微信官方API性能和兼容性都最稳。但劣势也很明显WXML/WXSS/JS那套写法是单独的语法体系会Vue的人上手也要适应一阵子而且它只能跑在微信里将来如果需求方说要出安卓App或H5版整套代码基本作废。做老人服务这类项目需求方今天说只要小程序、明天说要App的概率非常高原生写法在这点上太被动。再看Taro。Taro是React语法体系适合团队本来就是React栈的情况。但我们团队主力是VueTaro那套组件写法对我们来说等于重新学一个框架。而且Taro在跨端编译上依赖的配置项比较多对纯小程序场景来说有点“杀鸡用牛刀”的感觉。放一张我当时做的对比表方便你直观感受对比维度原生微信小程序UniAppTaro开发语法WXML/WXSS/JSVue语法React语法多端复用仅微信小程序小程序/H5/App/各类小程序小程序/H5/App学习成本需单独学习会Vue即可需熟悉React调试工具微信开发者工具HBuilderX微信开发者工具CLINPM生态性能损耗无有轻量中间层实测差异极小有中间层社区生态极成熟插件市场资源多质量参差NPM生态强2.2 UniApp真正舒服的地方和真正难受的地方用UniApp开发这个项目跑下来先说舒服的地方。第一是数据绑定方式。原生小程序改数据要自己管理setData改动频繁时很容易绕晕UniApp用Vue的响应式数据页面变量一变视图自动更新这对健康数据这类频繁刷新的页面特别友好。第二是打包环境HBuilderX里点几下就能产出小程序包云端打包也能直接出安卓和iOS的安装包省了搭建原生编译环境的功夫。第三是条件编译可以用注释标记某段代码只在小程序端生效或者只在App端生效多端差异处理比原生干净得多。但难受的地方也实实在在。第一是uni.xxx API和微信原生wx.xxx API并存。理论上UniApp提供了封装好的API但实际开发中时不时要用到微信独有的能力比如小程序订阅消息、微信运动这时候得在条件编译里写wx.xxx两边混着用代码风格不够统一。第二是样式兼容。部分CSS属性在H5端正常编译到小程序端就不支持比如一些伪元素动画、部分CSS Grid写法开发时要时刻想着“这段代码在哪个端跑”不能只写一遍。第三是插件市场质量参差不齐有的插件作者维护得不勤引入了反而多一堆bug。2.3 这个项目的技术栈全景定了UniApp之后整个前端技术栈就很清晰了开发框架UniAppVue3版本UI组件库uView PlusUniApp插件市场下载图表库ECharts配合小程序版echarts-for-weixin地图腾讯位置服务/高德地图UniApp的uni.getLocation配合地图SDK后端这里我们用的是Spring Boot MySQL如果你的后端不熟也可以直接用微信云开发老人服务这类小程序云开发足够扛住前期的所有场景缓存Redis主要用于登录态和验证码等短时效数据这个组合不是最花哨的但胜在每一步都有社区资料可以查遇到问题不容易卡死。尤其对老人服务系统这种需要反复调整界面和交互逻辑的项目技术选型越稳定迭代越快。3. 搭骨架初始化、manifest配置与UI库集成3.1 HBuilderX初始化UniApp项目项目搭建第一步是用HBuilderX新建uni-app项目。具体操作是打开HBuilderX文件 → 新建 → 项目选择“uni-app”模板项目名称填好之后模板选择“默认模板Vue3”。这里提醒一下Vue2和Vue3的UniApp模板在生态兼容上差别很大uView Plus这类新组件库都是基于Vue3的如果你用了Vue2模板后面很多组件装不上。创建完项目之后第一件要做的事是在manifest.json里填入微信小程序的AppID。AppID需要去微信公众平台注册一个小程序账号在“开发管理 → 开发设置”里拿到。如果暂时没有账号也可以先用测试号但测试号有很多限制比如无法使用订阅消息、无法开通部分权限建议还是早点把正式账号注册好。3.2 manifest.json里那些容易被忽略的配置manifest.json是UniApp各平台配置的核心文件但很多人初始化完就不管了后面上线时被各种问题绊住。我梳理几个这个项目里踩过的点微信小程序模块需要配置的主要是AppID同时要在“权限设置”里根据需求勾选定位权限、相机权限等。这里尤其注意小程序后台有一个“隐私接口声明”如果我用了getLocation、chooseImage这些接口必须在后台把使用目的描述清楚。审核阶段如果你声明了定位但没有在界面里明确提示用户用途会被直接驳回。还有图标问题。manifest里配置的App图标和启动图不但在微信里用将来云打包成安卓App时也会用到。我记得有一次项目快上架了才发现安卓端1024x1024的图标没处理云打包直接报错。建议项目一开始就准备好1024x1024、512x512等规格的图标省得后期手忙脚乱。3.3 uView Plus集成和目录结构规划UI组件库我选的是uView Plus。集成方式有两种第一种是在HBuilderX的uni_modules目录下直接放到插件市场导入这个方式对于HBuilderX项目最简单第二种是npm install uview-plus但需要额外配置。我建议用第一种因为UniApp的easycom组件模式配合uni_modules目录可以自动按需引入组件不用手动注册。集成之后记得做两件事一是在main.js里引入uView Plus并use二是在uni.scss里引入它的主题变量文件这样全局字体、配色才能统一控制。比如这个项目我把主色设置成了暖橙色#F08C3A比红色柔和、比蓝色温暖比较适合老人界面。目录结构我做了以下规划按功能拆分src/ ├── pages/ │ ├── index/ // 首页老人极简入口 │ ├── sos/ // 紧急求助 │ ├── health/ // 健康记录 │ ├── service/ // 服务预约 │ ├── family/ // 亲情联系位置共享、通话 │ └── mine/ // 个人中心设置、角色切换 ├── components/ // 自定义组件 ├── api/ // 按模块拆分的接口请求 ├── utils/ // 工具函数请求封装、缓存、格式化 ├── static/ // 静态资源 └── store/ // Vuex/Pinia状态3.4 自定义导航栏默认导航栏在老人场景里根本不够用微信小程序的默认导航栏有几个硬伤字体大小固定中年人看着都费劲背景色不能精细控制右侧胶囊按钮位置固定但我们希望把标题和按钮设计成高对比大色块。所以在这个项目里我给核心页面都配置了自定义导航栏。具体操作是在pages.json里把对应页面的navigationStyle改成custom。然后写一个top-bar组件在页面顶部占位。这个组件必须处理两个关键问题状态栏高度和胶囊按钮避让。状态栏高度要用uni.getSystemInfoSync().statusBarHeight动态获取不能写死不同手机的刘海屏高度差很多。胶囊按钮的位置可以通过uni.getMenuButtonBoundingClientRect()拿到它返回胶囊按钮的top、height、left、right这样我就能把自定义标题精确控制在胶囊按钮之下避免重叠。老人场景下我把标题字号直接放到19px左右按钮也加大到44px热区以上。这里有个容易忽略的细节用了自定义导航栏之后页面顶部就不会有默认的安全区域处理必须自己在top-bar组件里把高度计算出来否则内容会顶进刘海区域。4. 四个核心模块的实战拆解4.1 紧急求助防误触、秒级定位、多重通知紧急求助是整个系统里我应该放在最优先讲的一块因为它的逻辑直接关系到老人安全容不得半点疏忽。功能设计上首页放了一个占整行的大红色按钮写着“紧急求助”。点击之后不是立刻发起而是弹一个全屏确认页大字号显示“确认拨打紧急联系人或发送定位给家属吗”下方两个按钮分别是“确认求助”和“我不小心按到了”。这个确认页是为了防误触老人手指容易滑到按钮边缘没有确认直接发定位老人尴尬、家属也紧张。确认之后前端调uni.getLocation获取当前定位type选gcj02坐标系然后调用后端接口把老人的userId、经纬度、求助时间发给后端。后端收到之后做两件事一是通过短信通道给紧急联系人发短信附带一个高德地图链接二是调用微信小程序订阅消息给家属端推送一条求助提醒。如果开了服务管理端还会同步生成一条待处理工单。这个模块有几个细节要注意第一定位失败必须降级处理我写了一个兜底逻辑如果3秒内拿不到定位就弹出地图让老人或身边人手动选位置第二每24小时内最多发起N次求助防止误触或小孩乱按这个阈值可以在管理后台配置第三连续两次确认之间有3秒冷却时间防止连击。4.2 健康数据记录与可视化健康记录模块的核心是血压、血糖、心率这三项老人自己或用家人的帮助录入数值系统生成趋势图。这个模块我用ECharts来做折线图。UniApp接入ECharts有个经典坑直接import echarts在H5端没问题但编译到微信小程序端canvas组件和ECharts的render机制有兼容问题图表经常出不来或者出现“导出白图”这类情况。我的解决方案是用renderjs来渲染图表。renderjs是UniApp在App和小程序端提供的一个脚本运行环境它运行在视图层可以直接操作DOM或canvas避免了逻辑层和视图层通信的数据序列化损耗。简单贴一下核心思路template view classchart :propoption :change:propecharts.update/view /template script moduleecharts langrenderjs import * as echarts from echarts export default { data() { return { chart: null, option: null } }, mounted() { this.chart echarts.init(document.getElementById(chart)) }, methods: { update(newVal, oldVal) { if (this.chart newVal) { this.chart.setOption(JSON.parse(newVal)) } } } } /script这块还有一点特别值得注意健康数据属于隐私敏感数据不能直接缓存进本地存储尤其是血糖血压这种可能会影响医疗判断的数据。我做的策略是列表页只展示最近一次测量结果趋势图从后端接口实时拉取前端不落缓存这样即使手机被其他人拿到也不会轻易泄露老人历史健康数据。4.3 亲情关注位置共享与消息通知位置共享的设计思路是这样的老人端打开首页后如果开启了“允许家人查看位置”的开关前端会每隔一段时间调一次uni.getLocation把经纬度上报到后端。家属端在亲情页面里通过地图组件查看老人的位置。这个功能的实现难点不在地图本身而在于定位功耗和上报频率的平衡。如果每30秒上报一次老人电量掉得飞快如果半小时上报一次走失场景又失去了意义。我最终做的是动态上报策略默认10分钟上报一次如果家属端开启了“实时守护”模式就临时缩短到1分钟一次。这个模式由家属端触发老人端不用操作避免给老人增加认知负担。地图组件用的是UniApp内置的map组件绑定经纬度和标记点map :latitudelatitude :longitudelongitude :markersmarkers stylewidth: 100%; height: 500px;/map这里提一个小坑map组件在微信小程序端用gcj02坐标系没有问题但如果后端处理坐标时用了wgs84地图上就会产生几十米的偏移。老人定位场景几十米已经足够判断大概位置了但如果是精确到楼栋的救援场景这个偏差很危险。我的做法是前后端统一约定用gcj02后端存坐标时也标注坐标系避免不同数据源混用。4.4 服务预约把表单做到“老人不要思考”服务预约模块最开始做成了一个典型的表单服务类型下拉框、日期选择、时间选择、备注输入框看起来没问题但实际给老人用的时候光“下拉选择服务类型”这一个动作就难住了很多人——下拉框的交互方式在老人看来是完全陌生的。后来我把表单拆解成“先选服务、再选时间、最后填地址电话”三个步骤每一步只暴露一个决策点。服务类型用大卡片平铺展示每张卡片配一张大图标和一个通俗名字“助餐送饭上门”“助洁打扫卫生”“陪诊陪着去看病”“理发上门理发”。时间选择直接用微信自带的picker把日期和时段做成两级选择默认显示“明天上午”老人只需要确认或点一下切换。后端接口我设计了这样的状态流转待受理 → 已确认 → 服务中 → 已完成 → 已评价。老人端只展示前三个状态后两个状态由家属端或管理后台处理。每个状态变化都会触发订阅消息通知这样老人不用反复刷页面看进展子女也能第一时间知道服务进度。一个我踩过的坑给老人做时间选择时不要用“开始时间—结束时间”这种双选模式。老人的场景里服务是上门执行的只关心“哪一天、上午还是下午”其他的信息对老人来说都是负担。我最初做成开始结束双选测试时好几个老人直接卡在这一步后来改成上午/下午两个单选按钮通过率一下就上来了。5. 老人友好型UI大字体之外还有一堆细节5.1 字体、间距、按钮热区老人友好UI第一反应是放大字体但真正做起来远不止“把font-size改大”这么简单。字体、间距、热区必须成体系地放大否则会出现“字大了但按钮还是小”这种失衡状态。我在全局样式里做了一套基于rpx的尺寸规范主内容字号默认40rpx约20px按钮高度不低于88rpx约44px按钮文字不小于36rpx。任何可点击元素的点击热区最小是44x44px这是微信官方建议的最小人机交互尺寸实际老人场景我一般做到56px以上。间距方面页面左右边距统一32rpx卡片间距24rpx这样内容的块状感更强老人容易扫视。不能用纯rem或px写死了事因为小程序rpx本身是按屏幕宽度自适应缩放的配合designWidth 750设计稿不同手机上的视觉比例才能保持一致。如果混用px和rpx很容易出现iPhone上看着正常、安卓大屏上按钮反而变小的情况。5.2 减少跳转层级和操作步骤年轻人习惯层层深入找功能老人不行。我的原则是核心操作从首页到完成必须三步以内。比如“紧急求助”首页点按钮 → 确认页确认 → 完成。“预约助餐”首页点服务预约 → 大卡片选助餐 → 选时间确认 → 完成。绝不允许出现“首页 → 分类页 → 列表页 → 详情页 → 表单页 → 确认页”这种链路。实现上我用自定义组件做了首页的“一键直达”入口。比如首页的每个大卡片绑定的navigateTo目标地址直接在配置里写死不走通用列表页的中转。这样做虽然牺牲了一点代码规范性但换来了实际体验的大幅提升——老人少点一次右下角回退就能少一次迷路风险。5.3 语音播报与高对比度配色老人界面还有一个容易被忽略的点语音反馈。老人按了按钮之后如果只有界面变化很多人会不确定“到底按到没有”。我在关键动作上加了语音播报用的是微信同声传译插件的TTS能力点确认之后播报“预约成功”“求助已发送”“今天还没有打卡”这类短句。实现方式是在common.js封装一个speak(text)方法统一调用插件API所有页面共用。配色上我放弃了常见的淡蓝浅灰这类“清爽色”。清爽意味着低对比度对老人来说就是“看不清”。我用的是深色文字搭配浅米色背景所有主要按钮用高饱和大色块紧急求助大红色、服务预约橙色、健康记录绿色。同时保证前景和背景的对比度不低于4.5:1这个标准是参考无障碍设计的基本线。另外我刻意避免大面积使用蓝色和绿色区分功能因为部分老人有色弱问题红橙黄这类暖色调辨识度更高。5.4 无障碍支持与真机验证微信小程序支持无障碍访问主要方式是给组件添加aria-role和aria-label属性。比如大按钮我会写成view classsos-btn rolebutton aria-label紧急求助点击后发送位置给家人/view这样使用系统读屏功能的用户能听到更完整的播报信息。虽然很多老人不开读屏但这个习惯还是保留着成本很低收益存在。UI做完之后一定要真机验证不能只在开发者工具里看。开发者工具里的字体渲染和真机差不少特别是在Android低端机上大字号布局可能被撑破。我专门借了一台几百块钱的安卓低端机和一台旧iPhone做回归发现低端机上的canvas性能、列表滚动流畅度确实比开发机差一截针对这种情况我做了一版简化动画滚动卡顿明显减少。6. 请求封装、缓存策略与登录态设计6.1 uni.request的Promise封装老人服务系统的接口数量不算少涉及健康、位置、订单、用户多个模块。如果每个页面都直接uni.request代码会迅速失控。我第一步就是把请求统一封装成一个request工具函数。封装的核心逻辑很简单// utils/request.js const BASE_URL https://api.example.com export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, timeout: 10000, header: { Content-Type: application/json, token: uni.getStorageSync(token) || }, success: (res) { if (res.statusCode 200) { resolve(res.data) } else if (res.statusCode 401) { // token过期清除登录态跳转登录 uni.removeStorageSync(token) uni.reLaunch({ url: /pages/login/login }) } else { uni.showToast({ title: 请求失败请稍后重试, icon: none }) reject(res) } }, fail: (err) { uni.showToast({ title: 网络异常请检查网络, icon: none }) reject(err) } }) }) }在这个封装之上我再按业务模块做API函数文件。比如api/health.js里导出getBloodPressureList、addBloodPressure这些方法页面里调用时只关心数据不用关心错误处理逻辑。统一错误弹窗能让“请求失败”这类信息在全小程序内样式一致也方便后续换成统一的日志上报方案。6.2 缓存时间的坑微信小程序的存储API很简单uni.getStorageSync和uni.setStorageSync随手就能用。但“能存”不等于“该存”。这个项目里我吃过一次亏最开始把服务列表和公告接口的数据缓存到了本地设置成24小时有效结果第二天测试的时候发现头天后台改了服务价格小程序端怎么刷新都是旧数据直到老人反馈“价格怎么不对”才发现是缓存搞的鬼。后来我写了一个带时间戳的缓存工具// utils/cache.js export function setCache(key, data, expire) { const wrapped { data, timestamp: Date.now(), expire } uni.setStorageSync(key, wrapped) } export function getCache(key) { const wrapped uni.getStorageSync(key) if (!wrapped) return null if (Date.now() - wrapped.timestamp wrapped.expire) { uni.removeStorageSync(key) return null } return wrapped.data }使用上区分场景基础字典数据服务类型、公告列表缓存30分钟没问题健康记录、位置信息这类实时性高的数据一律不缓存。这个原则在团队里也写进了开发规范避免后来的人为了省流量把敏感数据也缓存了。6.3 登录态与角色区分微信小程序的登录链路是前端调uni.login拿到临时code传给后端后端用code向微信接口换取openid再返回一个自定义的登录态token。前端把这个token存进storage每次请求带在header里。这个项目特殊的地方在于角色区分。老人端的交互极简很多功能需要家属代操作比如绑定老人档案、查看健康趋势。所以登录流程我做成两步第一步先用手机号一键登录拿到基础账号第二步在“我的家庭”里绑定/创建老人档案绑定之后才能查看老人定位和健康数据。后端的用户表结构大概是这样user表id、openid、phone、roleelderly/family/admin、nameelderly表id、user_id、name、birthday、address、emergency_contactfamily_bind表id、elderly_id、family_user_id、relation、permission_level为什么要拆成三张表因为一个老人可能被多个家属绑定一个家属也可能同时管理多位老人。如果直接在user表里加一个“老人ID”字段多对多关系就锁死了。拆表之后前端根据role字段判断渲染老人端还是家属端家属端再根据family_bind表拉取自己关联的父母列表。7. 真机调试、打包上架与那些踩过的坑7.1 tabbar输入法顶起的处理开发过程中遇到一个在安卓真机上很典型的问题当输入框聚焦时软键盘弹出来tabbar被顶起来或者出现跳动闪烁非常影响体验。排查发现是页面adjust-position默认行为和tabbar原生栏直接冲突导致的。我的处理方式分两步第一步在pages.json涉及输入框的页面配置app-plus: {softinputMode: adjustPan}让软键盘使用平移模式第二步最关键的一步——像“服务地址填写”这类需要输入的页面我干脆不使用tabbar页面而是做成普通子页面避免tabbar和键盘同时出现的场景。实测下来这个方案最稳几乎再没出现过tabbar被顶起的问题。7.2 自定义分享好友功能需求方希望老人能一键把小程序分享给子女子女点开卡片就能绑定成为家属。这就要用微信小程序的分享能力。在UniApp里默认分享行为需要在每个页面配置onShareAppMessage。我封装了一个通用分享// utils/share.js export function shareApp(message, path) { return { title: message, path: path, imageUrl: /static/share-card.png } }然后在需要分享的页面里onShareAppMessage() { return shareApp(我在使用长辈健康服务快来绑定关注我, /pages/family/bind?elderlyIdxxx) }这里有一个很重要的细节分享卡片跳转的路径里携带的elderlyId属于敏感参数不能直接暴露明文的用户ID。我的做法是传一个短期有效的token参数后端解析后再绑定防止有人恶意拼接他人ID去绑定别人的档案。7.3 iOS机型网络请求失败率高的排查线上反馈里出现过“iPhone上经常请求失败、安卓没事”的情况。这个问题的常见原因有几个第一后端用的是自签名证书或HTTPS证书链不完整iOS对证书链的校验比安卓严格第二小程序后台没有配置request合法域名iOS在部分网络环境下表现得更敏感第三请求超时时间设置太短iOS蜂窝网络切换时的握手过程比WiFi慢。我当时的排查路径是先在真机上打开调试模式看控制台报错信息确认是证书问题还是域名问题然后检查小程序后台的request合法域名配置确认域名和证书是匹配的最后把超时时间从默认的几秒调整到10秒。这几个动作做完iOS端的请求成功率基本就上来了。7.4 打包上架与隐私合规的提醒小程序开发完成后在HBuilderX里点“发行 → 小程序-微信”会在dist目录下生成小程序代码包。然后打开微信开发者工具导入这个目录上传代码再去微信公众平台提交审核。审核的坑主要在三处第一隐私协议小程序里如果采集了位置、相册、手机号必须在后台配置“用户隐私保护指引”并在App内展示隐私政策入口第二定位用途描述调用getLocation时必须有一个页面明确告知用户“为什么需要定位”不能只在代码里声明第三类目问题老人服务类小程序往往涉及医疗健康相关内容如果写了“在线问诊”这类功能审核方会要求提供相应的资质如果项目初期没有资质建议先不要上这类功能。如果还要上架安卓应用市场UniApp可以走云打包在HBuilderX里配置好证书生成apk/aab。国内各应用市场的要求差异比较大像华为、小米、OPPO都有自己的隐私合规检测需要填写的权限声明比小程序更严格。我的建议是先把微信小程序跑稳再考虑App端同一套UniApp代码到App端基本只需要做适配性调整不用重写。我在实际开发里的体会是老人服务系统这类项目技术上并不需要多惊艳真正难的是每一处交互都站在那个眼睛不太清楚、手指不太利索、又希望被关心的人的角度去设计。从需求砍到功能排序从字体大小到分享路径的参数安全性每一环都需要认真对待。后面的扩展方向上语音交互相对于现在的按钮式操作会更友好健康数据如果能对接智能手环或血压计价值也会上一个台阶不过那要等下一轮迭代了。