棕榈大道康复系统做到第二周，我开始把注意力从“跑通脚手架”挪到一屏一屏的界面搭建上。这三天基本没碰复杂的原生交互逻辑，专注做一件事：把 React Native 在鸿蒙设备上的内置组件挨个用熟，用它们把康复训练记录、打卡表单、进度列表这些页面真正撑起来。如果你也在做 React Native 鸿蒙方向的适配，尤其是像我们这样要先交付一套可用的业务页面，而不是先啃底层能力，那么这四天里踩过的一些组件边界问题，应该能帮你少走不少弯路。
这里先交代一下背景：我们做的康复系统分患者端和康复师端。患者端最核心的页面是每日训练计划、训练打卡和进度查看；康复师端则是排期、记录和基础数据维护。最开始我很担心，鸿蒙的内置组件会不会跟 iOS/Android 上表现不一致，导致整套 UI 都要重写。实际做完 Day4~6 之后，我的结论是：常用内置组件的覆盖面已经够用，只要先把边界摸清楚、按照鸿蒙的运行习惯做一些细节调整，业务页面基本不需要依赖第三方 UI 库。
1. 项目背景：康复系统从“能跑”到“组件都用对”
1.1 这一阶段的起点与目标
先说说为什么到了 Day4 才开始认真研究内置组件。前面几天我们主要是在解决工程侧的问题：React Native 工程怎么在鸿蒙设备上初始化、原生工程和 JS 侧怎么联动、打包产物怎么塞进应用。等这些链路通了，页面打开不再是白屏，才有条件进入真正写业务界面的阶段。
Day4~6 的目标非常明确：
- 把训练计划页的长列表做出来，要求能按日期分组、支持下拉刷新；
- 把打卡页的表单做出来，包括训练项目选择、训练时长数字输入、备注文本输入；
- 把训练详情弹层和操作反馈做出来，尽量接近原生的交互手感；
- 顺手把启动阶段的体验问题处理一下，别让用户每次冷启动都盯着白屏。
这一阶段我们没有引入任何额外的 UI 组件库。原因很直接：康复系统的界面结构不算复杂，核心就是列表、卡片、表单、弹层。这些用 React Native 内置组件完全能实现。在鸿蒙这种还在快速迭代的运行环境里，第三方库的适配往往滞后，与其去调试一个不兼容的三方日期选择器，不如先用内置组件搭一套稳定的界面骨架。
1.2 为什么只盯着内置组件
很多做 RN 开发的朋友习惯了“缺什么就 npm 装什么”，但到了鸿蒙侧，这个习惯得改一改。新架构、新原生能力、新的发布节奏，导致社区里许多组件的原生代码还没有完整编译进鸿蒙的包体。最稳妥的做法是先把内置组件的能力边界吃透，用组合的方式解决问题。
比如日期选择，我没有直接去找一个日历库，而是用 Modal 加自定义的滚轮列表来实现。表面上多写了一些代码，但实际上避开了“第三方原生组件在鸿蒙上未编译、接口不存在”这一类最棘手的问题。内置组件还有一个好处是 API 心智模型稳定。你在 iOS 上怎么写 FlatList，鸿蒙上基本还是同样一套写法，团队协作时不用额外记一套差异。
所以后面这几天的记录，本质上就是一份“用内置组件搭康复系统业务页面”的实战笔记。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 内置组件兼容性摸底：把不确定项提前找出来
2.1 组件可用性清单
开始写页面之前，我做了一张简单的组件盘点表。不是说每个组件都要列一遍，而是把我预期会用的组件拿出来，在鸿蒙设备上逐一跑最小示例。
| 内置组件 | 预期用途 | Day4~6 实测结论 |
|---|---|---|
| View | 布局容器、卡片背景 | 基础能力稳定，关注圆角与阴影表现 |
| Text | 标题、正文、状态标签 | 稳定，注意字体缩放适配 |
| TextInput | 打卡表单、搜索框 | 基础输入没问题，多行输入与键盘避让需要处理 |
| ScrollView | 页面滚动、表单滚到底 | 稳定，适合子元素较少的长页面 |
| FlatList | 训练计划列表、历史记录 | 稳定，长列表性能需要显式配置 |
| Pressable | 卡片点击、按钮反馈 | 比 Touchable 系列更好用，压感状态清晰 |
| Modal | 训练详情弹层、确认弹窗 | 基础能力可用，透明遮罩类的样式要小心 |
| RefreshControl | 列表下拉刷新 | 通过 FlatList 的 refreshing 属性接入可用 |
| Image | 用户头像、康复示意图 | 本地与网络图片基本都能显示 |
这张表看起来平平无奇，但对后面的排期很有用。前端排期最怕的就是某个组件写到一半发现运行时和预期不一致，被迫返工。提前跑一遍最小示例，相当于把风险前置了。
2.2 摸底过程中容易误判的两个点
第一点是 Text 的字体对齐。鸿蒙设备上部分中文字体在行高、垂直对齐上跟 Android 略有差别，同样的 lineHeight 写出来，视觉效果会比 iOS 上偏上或偏下。后来我们在全局样式中统一给 Text 设了一个基准行高，遇到多行文本优先用 textAlignVertical 配合，避免文字贴边框。
第二点是 View 的阴影。iOS 上用 shadowColor、shadowOpacity、shadowRadius，Android 上经常需要 elevation，鸿蒙的渲染引擎对这两套属性的支持并不完全一致。实测下来，卡片阴影最稳妥的方式还是用带边框的浅色 View 去模拟层次感，或者把