医疗健康类应用开发几乎都会被同一件事反复折磨数据格式没法统一。医院信息系统一套术语体检中心一套结构智能手表吐出来的又是一份私有 JSON想把这些数据在同一个应用里整合、检索、打破信息孤岛光做字段映射就能把人磨秃。这也是为什么我这次的项目从立项第一天就直接锁定了 FHIR R4 标准并且在鸿蒙 HarmonyOS 上完整落地了 Flutter 组件 fhir_r4 的适配目标很纯粹——让医疗数据在鸿蒙生态里真正形成一套闭环的标准流转体系。这篇文章我会把整个适配过程拆开来讲包括环境怎么搭、fhir_r4 组件在鸿蒙上动了哪些手术、FHIR 资产工程怎么建、一致性治理怎么做、性能怎么优化以及踩过的一堆真实坑。内容偏实战适合正在做医疗健康应用、或准备把 Flutter 医疗组件迁到鸿蒙的开发同学参考也适合那些想了解 FHIR 标准到底如何在真实应用中落地的产品和技术负责人。1. 医疗数据标准化的现状与本项目要解决的问题1.1 医疗数据互操作性的现实困境大部分人提到医疗信息化的第一反应是电子病历、在线问诊、报告查询但真正做过这个领域的人都知道表面的功能背后是一场持续多年的数据翻译灾难。不同医院的 HIS医院信息系统、LIS检验系统、RIS影像系统各自演进多年底层数据结构完全是私有化的。一个简单的血常规检验结果在 A 医院可能叫WBC在 B 系统里叫white_blood_cell_count到了第三方体检平台又变成WBCS加一个嵌套数组。字段命名不一致、单位不一致、参考范围不一致甚至连时间格式都有多种变体——2024-01-01、2024/01/01、20240101全都能见到。这种碎片化带来的直接后果是应用开发商每对接一个数据源就要重写一遍解析逻辑患者换一家医院就诊历史数据几乎等于作废哪怕同一个人的体检报告在不同机构之间互相引用也无法自动完成合并和比对。说到底互操作性差的根因不是技术能力不够而是缺少一个被广泛接受的统一语义模型。1.2 为什么选择 FHIR R4 和 fhir_r4 组件FHIRFast Healthcare Interoperability Resources是 HL7 组织制定的新一代医疗数据交换标准而 R4 是目前生态最成熟、工具链最全的版本。相比老的 HL7 v2 的管道文本协议FHIR 以 RESTful API JSON/XML 资源为核心天生就和移动端、Web 端的技术栈同频。FHIR R4 的核心思路是问题拆成资源——患者是Patient资源检验报告是DiagnosticReport资源血压测量是Observation资源就诊过程是Encounter资源。每个资源都有标准定义的字段结构、检索参数和操作语义。这样不同系统之间不再需要一对一的自定义映射而是统一对齐到同一套资源模型上。fhir_r4是 Flutter/Dart 生态里比较成熟的 FHIR R4 实现组件内置了全部 R4 标准资源类包括扩展资源支持fromJson/toJson序列化与反序列化、FHIRPath 表达式解析、Bundle事务包的构建与解析还附带了一整套用于校验资源合规性的工具。在医疗类 Flutter 项目里用fhir_r4作为数据模型层的基础基本可以做到与标准同步而不需要手工维护几百个实体类。选它还有另一层考虑fhir_r4的底层是纯 Dart 实现不依赖 Android/iOS 的原生 SDK这让它具备了跨端移植到鸿蒙的先天条件。后面我会详细讲纯 Dart 依赖在鸿蒙适配中省了多少事。1.3 鸿蒙生态适配的战略价值鸿蒙 HarmonyOS 并不是传统的手机系统形态——它最大的特点是全场景手机、平板、手表、电视、车机、智能家居都能跑同一个系统底座。对医疗健康应用来说这意味着一个非常理想的落地场景用户在手机上建档在手表上采集体征在平板上查看报告在电视上做康复训练展示。这些设备之间如果能跑同一套 Flutter 业务代码、用同一个fhir_r4标准数据模型做数据交换那么全场景的医疗数据一致性就能真正落地。换句话说这次适配解决的不只是让一个 Flutter 组件在鸿蒙上能跑这样的基础问题而是把标准数据管道铺到了鸿蒙生态的每个设备角落为后续的所有健康业务提供统一的基础设施。2. 鸿蒙 Flutter fhir_r4 工程搭建实战2.1 环境准备OpenHarmony Flutter SDK 的选型与版本问题目前要在鸿蒙上跑 Flutter通用做法是使用社区维护的OpenHarmony Flutter SDK也就是 ohos 分支它不是华为官方直接发布的某个稳定版而是基于 Flutter 主版本做的鸿蒙适配。所以第一步就是选版本。以我这次实践为例Flutter 主版本选择的 3.22.x 配套 ohos 适配版本。这里有个非常容易被坑的点Dart SDK 版本与 Flutter 版本是强绑定的而 fhir_r4 组件对 Dart 版本又有最低要求。如果 Flutter 主版本太老Dart 版本过低fhir_r4依赖的intl、collection、meta等包可能解析失败如果 Flutter 版本太新ohos 适配分支又没有及时跟进构建时就会遇到编译错误。建议做法是先去 OpenHarmony 官方 Gitee 仓库确认适配分支对应的 Flutter 版本号再反推fhir_r4的约束范围。实操中我用的是如下组合组件版本Flutterohos 适配分支3.22.0Dart SDK3.4.0fhir_r40.9.5OpenHarmony SDKAPI 11安装完成后需要把flutter命令行工具切换到 ohos 分支的可执行文件并且要安装配套的ohos插件。运行flutter doctor时可能不会自动识别鸿蒙工具链需要手动检查环境变量里是否包含OHOS_SDK_HOME指向本地解压好的 OpenHarmony SDK 目录。2.2 创建 Flutter 鸿蒙工程的关键配置工程结构上鸿蒙 Flutter 项目的宿主壳是DevEco Studio 工程Flutter 的 Dart 业务代码作为模块被集成进去。实际操作中我建议用两种方式配合先用flutter create --platforms ohos生成 Flutter 侧的项目骨架前提是你安装的 ohos 分支支持该参数再用 DevEco Studio 创建一个标准 HarmonyOS 工程最后把 Flutter 模块作为依赖接入。这里有一个容易忽略的细节鸿蒙工程构建时使用的是hvigor构建系统和 Android 的 Gradle 不完全相同。所以android/app/build.gradle里的配置思路不能直接照搬需要在 DevEco 项目的build-profile.json5里配置模块依赖并在oh-package.json5中声明对 Flutter 模块的依赖。// oh-package.json5 { name: entry, version: 1.0.0, dependencies: { flutter: file:../flutter_module } }同时在entry/src/main/module.json5中要注册 Flutter 的 Ability 和页面路由。要特别注意的是鸿蒙 API 版本和compatibleSdkVersion的一致性否则真机调试时会出现版本过低导致 API 调用失败的问题。我在第一轮适配时就因为compatibleSdkVersion写的 API 9导致 fhir_r4 依赖的dart:io相关网络行为在 API 11 设备上表现异常白白排查了两天。2.3 最小验证跑通 fhir_r4 在鸿蒙上的第一个解析 Demo工程能跑起来之后先别急着写业务代码我建议马上做一个最小验证——把一段 FHIR 标准 JSON 塞给fhir_r4看它能不能在鸿蒙设备的 Dart VM 里正确解析。这一步能快速暴露底层兼容性问题避免后面业务越写越多、定位越来越难。我当时的验证代码非常简单一个Patient资源的 JSON 字符串调用Patient.fromJson解析再调toJson转回去对比字段是否一致。import package:fhir_r4/fhir_r4.dart; void main() { final patientJson { resourceType: Patient, id: example-001, active: true, name: [ { family: Zhang, given: [San] } ], birthDate: 1990-04-01 } ; final patient Patient.fromJson(patientJson); print(解析成功${patient.name?[0].family}); print(resourceType${patient.resourceType}); final backToJson patient.toJson(); print(序列化后 id${backToJson[id]}); }这段代码在 Android 上跑通不算什么但在鸿蒙上能一次通过说明 Dart 层的 JSON 编解码、集合操作、枚举序列化等基础能力都没有兼容性问题。我在真机上跑完这个 Demo 后信心增加了不少——因为fhir_r4的很多数据模型都是纯 Dart 嵌套类只要这个链路没问题后面 90% 的解析逻辑都能直接复用。当然这一步也遇到一个意料之中的坑fhir_r4内部会用到intl包做日期格式化而intl默认的 locale 数据在部分鸿蒙 ROM 上加载会有时区偏移。后文会有专门一节讲这个问题的根因和解决方案。3. fhir_r4 组件的架构拆解与鸿蒙端兼容改造3.1 fhir_r4 包的核心模块与资源模型fhir_r4并不是一个简单的 JSON 解析库它的内部结构更接近一个完整的 FHIR 实现框架。它把 FHIR R4 标准里的所有资源约 145 种都定义成了强类型 Dart 类并且提供了三类核心能力资源类型体系Resource作为抽象基类Patient、Observation、Encounter、DiagnosticReport等资源类型继承自它。这种设计保证了任何资源都可以用统一接口处理非常适合做批量校验和通用化存储。内部构件类型比如CodeableConcept可编码概念、Identifier标识符、Reference资源引用、Period时间段、HumanName人名这些是 FHIR 资源骨架里的积木块用于组合出复杂的数据语义。语义能力拓展支持Bundle事务包BundleType.transaction、searchset等、OperationOutcome校验结果输出以及一部分 FHIRPath 表达式解析。实际开发中这带来一个很大的便利业务层不需要关心字段名对应的到底是family还是lastName全部由强类型属性约束。你在写observation.valueQuantity?.value时会得到编译期提示而不必在十几个 JSON key 里翻来覆去查文档。3.2 序列化与反序列化机制在鸿蒙上的适配重点FHIR 资源在网络上传输时通常序列化为 JSON这是fhir_r4最频繁使用的路径。适配鸿蒙时以下几个环节是我重点关注的第一fromJson 的健壮性。医疗数据源质量参差不齐报文里经常出现缺字段、多字段、类型偏差比如数字被写成字符串。fhir_r4在这方面做了不少容错设计但它的容错依赖的是MapString, dynamic类型的动态判断这在 Dart VM 上没有问题而到了鸿蒙的 AOT 编译模式下部分动态类型判断的性能会有下降。因此在大批量导入数据的场景下我不建议直接循环调fromJson而是使用Future.wait配合合理并发数来做。第二toJson 的一致性。鸿蒙生态多设备联调时序列化后的 JSON 会被发送给其他设备或后台 FHIR 服务器。这时候字段顺序、空值是否剔除、时间精度是否保留都可能影响对端协议的兼容。fhir_r4默认的toJson会做空值过滤但如果你的后台系统用的是严格校验的老代码可能更希望保留null字段这种情况下需要自定义序列化逻辑。第三日期的标准化。fhir_r4对FhirDateTime、FhirDate类型有严格的格式约束如2024-01-01T10:30:0008:00并且会调用intl包的DateFormat做解析。鸿蒙的运行时环境对时区数据库的访问方式和 Android 不同在某些 ROM 上获取系统时区可能返回空值导致时间类型解析抛异常。我在适配时做了统一的时区兜底// 统一处理鸿蒙设备可能出现的时区空值问题 String getSafeTimeZone() { final tz DateTime.now().timeZoneName; return tz.isEmpty ? 08:00 : tz; }3.3 原生能力桥接与本地依赖处理虽然fhir_r4本身是纯 Dart但在真实业务中它不可能孤立存在——你需要发起网络请求获取 FHIR 数据需要把资源对象存入本地数据库还可能需要调用系统级能力如扫码、蓝牙、安全芯片来采集医疗信息。鸿蒙上的 Flutter 桥接用的是Platform Channel机制和 Flutter 在 Android 上的思路类似但通道名和类型映射需要适配鸿蒙 API。比如在鸿蒙上读取设备信息、调用统一扫码服务时需要在 ArkTS 侧用hilog替代 Android 的Log用ohos.ability相关 API 来获取上下文。如果业务想封装一个给fhir_r4调用的原生健康数据采集模块我建议在鸿蒙侧把采集逻辑封装成一个独立的Ability通过promise或者回调把结果转成 JSON再在 Dart 层交给Observation.fromJson解析。不要试图把大的原生对象直接通过 Channel 传回来鸿蒙的序列化开销对复杂对象会明显放大JSON 字符串仍然是跨语言边界最稳妥的格式。4. FHIR 资产工程与一致性治理架构设计4.1 FHIR 资产的含义与工程化组织FHIR 生态里有一个常被新手忽略的概念——FHIR 资产Artifact。它不是指某个患者数据资源而是指那些定义数据如何组织、表达、校验的元数据资源。最典型的资产包括资产类型作用实际例子StructureDefinition定义资源或数据元素的结构约束自定义血压测量必须包含收缩压和舒张压两个子字段ValueSet枚举可选值集合性别取值绑定到administrative-gender值集CodeSystem定义编码系统及概念自定义一套科室编码表SearchParameter定义资源的检索参数为Observation增加按检查时间范围检索的能力CapabilityStatement描述服务器支持的能力声明本系统支持哪些 FHIR 交互在鸿蒙应用里做 FHIR 适配如果只是把fhir_r4当普通数据模型用那是大材小用。真正专业的做法是把 FHIR 资产也工程化地纳入项目把自定义的 StructureDefinition、ValueSet 等资产以正式文件形式放在工程的fhir_assets目录下配套专门的校验和更新流程。我做第一版时并没有意识到这些东西的价值结果业务越做越深数据字段的语义定义散落在各个业务代码里一个血压高值在不同页面可能有三种单位换算结论。后来把所有字段定义收敛到 FHIR 资产之后整个开发团队终于有了统一的语义字典。4.2 资产版本治理与映射规则医疗数据的另一个特点是语义会随版本演进。同一个诊断术语可能在不同版本的编码系统里有了不同的编码同一种检验项目参考范围也会随人群和试剂批次变化。如果应用的 FHIR 资产没有版本管理就会遇到设备 A 用老版本值集、设备 B 用新版本值集导致的数据互认失败。我会在鸿蒙应用里做一套三层映射厂商私有编码到 FHIR 标准编码的映射比如手表里的HR_AVG映射到Observation.code中SNOMED CT的8867-4历史 FHIR 版本到当前 R4 的映射针对老接口的低版本报文做兼容中文自定义术语到标准值集的映射这部分工作量通常最大每个映射规则都记录在资产的version字段中并且配套map_rule.json做机器可读的映射声明。这样鸿蒙应用内部的数据互操作就不仅仅是字段对上了而是语义也真正对上了。4.3 数据校验引擎保证进入鸿蒙应用的必须是合规 FHIR如果客户端只是尽量遵守标准那么服务端就没法放心消费这份数据。鉴于此我在鸿蒙应用的本地数据层内置了一个校验引擎核心职责有三条结构校验检查资源是否符合对应 StructureDefinition必填字段是否缺失类型是否正确值域校验检查 code、CodeableConcept 的取值是否在绑定的 ValueSet 范围内引用校验检查资源的 Reference 目标是否真实存在、类型是否匹配。fhir_r4本身提供了一部分基于内置 schema 的校验函数但真正的业务级校验比如住院患者必须关联到有效 Encounter要靠自定义校验器。我的做法是定义一个ValidatorT extends Resource接口并针对关键资源类型各自实现校验逻辑。abstract class ValidatorT extends Resource { ListFhirValidationError validate(T resource); } class PatientValidator implements ValidatorPatient { override ListFhirValidationError validate(Patient patient) { final errors FhirValidationError[]; if (patient.name null || patient.name!.isEmpty) { errors.add(FhirValidationError(Patient.name 不能为空)); } if (patient.birthDate ! null patient.birthDate!.after(DateTime.now())) { errors.add(FhirValidationError(出生日期不能晚于当前时间)); } return errors; } }校验失败时不直接丢弃数据而是生成OperationOutcome结果把问题明确反馈给上层或同步给后台。这样处理能保证一些不完全合规但业务有用的数据仍然有机会被部分消费同时问题点始终透明可追踪。4.4 实战基于患者档案场景构建资产流水线我拿患者健康档案这个具体场景来演示资产流水线是怎么跑的采集手表通过蓝牙上报心率、血氧、睡眠时长的原始数据包以私有 JSON 格式到达鸿蒙手机端。转换Dart 层的转换服务将私有 JSON 映射为Observation资源代码部分映射自标准值集数值部分带入统一的 UCUM 单位编码。校验ObservationValidator检查时间戳是否合理、值域是否合法BundleValidator检查批量数据是否有重复 id。入组多个Observation组成Bundle按BundleType.transaction的语义提交到 FHIR 服务器服务器端对账后返回OperationOutcome。入本地缓存ArkTS 侧的轻量数据库记录缓存摘要Dart 侧维护一份与服务器一致的资源索引。这套流水线在鸿蒙上运行的信心来源于fhir_r4的Resource体系因为所有环节的对象类型都继承自同一个抽象基类流水线每一站都可以用泛型方法处理代码复用率很高。5. 性能优化从冷启动到大数据量解析5.1 Impeller 渲染引擎在鸿蒙上的表现与取舍Flutter 从 3.10 开始力推 Impeller 渲染引擎用它替换老旧的 Skia 管线。Impeller 在 iOS 上表现优异但在鸿蒙适配初期并不完全是默认打开状态。如果你发现应用的 UI 出现文字渲染糊、滚动掉帧不要急着怀疑业务代码先检查一下当前 ohos 分支的 Flutter 是否默认启用了 Impeller。在鸿蒙上Impeller 的实现基于 Vulkan 图形接口。API 11 及以上的鸿蒙设备普遍支持 Vulkan但部分低端机型驱动的兼容性堪忧。一个合理策略是低端机 / 老设备关闭 Impeller回退 Skia保证基本流畅度中高端设备开启 Impeller获得更快的着色器编译和更少的路由卡顿。打开方式是在main()里显式配置void main() { // 鸿蒙 ohos 分支可用的开关示例 if (deviceSupportsImpeller()) { FlutterRendering.setImpellerEnabled(true); } runApp(const HealthApp()); }在医疗图表这类复杂绘制场景比如趋势折线、热力分布“渲染引擎调好 数据解析高效”是双保险。我实测过同一条心率趋势曲线开启 Impeller 后滚动体验明显比默认 Skia 顺滑尤其是在多图叠加场景下。5.2 大数据量 JSON 解析与分页策略FHIR 的Bundle在一次查询中可能带回几百条数据每条Observation都包含完整的时间戳、编码数组和参考范围结构。如果不做任何处理一次性把 500 条Observation同时fromJson在鸿蒙中低端机上会出现可感知的卡顿耗时 300ms 左右加上后续渲染可能突破 600ms。针对这种情况我从项目中期开始推行三条性能纪律服务端分页优先严格遵守 FHIR 的_count和_page语义每次请求只拉 50~100 条用Bundle.link中的next关系逐页拉取。解析异步化遇到必须全量解析的批量导入场景使用Isolate.run把 JSON 解析放到独立 isolate不阻塞主 UI 线程。复用已解析对象本地建立基于Resource.id的内存缓存重复展示同一份数据时不二次解析。运行效率上我还对fhir_r4的toJson做过针对性优化——批量导出数据时手动复用JsonEncoder实例而不是每次新建jsonEncode的顶层调用。JsonEncoder的复用能减少大量对象分配这在反复构建 Bundle 时收益非常明显。5.3 状态管理与数据层隔离的搭配实践鸿蒙端的 Flutter 项目中我采用Bloc 状态管理 Repository 数据层隔离的组合。fhir_r4资源对象是不可变风格设计所有字段通过 final 修饰这正好和 Bloc 的单向数据流模型匹配每次状态变化都携带新的不可变 Resource 对象避免多个页面同时改动数据导致的状态错乱。数据层隔离的意义在于业务页面完全不知道数据来自 FHIR 服务器还是本地缓存它看到的只是 Repository 吐出的Patient、Observation等标准对象。这个抽象在鸿蒙全场景下意义更大——同一个 Repository 可以被手机端、平板端、手表端的 UI 复用真正做到一套业务代码多端一致体验。5.4 离线优先与增量同步机制医疗应用有一类硬需求离线时也要能查历史记录而且手表的本地采集在无网络时必须不断写入。为此我把数据策略设计成 offline-first数据首先写入本地存储我用的是 Drift 数据库基于 Dart 实现跨端兼容性好网络恢复后通过 FHIR 的BundleType.batch把所有本地变更一次性提交到服务器服务器返回OperationOutcome后按 result 逐条标记上传状态客户端再从服务器拉取增量数据利用_lastUpdated比较时间戳把远端更新的资源合并到本地。这套机制在鸿蒙上有一个小优势鸿蒙的多设备协同能力让我们可以把手机端作为本地数据仓库手表端的采集数据通过鸿蒙自有的分布式软总线直接写入手机端数据库。这样离线同步链路的复杂度被系统能力大大抵减fhir_r4就只需要负责标准数据格式的转换而不必操心异构设备间的传输协议。6. 实测踩坑记录版本、网络、渲染与包体细节6.1 Flutter SDK 版本支持警告的排查思路首次在鸿蒙设备上启动 Flutter 应用时大概率会看到类似的提示The current configured Flutter SDK is not known to be fully supported.这并不代表完全不能运行而是说明当前 ohos 分支与你项目依赖的某些原生模块存在兼容性风险。正确的排查链路是确认fhir_r4等纯 Dart 依赖的版本没有超出当前 Dart SDK 的 language version检查pubspec.yaml中是否存在flutter_test等开发依赖使用了较新 API在DevEco Studio中关闭自动 Gradle 配置改为手动指定 Flutter 模块的 SDK 路径如果仍然报错优先升级 ohos 分支到最新 commit而不是降级 Flutter 主版本。我处理这个问题时花费了不少精力最后发现根因是本地 Flutter 环境变量和 DevEco Studio 内嵌的 Flutter 插件版本不一致导致 IDE 层面的 SDK 检测误报。把两个路径统一后警告消失。6.2 网络请求中的 SocketException 与证书问题fhir_r4本身不负责网络传输所以实际项目中我会用http包或dio包来请求 FHIR 服务器。在鸿蒙上第一个暴露的问题就是SocketException。鸿蒙的网络栈在默认情况下会对自签名证书和 HTTPS 证书链的校验比较严格。如果你联调的目标服务器是测试环境比如本地起的 HAPI FHIR Server证书自签Dart 侧的HttpClient默认会直接拒绝连接。处理方案有两个测试联调临时允许 BadCertificateCallback只应用在 debug 模式下生产环境确保正式服务器使用受信任 CA 签发的证书不做任何跳过校验的妥协。另外鸿蒙应用需要在module.json5中显式声明ohos.permission.INTERNET权限否则网络请求也会以异常形式失败。这点在 Android 上因为默认有 INTERNET 权限而容易忽略。6.3 Flutter 调用原生组件鸿蒙侧的桥接写法差异如果业务中需要调用扫码、NFC、蓝牙等原生能力就要用 MethodChannel 打通 ArkTS。与 Android 不同鸿蒙在 Channel 的注册与调用时机上有一点非常需要注意必须在PageAbility的onWindowStageCreate生命周期之后注册 Channel否则原生侧会收不到 MethodCall。示例代码结构// 鸿蒙 ArkTS 侧注册 Flutter 原生通道 import { MethodChannel } from ohos/flutter_ohos; const channel new MethodChannel(com.example.health/native_bridge); channel.setMethodCallHandler((call, result) { if (call.method getDeviceInfo) { result.success({ model: HarmonyOS Device }); } else { result.notImplemented(); } });在 Dart 侧调用和普通 Flutter 没区别但返回值尽量只传MapString, dynamic可序列化的基础类型避免传类实例或自定义对象。6.4 包体大小与构建产物优化把fhir_r4引入鸿蒙工程后App 体积会有明显增长原因是 FHIR 资源类型定义非常庞大。fhir_r4依赖的intl和自身源码在 debug 模式下会显著膨胀而鸿蒙应用又很在意安装包的头部体积。我做了三个优化措施开启 Flutter 的tree shaking移除未使用资源类的代码路径在发布构建时开启--split-debug-info并把--obfuscate一起打开减少符号表体积对 ArkTS 侧使用按需加载把 FHIR 相关的原生模块延迟到首次网络同步时才动态加载。实测下来这些优化少说能让安装包减少 15%~20%对需要预装到手表等小存储设备上的场景有实际价值。最后再分享一个经验在鸿蒙上用 Flutter 跑fhir_r4最大的幸福感来自于标准化的确定感。你不用再为每个新数据源重新设计一套万能实体类也不用反复跟后台同学对字段名。鸿蒙的全场景设备和 FHIR 的标准语义是少有的特别匹配的组合。如果后续你也打算在这一块做深度应用建议先把官方那张资源关系图啃下来再动手写代码。接下来无论是做远程问诊、慢病管理还是居家康复这条路都会走得更稳。