健康管理App开发

项目背景

这是一个医疗健康方向的多端产品矩阵，横跨 14 个代码仓库，最后提交时间从 2020 年 1 月延伸到 2026 年 7 月。仓库里包含眼健康筛查 App、心电相关系统（服务端 287 个 Java 文件，配套 Web 端 81 个 Vue 文件）、医院端平台、诊断辅助系统（后端、Web 与小程序端），以及覆盖安卓、iOS、H5、平台与服务端的五端产品。技术栈以 Objective-C 与 Swift 做 iOS 端，Java 加 Vue 做服务端与 Web，JavaScript 做 H5。它的特点不是某个端做得多深，而是端多、产品线多，且都围绕同一条筛查业务。

客户当时的状态

这类项目的难处不在界面，在业务的一致性。筛查流程本身是标准化的：量表、问卷、图像采集、结果出具，每一步都有固定动作；但不同端的使用者完全不同——被筛查的人、现场操作人员、医生看的是三套东西。医疗数据又敏感，不能随手导出流转。多端并行还有一层现实压力：如果每个端各自实现一遍筛查逻辑，量表一改就要改五处，改漏一处就会出现同一份数据在不同端口径不一致。

我们的做法与取舍

第一个取舍是把筛查流程抽象成可复用的标准动作。量表、问卷与图像采集按统一结构定义，各端只负责呈现与采集，不各写一套判断逻辑。代价是前期要把流程梳理干净，收益是流程变更时改动集中在一处。

第二个取舍是多端并行推进，而不是一个端一个端串着做。串行虽然每步更稳，但业务方等待时间太长，后面做的端还容易和前面出现偏差。并行要求接口先定下来，对前期设计要求更高。

第三个取舍是把医疗数据的处理边界写进设计里。涉及健康信息的部分，我们只做系统内必要的采集、存储与流转，不预设可以随意导出或二次使用。

系统怎么承载这条链路

系统按产品线拆分：筛查与采集类应用负责前端流程，服务端承载业务与数据，Web 端供医院与运营使用，诊断辅助部分另有小程序入口。心电这一类有相对独立的数据模型，单独作为一条线维护。各产品线共享的是筛查流程定义与用户体系，而不是共享一整套代码——这样一条线出问题，不会连带影响其他线。

交付状态与边界

代码处于持续维护状态，最近一次提交在 2026 年 7 月，最早可追溯到 2020 年 1 月。需要说清楚的是边界：我们不提供医疗诊断结论，也不为诊断准确性背书，系统承载的是筛查流程、数据采集与结果出具；医疗数据的使用与对外提供按主管机构规定执行，我们只按约定负责系统内的处理；采集类硬件设备的采购与相关资质事项不在开发范围内。