ChangeSUS今年年中接到一个政务类应用的改造任务：证件核查完成后，审批人要在移动设备上完成在线审批，并且用手写笔迹完成电子签名，核查结果、签名图片、审批意见都要一起归档。最初我以为只是做一个手写签名组件，真正落地方案时才发现，核心难点根本不在画布上，而在于：React Native怎么在鸿蒙设备上稳定运行，笔迹采集怎么保证不丢点、不漂移，签名数据怎么和审批状态绑定，以及归档数据怎么才能做到可追溯、不可抵赖。这篇文章把整个项目的选型、鸿蒙化改造、签名组件实现、审批联动、存档合规和踩坑记录完整写出来，给准备做RN鸿蒙化或者电子签名功能的朋友一个参考。
1. 证件核查审批的业务链路：签名不是画布，而是流程终态
1.1 真实场景：核查、审批、签名、归档这四个环节分别是谁
这种需求通常出现在政务窗口、金融机构远程柜面、行政执法现场、保险定损等场景里。业务链路大致是：一线核查人员先录入证件信息，上传到后端调用外部证件核查接口，拿到核查结果；结果返回后并不是直接生效，而是需要有一个审批动作，通常由带权限的组长、主管或授权审批人对核查结果进行确认；确认的动作在移动端体现为手写电子签名，同时附上一句审批意见（同意或驳回）；确认后的完整数据包——核查结果、签名图片、签名人、审批意见、操作时间——一起落库归档，后续随时可以调出来审计。
我见过不少团队把这种需求简单理解成“做一个签名板”，结果交付后业务方不满意，因为签名画上去之后，既没有跟核查记录绑定，也没有审批状态流转，更没有归档审计能力。所以项目启动前，一定要先把业务链路里的角色和环节理清楚。
1.2 把需求拆成四层，避免做成一坨“会画画的页面”
从技术实现角度，这个需求可以拆成四个层次：
- 交互层：签名面板，负责采集用户手写笔迹，支持清空、重签、确认。
- 数据层：签名图片数据、签名人ID、签名时间、审批意见、设备信息、核查结果快照。
- 控制层：审批状态机，从待审批到审批中，再到已通过或已驳回。
- 归档层：持久化存储、防篡改校验、审计查询。
四个层次缺一不可。只做交互层，需求完成度可能不到30%。整个项目的难点分布也很不均匀：交互层大概占20%的工作量，控制层占30%，归档层占30%，剩下的20%是鸿蒙化和联调排查。
我当时的实现顺序是：先确定数据模型，再搭审批状态机，最后才写Canvas签名面板。因为签名面板界面改起来最直观，最容易返工，放在后面做反而能避免返工。
1.3 跨平台的硬约束：Android存量、鸿蒙试点、iOS后台并存
为什么不直接做一个鸿蒙原生App？因为项目现场有三个硬性约束：
- 存量Android设备上已经有一套稳定的业务App，里面包含证件录入、核查结果展示、历史记录查询等功能，不能推倒重来。
- 新采购的一批终端是鸿蒙设备，可能是HarmonyOS NEXT这种不兼容Android APK的系统，旧App装不上去。
- iOS设备主要用于后台管理的只读场景，也需要同一套业务逻辑覆盖。
这就意味着：前端必须跨平台，业务逻辑尽量复用一套代码，Android、鸿蒙、iOS三个端各自只做薄薄的原生壳和必要的桥接模块。React Native在这种情况下几乎是顺理成章的选择。团队原本就有RN的开发和调试经验，存量功能里有很大一部分业务页面可以直接迁移，不需要用ArkTS重写一遍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 方案对比与最终选型：React Native如何进入鸿蒙战场
2.1 三个候选方案横评：纯鸿蒙原生、Flutter、React Native
立项时团队内部开了两次会，列出的候选方案很典型：纯ArkTS原生开发、Flutter、React Native。三者的取舍点不太一样。
| 维度 | 纯ArkTS原生 | Flutter | React Native（+react-native-harmony） |
|---|---|---|---|
| 存量代码复用 | 几乎为零，全部重写 | Dart代码需重新实现，业务逻辑可参考 | RN页面和JS业务逻辑可直接复用 |
| 团队学习成本 | 需要系统学习ArkTS和ArkUI | 需要学习Dart和Flutter框架 | 已有RN基础，学习鸿蒙桥接即可 |
| 鸿蒙适配成熟度 | 最高 | 社区方案逐步完善，但部分插件缺失 | 核心框架可用，部分第三方原生组件需自研桥接 |
| 多端一致性 | 只覆盖鸿蒙，其他端仍要维护 | Android/iOS/鸿蒙一致性好 | 三端一致性好，取决于桥接层质量 |
| 原生能力调用 | 直接调用系统API | 通过Platform Channel或FFI | 通过原生Module桥接 |
从上面看，Flutter本身是个很好的框架，但在这个项目里的最大问题不是性能，而是存量业务资产。已有的RN页面、状态管理、接口请求层、工具函数都是现成的，如果切到Flutter，相当于把老业务重写一遍，而且重写过程中还会引入大量与业务无关的兼容性Bug。纯ArkTS原生就更不用说了。
2.2 最终选型理由：存量业务复用和团队技术栈
最终拍板选React Native，核心原因就两条。
第一个原因是存量业务复用。我们原有的证件核查业务页面、拍照上传逻辑、表单校验、列表筛选这些模块，全部是RN实现的，逻辑代码大部分可以原样搬到鸿蒙工程里。移动端只需要对相机、文件、签名这几个强原生依赖做鸿蒙桥接，其余页面能快速跑通。
第二个原因是团队技术栈。团队里前端工程师比原生工程师多，RN相关的招聘和培训成本明显更低。如果选了纯ArkTS，等于要所有人从头学一门新语言，项目排期根本兜不住。
不能说React Native是“最优解”，但在我们这个项目里，它就是当时约束条件下的“最满意解”。
2.3 选型前必须向老板和团队确认的三件事
选型不能只看技术文档，落地前有几件事要先确认好，不然后面全是坑。
第一，确认目标鸿蒙设备的系统版本是API 10还是API 12，以及是否兼容Android APK。HarmonyOS NEXT这种不兼容APK的设备，要求RN桥接层走完整的react-native-har