鸿蒙环境下用React Native实现量表评分：选项索引映射与适配实战

1. 项目背景：为什么在鸿蒙环境下做量表评分

1.1 这个需求从哪来，PHQ-9/GAD-7到底是什么

PHQ-9（患者健康问卷抑郁量表）和GAD-7（广泛性焦虑障碍量表）是精神科和临床心理科最常用的两个自评筛查工具。PHQ-9一共9个条目，GAD-7一共7个条目，每个条目的选项都是四级频率描述：“完全没有”“有几天”“一半以上天数”“几乎每天”，对应0到3分。把各条目得分累加，得到总分，再按5分、10分、15分、20分这样的分界值划分严重程度。

我接到这个需求的时候，产品经理给的原话是：“咱们App要内置心理健康自评模块，用户做完题直接出分，后台把每个条目的选项也存下来。量表规则必须按PHQ-9和GAD-7的标准来，不能自己改。另外UI要快，评估能不能用React Native做，顺便把鸿蒙的包也一起出。”

这里有两个关键点：一是打分规则必须严格符合标准化量表的计分逻辑，二是技术栈要跨Android、iOS、鸿蒙三端统一。React Native从0.71版本开始对鸿蒙有了完整的社区支持方案（react-native-oh-tpl），加上我们团队本来就有RN基础，所以最终选了RN + HarmonyOS适配方案。

1.2 为什么选择React Native而不是鸿蒙原生开发

鸿蒙原生用ArkTS + ArkUI，说实话做列表页、表单页效率不低，但问题是团队里没人写过ArkTS，现学成本高。而RN组件化开发速度快，一套业务代码在Android、iOS、鸿蒙三端复用。尤其是这种量表类页面——结构固定、交互简单、逻辑集中在评分计算上——用RN做非常合适。

选择RN还有一层考量：量表的题目和选项可能后续会变。如果用原生写死，每次改量表都要发版；用RN写，可以把量表配置做成JSON下发，热更新就能调整题目标题、选项顺序、甚至评分映射规则。实际做下来，这个设计帮了大忙，后面运营那边改过两次选项文案，前端一行代码没动。

提示：RN鸿蒙适配目前走的是OpenHarmony的React Native适配层（react-native-oh-tpl），本质上是通过鸿蒙的Ability框架承载RN实例。选型时要确认你用的RN版本对应社区维护的鸿蒙适配包版本，别直接拿Android的依赖硬套。

2. 核心设计：选项索引映射评分到底是怎么一回事

2.1 量表的评分逻辑拆解

PHQ-9和GAD-7的计分规则非常统一：每个条目的选项都是0到3分，总分就是把所有条目的分值直接相加。所以最简单可靠的实现方式是——“选项索引即分值”。

什么意思？假设我们定义选项数组：

javascript复制const PHQ_OPTIONS = [
  { label: '完全没有', score: 0 },
  { label: '有几天', score: 1 },
  { label: '一半以上天数', score: 2 },
  { label: '几乎每天', score: 3 }
];

用户选中第几个选项，就取对应的score值作为该条目的得分。这个映射关系简单到不能再简单，但你千万别觉得简单就轻视它，真正容易出错的点在“用户没作答的题目怎么处理”“多题共用一套选项时怎么避免状态串了”“总分计算时怎么保证所有题目都已作答”。

PHQ-9的总分范围是0到27分，GAD-7是0到21分。分级标准容易记混，PHQ-9是5/10/15/20四个分界线，GAD-7是5/10/15三个分界线。就是说不光是计算总分，连结果解读也要按量表各自的规则来，不能一刀切。

2.2 索引映射、分值和总分的代码实现

核心逻辑其实不多，把关键部分拆开看：

javascript复制// 题目配置，每个条目的选项都是同一个四级刻度
const QUESTION_CONFIG = Array.from({ length: 9 }, (_, index) => ({
  id: `