东予薏米前阵子朋友找我帮忙看一个社区健康类小程序的方案，需求方想做一个“中医体质＋社区问诊＋居民健康档案”的一体化系统，而且明确要求必须能跑在 Android 环境下，最终形态又要是小程序。乍一听好像有点绕——又是 Android 又是小程序，到底服务端在哪端、管理端在哪端、居民用哪个入口？等我把里面那层逻辑理顺之后才发现，这个需求其实非常典型：物业型社区医疗、企业园区健康角、基层公卫驿站这类场景里，运营人员手里拿的基本都是 Android 平板或安卓手机，而居民侧最轻的交互方式就是小程序，扫码即用、不用装 App。今天我就把这个项目的完整设计思路、体质辨识算法落地方案和排坑过程写出来，给正在做类似社区健康管理系统的朋友一个可复用的参考。这个项目适合两类人看：一类是刚接触 uni-app 跨端开发、想搞明白“Android 壳 + 小程序端”到底怎么配合的开发者；另一类是产品经理或项目经理，想知道中医体质这种偏传统理论的东西，怎么转化成一套能工程化、可量化、可追溯的数字系统。
1. 为什么是“Android 端 + 小程序”双端形态
1.1 双端职责划分的底层逻辑
很多第一次看到这个标题的人都会问：既然做小程序，为什么还要扯上 Android？甚至有人会直接把它理解成“做一个 Android 手机上的问诊 App”。其实这里头的角色划分是这样的：
- Android 端：面向社区医疗站的工作人员，用的是
Android Studio开发的原生工程或通过uni-app打包出来的管理端。主要职责是录入居民档案、维护坐诊安排、查看问诊排队记录、管理中医体质评估任务。因为使用场景是在社区卫生站前台或诊室里的固定设备上，所以 Android 平板是最合理的选择——便宜、可控、可以锁应用。 - 小程序端：面向社区居民。用户不需要下载 App，在微信里搜一下或者扫个码就能填体质评估问卷、预约社区医生问诊、查看历次健康记录和体质报告。
这里必须强调一个关键点：哪怕你用的是 uni-app 这种跨端框架，也不代表 Android 端和小程序端的业务代码可以完全共用。管理端的界面密度高、信息展示量大，适合用宽屏平板来呈现；居民端则要足够轻、路径足够短，老人也能按得动。所以我的做法是——在同一个 uni-app 工程里通过条件编译分平台输出，但两端的页面结构完全独立设计。管理端用了 split-view 的布局来保证列表和详情同屏；居民端则全部是上下层级关系的小程序页面，一个页面只干一件事。
1.2 体质辨识服务的跨端复用
体质辨识和问诊记录这部分逻辑比较重，而且后续可能还要扩展微信服务号、PC 管理后台等多入口，所以我没有把算法写死在端上，而是抽成了独立的后端服务。Android 管理端和小程序端都通过 HTTPS 调统一接口，这样居民在小程序里填的量表数据、管理端在 Android 上录入的线下问诊记录，最终都能汇到同一条业务链路上。
服务端技术栈我用的是 Spring Boot，数据库用 MySQL，体质辨识相关的规则引擎单独做了一个模块，方便后续调整算法而不用动两端代码。整体协作模式是：小程序负责采集居民端信息，Android 管理端负责线下核实和补充巡检数据，服务端负责算体质、建档、推报告。这样的三角结构，下面每一块单独拆开讲都有一堆细节。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从“望闻问切”到可计算的九型体质辨识算法
2.1 九型体质分类绝不是空泛的玄学标签
要把中医体质理论工程化，第一件事就是明确它到底有没有一个可操作的标准。实际上中华中医药学会发布的《中医体质分类与判定》标准里，对体质类型的定义是非常清晰的——九种体质类型（平和质、气虚质、阳虚质、阴虚质、痰湿质、湿热质、血瘀质、气郁质、特禀质），每一种都有对应的症状表现和判定量表的条目，比如“平和质”的判定条目里有“精力充沛”“不易疲劳”这些正向条目，而偏颇体质则各有各的负向条目集。
这套标准落到系统里的核心，是一份标准化的《中医体质分类与判定自测表》，分 9 个亚量表，共 60 多个条目，每个条目按 5 级评分（没有／很少／有时／经常／总是）。居民端的评估流程就靠这份量表来驱动。
量表设计的时候有个产品层面要特别小心的地方：不能把全部 60 多个题目一次性堆在一屏上，尤其是目标用户里有相当一部分是中老年人。我实际做的时候把题目拆成了 4 步，每一步只展示一个体质维度下的 7~8 道题，每题用大字号的单选卡片，点选后自动跳到下一题，并配了进度条。这种交互在小程序端实现并不难，但对完成率的提升非常明显——测试阶段全量一屏展示的弃答率是 38%，改成分段式之后弃答率降到了 6% 左右。
2.2 原始分到转化分：判定规则的工程化表达
判定标准里最核心的算法其实就是两个公式：
- 原始分 = 该亚量表各条目得分之和
- 转化分 = （原始分 − 该亚量表条目数） ÷ （该亚量表条目数 × 4） × 100
每个亚量表按转化分做判定：
- 平和质：转化分 ≥ 60 分，且其他 8 种偏颇体质转化分均 < 30 分时，判定为“是”；≥ 60 分但其他偏颇体质有 ≥ 30 分的情况，判定为“基本是”；否则判定为“否”。
- 偏颇体质：转化分 ≥ 40 分判定为“是”；30~39 分判定为“倾向是”；< 30 分判定为“否”。
这套规则看起来简单，但落到代码里有一个极容易踩的坑——边界条件的范围区间到底用开区间还是闭区间，下面这段是调整次数最多的判定代码，最终版本长这样：
javascript复制function judgeConstitution(scores) {
// scores: { pinghe: rawScoreObject, qixu: rawScoreObject, ... }
const results = {};
for (const type in scores) {
const { sum, count } = scores[type];
const conversion = count > 0 ? ((sum - count) / (count * 4)) * 100 : 0;
results[type] = {
conversion: Math.round(conversion * 10) / 10,
original: sum
};
}
const isPinghe = results.pinghe.conversion >= 60;
const hasPartial = Object.keys(results)
.filter((t) => t !== 'pinghe')
.some((t) => results[t].conversion >= 30);
let constitution;
if (isPinghe && !hasPartial) {
constitution = '平和质';
} else {
// 找转化分最高的偏颇体质
const biasTypes = Object.keys(results).filter((t) => t !== 'pinghe');
biasTypes.sort((a, b) => results[b].conversion - results[a].conversion);
const top = biasTypes[0];
if (results[top].conversion >= 40) {
constitution = getTypeName(top);
} else if (results[top].conversion >= 30) {
constitution = getTypeName(top) + '倾向';
} else {
constitution = '基本平和质';
}
}
return { result: constitution, details: results };
}
这段代码的关键，一是那条“平和质必须是其他所有偏颇体质都低于 30 分才算真平和”的规则，很多人第一次实现会漏掉这个条件，导致大量用户被误判成平和质；二是转化分保留一位小数时，天花板正好卡在 30 分或 40 分的情况——有的用户 29.95 分被四舍五入成 30.0 分，直接从“否”跨进“倾向是”，这就引发了下面第 4 章里我会细聊的测试事故。
2.3 算法验证阶段的“双人盲评”测试
体质辨识算法有个和普通评分系统完全不同的验证难题——你没法用一个唯一正确的标准答案去校验结果。同样是怕冷、乏力、容易感冒这三组症状，不同的中医师可能会给用户判出“气虚质”或“阳虚质”两种结论。
我当时和项目里合作的一位中医师商量了一套两轮验证法：
第一轮，先把 200 名志愿者的量表答案导出，交给两位中医师各自独立判体质，不让他们看到彼此的结果。然后我把算法判定结果也混进去，比较两两之间的一致性。结果显示算法和医师 A 的一致率是 78%，和医师 B 的一致率是 82%，但 A 和 B 两个人自己的一致率也只有 84%——这说明 78%~82% 的算法一致率基本已经达到了“真人医师之间的共识水平”。
第二轮，把分歧案例挑出来做会诊，总结出规律，大部分分歧集中在“气虚质”和“阳虚质”的边界样本上。有人回答问题的时候，“怕冷”和“容易气短”同时选了高频，这时候算法会因气虚亚量表的题目数更多而把总分拉高，判成气虚质。如果完全按原表走，这不能算错，但如果你想要结果更贴近临床直觉，可以把这类混合表现处理成“兼夹体质”，比如“气虚质兼阳虚倾向”。如果产品允许输出兼夹体质，这会是一个非常有价值的优化点。
3. 问诊与健康管理的数据链路设计
3.1 管理端的“建档—评估—问诊”三段式操作流
体质辨识虽然是最抓眼球的功能，但整个系统的主干其实是问诊管理。没有问诊环节支撑，体质评估就是一个孤立的调查问卷，用户填完拿个结果就走了，后续没有服务承接，留存基本为零。
社区医疗站的实际业务流是：居民先在小区物业或社区服务站扫码打开小程序，完成体质评估 → 拿到初步体质报告 → 如果有进一步需求，在小程序里按时间段预约线下问诊 → 到了预约时间，社区医生在 Android 管理端看到当天的号序列表 → 问诊之后医生会在管理端填写电子问诊单和健康指导建议 → 居民端收到问诊反馈和更新后的体质健康档案。
Android 管理端的首页我设计成一个按“今天/未来 7 天/全部”切换的预约时间线视图。这样医生一早打开平板就能知道今天一共几个号，哪个时段比较空，是否需要临时加号。时间线里每个卡片会显示居民头像、年龄、既往体质类型、本次问诊主诉，下面有三个快捷按钮：“开始问诊”“改约时间”“添加备注”。预约状态流转如图：待接诊 → 问诊中 → 已完成/已取消，全部由管理端驱动，小程序端只负责展示状态，不能自行修改——这一点在权限设计上要非常明确，居民的改约操作必须走“取消后重新预约”流程，不允许直接改已确认的号源，否则号表会和医生的排班逻辑打架。
3.2 问诊单模板怎么设计才不会踩“非法行医”的线
健康问诊管理系统最怕的就是合法性问题。社区医疗站不是三甲医院，不能做诊断，更不能开处方。所以问诊单字段在设计时必须把系统定位成“居民健康信息管理工具”，而不是“在线诊疗工具”。
我的做法是在问诊单里只保留这些字段：主诉、现病史描述、既往史（用户勾选常见慢病标签）、体征测量项（血压、心率、身高体重）、生活方式记录（睡眠、烟酒、运动频率）、中医体质评估结果、医生建议（非药理性建议，例如饮食宜忌、作息调整、情志调摄）。系统里不设置任何诊断结论字段、不提供处方笺打印功能，并且在问诊单底部固定输出一行提示：本记录仅供参考，不作为疾病诊断依据，如有不适请前往正规医疗机构就诊。
技术上有一块很容易被忽略的是数据合规设计——居民的健康数据属于敏感个人信息。我在做数据库设计的时候，把居民的基本身份信息（姓名、手机号、身份证号）和健康档案表拆成了两张独立的表，通过一串随机生成的 uuid 关联，而不是直接用身份证号做主键外键。这样即便将来某张表被拖库，攻击者也没法把“张三”和“张三的体质报告”对上号。小程序端的健康档案查询也要求每次进入时二次验证身份，不保存登录态里的敏感数据。
3.3 消息触达：模板消息和订阅消息的取舍
问诊流程里最容易被忽略的是通知环节。预约成功后要通知用户；医生在管理端确认号序后要再通知一次；问诊完成生成报告后还要通知一次。这三次通知在小程序端对应三种不同的机制：
- 第一类（预约成功）：用的是支付成功后的模板消息，但后来微信收紧了模板消息的使用场景，医疗类目下已经不太能用通用模板了。
- 第二类（号序提醒）：采用订阅消息，用户点“同意”后，后端在医生操作“确认接诊”时调用一次订阅消息下发接口。
- 第三类（报告生成）：同样走订阅消息，但要注意订阅消息的
一次性特性——用户每次需要授权才能收到下一次通知。
实测下来这块的坑在于：订阅消息的一次性授权，在问诊这种低频场景里用户流失率并不高，但如果居民一个月内问诊多次，用户很容易忘了第二次要重新点授权。后来我做了一个在报告页询问“下次问诊提醒我”的引导按钮，顺便在按钮触发里重新拉起了一次订阅授权，把授权失败率从第一版的 32% 降到了 9%。这个案例说明，凡是依赖微信订阅消息的业务，都必须设计“在业务环节内部自然回补授权”的入口，而不是指望用户主动去找设置开关。
4. 实际开发中绕不开的四个大坑
4.1 用 HBuilderX 改完小程序 ID 后模拟器里还是旧 ID
这个问题的复现路径非常经典。项目同时要跑小程序端和 Android 管理端，我用 HBuilderX 作为 uni-app 的 IDE。某次从一个演示项目把代码拷贝过来之后，我在 manifest.json 的小程序配置里把 appid 改成了新申请的小程序 ID，然后在微信开发者工具里运行时，控制台却提示的还是旧的 appid，导致模拟器一直加载不出正确的项目信息。
排查过程：先检查 manifest.json，看着没问题；又检查 project.config.json，也没问题；最后突然想起来微信开发者工具里项目导入的时候会有一次“记忆”，也就是微信开发者工具右侧详情面板里的 AppID 一旦在导入时被固定，它就不会跟着 manifest 的改动自动刷新。解决方法是把微信开发者工具里的项目目录删掉，从 HBuilderX 重新“运行到小程序模拟器”，让工具重新读取配置文件，必要时还要手动清一下微信开发者工具的编译缓存。这个问题极其隐蔽——它让你以为代码配置写错了，甚至让你怀疑是不是 uni-app 框架本身有全局配置覆盖了本地配置，实际上只是工具层缓存。
4.2 iOS 里 swiper 嵌套 video 导致全屏错位
社区问诊系统里有一个健康宣教板块，会嵌入一些短视频。在小程序端我用 swiper 做了视频轮播，Android 端一切正常，但 iPhone 上一全屏播放再退出，整个 swiper 的滚动位置就会错乱，表现为：当前显示的视频变成空白、滑动到下一帧时页面跳动、最严重的时候卡死在某个位置不能滑。
最开始我以为是 video 组件的 controls 配置问题，反复调了好多参数仍然复现。后来查了微信社区才知道，这是 iOS 上 video 原生组件层级特殊性导致的已知问题——video 在 iOS 上并不是真正的同层渲染，全屏行为会触发原生层的 view 重建，而 swiper 内部的 current 索引和原生层不同步。
最终方案是绕开 swiper 里直接放 video 的思路，把 video 改成封面图 + 点击后弹出全屏播放层的方式。列表区域只渲染封面图和播放按钮，点击之后用 wx.navigateTo 跳到一个独立播放页，在该页面内只放一个 video 组件。这样既解决了错位问题，又把视频加载的耗时从首页列表渲染流程中剥离了，列表滑动帧率也涨了——算是因祸得福。
4.3 管理端白屏：Android WebView 内核引发的兼容问题
Android 管理端我用的是 uni-app 打包成 APK 的方案。某款常用的国产平板（具体型号不方便说）在打开管理端时偶尔会出现白屏，频率大概每三次启动中有一次，重启 App 后恢复，但过一会儿又白屏。
这种偶发性白屏的问题非常折磨人。后来我在平板设置里发现这款平板默认的 WebView 内核版本非常老，连 JavaScript 的 ES6 Promise 都不完全支持。因为 uni-app 打包出来的应用在 Android 上本质上还是跑在一个 WebView 容器里，而老版本内核无法解析新语法——但原生层又没有崩，所以表现出来就是“页面渲染不出来但 App 本身没退出”。
排查工具方面，我用 adb logcat 抓到浏览器内核的报错日志，定位到是某个第三方图表插件里的 ES6 语法降级失败。解决方式是三层：第一层，在 manifest.json 里配置 minSdkVersion 提到 21 以上；第二层，在项目里引入 babel 的 polyfill，保证老内核也能识别常见的新 API；第三层是把那款平板的内置 WebView 手动升级到最新版（在系统设置的应用管理里可以操作）。后来稳定跑了一个月，没有复现白屏问题。
4.4 体质量表精度：29.95 分的“卡线魔咒”
前面讲判定算法时我提过一嘴的边界问题，这里详细展开。内测阶段，有一位测试同学提交了一份血脂偏高、平时容易疲劳的问卷。算法算出来，痰湿质转化分 = 29.95 分，因为代码里保留了 1 位小数再四舍五入，结果展示成了 30.0 分，判定直接变成了“痰湿质倾向”。
但需求方的医生说，从症状来看，这位测试者更接近“基本平和质”，并没有到需要干预的临界程度。问题是——按标准，30 分确实是一个“倾向”的起点，标准本身没错，错在展示精度。因为 29.95 和 30.0 之间的差异，实际来源只是某一题的作答从“很少”变成“有时”，这一分都不到的变化，不应该直接影响判定级。
我仔细重新读了标准，发现标准文本里的原话是“转化分 ≥ 40 分为‘是’，30~39 分为‘倾向是’”，并没有明确说这个分值是要保留整数还是保留小数。如果按整数来看，29.95 取整成 29，就是“否”；如果保留一位小数，就成了 30.0，就是“倾向”。
解决方式是在数据库和服务端计算时全部按浮点原值存储，展示时保留一位小数，判定时按 30.0/40.0 作为阈值，但增加一个“分值在 29.5~30.5 之间时人工复核”的标记。这个方案有点保守，但实践证明它是最稳妥的——既不会因为浮点精度问题误判患者，也不会让医生觉得系统“计算错误”。后来我还把这段逻辑写成了注释，后来者维护的时候不会一头雾水。
5. 上线前必须做的性能调优与安全加固
5.1 小程序端的包体控制和首屏提速
社区用户扫码进小程序最怕什么？最怕加载慢。尤其是在小区电梯里扫码，网络信号可能只有一格，如果首页要加载一堆图片和视频封面，用户早就退出去了。
我在做首屏优化时做了三件事：第一，首页静态资源全部走 CDN，并给图片手动指定了宽高，避免页面 reflow 导致的白屏闪烁；第二，体质评估问卷的题目数据不打进主包，而是通过分包加载，页面启动时先拉取一个 list.json 题目索引，只有用户真的开始答题时才加载完整题目配置；第三，把 tabBar 相关的图片全部压缩到 40KB 以下——微信小程序的 tabBar 图标限制是 40KB，超过会被无提示地压缩，画质劣化非常明显，踩过坑才记住。
分包处理还有一个额外收益：主包体积小了之后，微信开发者工具的上传和预览速度快了很多。团队里多人协作时，每个人在微信开发者工具里“预览”的编译时间可以缩短 30% 左右。在“工具决定开发体验”的时代，这个优化对研发效率的提升不可忽视。
5.2 Android 管理端的签名、权限和续航
Android 管理端有一个使用场景经常被忽略——设备全天候挂在诊室前台，屏幕常亮，所以在 AndroidManifest.xml 里需要申请 WAKE_LOCK 权限以外，实际开发里还要尽量降低刷新频率。我的做法是把号序列表改成“拉取一次 + 本地定时器每 60 秒轮询一次”，避免用 WebSocket 长连接维持实时状态。医生手动下拉刷新时再触发一次实时请求。这种方式省电效果非常显著，实测平板续航从 6 小时提升到接近 9 小时。
另一个容易被忽略的坑是 Android 系统的后台省电策略。某些国产品牌平板默认会把不常用的应用列入“后台冻结”名单，一旦管理端退到后台超过几分钟，再切回来时网络请求可能已经因为连接被系统杀掉而全部超时。我最后的解法比较老土但有效：在代码里监听 onShow 生命周期事件，切回前台时强制重新拉一次号序列表，同时在管理端设置页里引导运营人员把 App 加入系统的“不受限制应用”白名单。
5.3 后端接口的传输加密与越权校验
涉及健康数据，接口安全不能停留在“有个登录就行”的程度。我主要做了三个层面的加固。
第一层是 HTTPS 全链路加密。Android 管理端的 APK 里不要内置自签名证书，否则一旦服务器证书轮换，所有客户端会突然集体断连。正确做法是正常的 CA 机构证书，客户端做证书公钥校验（certificate pinning），但这个度要把握好——证书轮换时要有紧急开关，可以一键关闭 pinning 检查，否则运营人员平板上的旧包会全部无法联网。
第二层是权限校验。小程序端居民的接口和管理端医生的接口必须在后端做严格的角色区分。我踩过一次坑：居民端调用了管理端的“获取某个手机号对应的健康档案”接口，原因是后端只校验了“登录态”而没校验“角色和数据归属”。后来我在所有查询接口里强制根据当前登录人的 ID 拼 SQL 条件，而不是信任前端传过来的目标用户 ID。
第三层是操作日志。每次医生查看或修改居民档案，后端都要记录操作人 ID、操作时间、修改前后的 JSON diff。这既是合规要求，也是医疗纠纷时保护自己的证据。不要觉得日志系统不重要，真到了出问题复盘的时候，日志是你唯一的救命稻草。
6. 从“能跑”到“好用”的体验打磨记录
6.1 老人友好化的交互改造
给社区医疗做小程序，一定要认真考虑老年用户。刚开始我们做的版本风格偏现代，按钮小、对比度低、信息密度高，结果在社区里做现场推广时发现，很多五十岁以上的用户根本不敢点——不是点不到，是不确定点了之后会跳到哪里。
后来做了一次大改版。核心变化是三件事：字号全局上调到 17px 以上，关键操作按钮的高度从 80rpx 提到 110rpx；所有页面底部固定一个“返回上一页”的悬浮按钮，而不是依赖微信自带的导航栏返回；每个体质评估的页面顶部加了语音读题按钮，调用微信同声传译插件把题干读出来。这个读题功能看着简单，但对视力下降、阅读吃力的用户来说，它直接决定了一份问卷能不能被独立完成。
改版后的结果显示，评估页面的平均停留时长从 1 分 52 秒下降到 1 分 26 秒，问卷完成率又提升了 11%。这充分说明，在面向社区场景的应用里，把交互做“慢”做“笨”做“大”，反而才是最优解。
6.2 体质报告的通俗化措辞
中医体质报告如果直接把“阳虚质”“痰湿质倾向”之类的结果甩给用户，很多人当场就慌了——有些人会在网上翻半天，越看越觉得自己一身都是病。所以我们做报告展示的时候专门设计了一套“结论 + 解释 + 建议”的文案结构。
结论区里显示主体质类型和兼夹信息；解释区用大白话把这种体质的特征描述一遍（例如“阳虚质：身体阳气不足，容易出现怕冷、手脚凉、精神不振的表现”）；建议区分成饮食调养、起居作息、情志调节、运动建议四个标签页，每页最多列 3 条，每条控制在 30 字以内。体质报告末尾一定加一段免责声明和一句“体质不是病，它只是你当前身体状态的一个描述”。
这种文案设计是有业务逻辑在的：社区健康管理系统如果吓到用户，用户会离开；如果让用户觉得“说得真准”，用户才会愿意回来复测或者找社区医生聊。体质报告的措辞，直接影响到问诊的转化率。
6.3 离线场景下的数据兜底
社区里经常有义诊活动，网速不稳定或现场网络直接断了的情况很常见。小程序端的体质问卷如果全部依赖后端在线提交，网络一断用户前面答的十几题就全白费了。
我最后的方案是做了本地暂存。问卷每完成一个亚量表（一组题目），就把结果写入小程序的 wx.setStorageSync。如果提交接口失败，页面上提示“网络异常，已为您暂存，可稍后重试”，同时在用户下次打开问卷页时检测到本地有未提交数据，主动弹窗提示继续提交。对于 Android 管理端的操作场景，也做了一个简单版的本地待办队列——医生在信号不好的诊室里录完信息后，如果提交失败数据会存到本地 SQLite 里，界面上用一个红色角标提示“有 N 条记录待同步”，点击可重试。这套方案非常朴素，但对义诊这种“现场乱成一锅粥”的场景极其可靠。
7. 从一次上线事故中学到的回滚与灰度经验
上线后第三周遇到一次事故，回想起来挺后怕的。当时为了优化体质报告的展示效果，我改了一版前端渲染逻辑，把之前从后端一次性返回完整报告改成前端先拉体质结果再按 type 去匹配文案。问题是新版的文案表有 3 种体质的 key 拼错了（比如 qixu 写成了 qixv），结果就是部分用户的报告页出现大面积空白。
更要命的是，小程序端我之前没配灰度发布，直接一键全量上线。好在发现的还算快，从后台看到报告接口调用量异常下降，用户反馈也陆续进来。当时我把后端接口回滚到了上一个版本，但因为小程序包上传之后是不能立即回退的（微信的版本发布机制就是这样，只能发新包覆盖），所以只能赶着改代码再提审。
这次之后我把发布流程固定成了三条铁律。第一，前端所有页面必须配置“容错态”而不是“空白态”——渲染数据失败时显示一个兜底提示和刷新按钮，绝不能白屏。第二，涉及文案表这种基础配置的改动，必须跑一遍自动化脚本来校验所有 key 是否有对应文案。第三，微信小程序端一定要用“分阶段发布”功能，先把新版本放给 10% 的用户，观察半天日志再逐步放量。
这套经验听着有点像常识，但没经历事故之前从来不会把它当回事。社区医疗类应用和人命安全沾边，容错设计更加不能省。宁可让用户在页面上看到一句友好的错误提示，也不能让他在面对健康问题时面对一片空白。
个人最终的体会是，这类医疗健康方向的小程序，技术难度一定不是最核心的瓶颈。真正拉开差距的，是能不能把传统中医理论转化成老百姓看得懂、操作得动、用完觉得有价值的数字服务。而 Android 管理端和小程序的配合，本质上要解决的就是“线下服务的数字化接缝”问题——医生在线下问诊时怎么用平板快速建档、居民离开诊室后怎么持续收到健康反馈，这个闭环打通了，系统才算真正有价值。后面如果有余力，可以考虑把膳食推荐、节气养生提醒和体质变化趋势图加进去，再往深了走，甚至可以对接社区已有的智能体检一体机，让居民测完血压体脂直接同步到档案里。这条路能延伸的方向还很多，但地基就是今天聊的这套双端架构和体质辨识中枢，它们稳住了，上面的功能才敢继续盖。