Flutter适配鸿蒙全指南：运行原理、踩坑实战与选型策略

大概从2023年底开始，技术群里讨论“Flutter能不能跑鸿蒙”的频率肉眼可见地涨了起来。起因很简单：身边不少团队开始收到“App要支持鸿蒙系统”的产品需求，老板的第一反应永远是“我们用Flutter，是不是直接就支持了？”答案没想象中简单，但也没有想象中难。截至目前，Flutter跑在HarmonyOS上已经不是概念验证阶段——社区分支持续推进，官方仓库也给了名分，已经有相当多的商业App把Flutter页面搬进了鸿蒙应用。这篇文章把我从环境搭建、原理理解、选型判断到实际业务踩坑的全程整理了一遍，重点讲三件事：Flutter在鸿蒙上的运行原理、真实开发中的坑与绕法、Flutter和ArkTS到底怎么选。无论你是被迫接触鸿蒙的Flutter开发者，还是正在评估跨端技术栈的技术负责人，这篇都值得认真看完。

1. 鸿蒙为什么盯上了Flutter，Flutter又为什么愿意来

1.1 一个生态新玩家的应用焦虑

鸿蒙的扩张路径跟传统移动操作系统不太一样。它从手机出发，一路铺到平板、车机、手表、电视，后面还有明确的PC版规划。设备品类多了以后，系统本身的底座能力反而不是最焦虑的，最焦虑的是“应用从哪里来”。设备厂商可以帮头部App做适配，但长尾应用、中小企业的App、企业内部工具，总不能全部靠官方团队手写。这时候跨端框架的价值就体现出来了：如果一套Flutter代码能直接跑在鸿蒙上，等于一下子借用了整个Flutter开发者生态的存量。

你可能觉得“借生态”这个说法有点功利，但商业世界就是这么算账。Flutter开发者数量在跨端领域一直是头部梯队，这帮人熟悉Dart、熟悉Widget树、熟悉状态管理，他们不需要重新学一门全新的语言和UI框架就能上手鸿蒙。对平台来说，降低开发者的迁移成本，就是降低生态填充的成本；对开发者来说，一套代码多端复用本来就是这个框架的核心卖点，现在多一个鸿蒙终端，边际成本并没有想象中那么高——前提是适配链路真的通。

1.2 从社区分支到官方仓库：适配的由来

很多刚接触这件事的人会以为Flutter官方早就支持鸿蒙了，其实不是。HarmonyOS的适配最早是由OpenHarmony开源社区驱动的，openharmony-sig下维护着一个flutter_flutter的分支仓库，持续跟Flutter upstream同步代码，同时把引擎的鸿蒙embedder、Dart运行时在鸿蒙设备上的构建产物一步步补全。后来华为自己也组织了专门的flutter_flutter仓库，在API版本对齐、工具链完善上投入明显加大。

这里要区分清楚两个概念：OpenHarmony是鸿蒙的开源底座，HarmonyOS是华为面向消费者设备的商用发行版，两者在开发API上大体同源，但设备和SDK版本不完全等价。Flutter适配盯的是OpenHarmony的API能力，实际调试跑的是HarmonyOS真机。这个差异会在你配置SDK版本时给你上第一课——Flutter SDK分支、DevEco Studio版本、HarmonyOS API Level三者必须对齐。

到2024年前后，Flutter主仓库的README里出现了HarmonyOS相关标识，社区分支开始有人维护“非官方但实锤”的发布包。这个“名分”很关键：它决定了CI流水线会不会持续构建ohos产物，决定了flutter pub publish的插件作者会不会顺手支持鸿蒙，也决定了你遇到问题能不能在GitHub Issues里搜到答案。整体进度不算快，但方向是明确在往前走的。

1.3 为什么是Flutter而不是其他跨端方案

跨端框架不止Flutter一个，React Native、uni-app、Kotlin Multiplatform都在这个赛道。鸿蒙适配偏偏选了Flutter，背后其实是技术路线的差异。

React Native的核心思路是“用JS/TS写业务，通过桥接层映射到系统原生组件”。到了鸿蒙上，这套方案意味着要把整套原生组件映射表重写一遍，Android的View、iOS的UIKit对应鸿蒙的什么组件？桥接层的通信协议要不要为鸿蒙单开一套？工作量非常大，而且RN的性能瓶颈始终在桥接层上。

Flutter则完全不同：它是自绘渲染。UI不是靠系统控件拼出来的，而是Dart代码描述UI树，Flutter Engine用Skia或Impeller直接把画面画到屏幕上。换句话说，Flutter自带一套“UI操作系统”，不依赖宿主系统提供控件。移植到鸿蒙时，最核心的工作是把引擎嵌入到鸿蒙的窗口系统里，也就是重写embedder层，Dart层的业务代码几乎原封不动。这套架构天然更适合接入一个新的系统。

这也解释了为什么社区优先推Flutter而不是其他方案：不是谁更流行的问题，而是谁更好移植的问题。自绘引擎只要搞定窗口、输入、纹理、事件这几个门，剩下的路就顺了。

2. Flutter在鸿蒙系统上跑起来的底层逻辑

2.1 一套自带UI操作系统的三段结构

要理解Flutter在鸿蒙上是怎么跑的，先要理解Flutter本身的分层。它大致分成三层：

• Dart Framework（框架层）：你写的业务逻辑、Widget树、状态管理、路由，全部是Dart代码，跟平台无关。
• Flutter Engine（引擎层）：负责Dart运行时（VM或AOT）、UI渲染、文本排版、事件处理、GPU指令生成。这一层跟平台有一定关系，但大部分是跨平台的C++代码。
• Platform Embedder（嵌入层）：真正的平台相关代码。它负责把Flutter引擎塞进宿主应用里，创建窗口、接收系统触摸事件、接入输入法、注册纹理、控制生命周期。Android有Android Embedder，iOS有iOS Embedder，鸿蒙自然需要一套OHOS Embedder。

打个比方：Flutter像一台自带屏幕和操作系统的掌上游戏机，到了鸿蒙这边，它不需要鸿蒙给它造屏幕、造按键——只需要一个电源适配器，也就是embedder，把鸿蒙的电力接口翻译成Flutter能用的输入输出通道。这个比喻能帮你理解后面的所有坑：业务代码的兼容性很好，但适配的难点几乎都集中在“电源适配器”这一层。

2.2 鸿蒙适配到底改了什么

把Flutter移植到鸿蒙，核心工作不是把Dart代码编译成鸿蒙包，而是把Engine和Embedder层重新接一遍。具体来说：

• 窗口与渲染接入：需要把Flutter的渲染输出接入鸿蒙的图形栈，让Skia绘制的画面能显示到鸿蒙窗口上。涉及Surface的创建、EGL/GLES上下文的管理、VSync信号的同步。
• 输入与事件分发：鸿蒙的触摸事件、鼠标事件、键盘事件要通过embedder转成Flutter内部的PointerEvent，否则页面上的点击和滚动手势全部失灵。
• 输入法与文本：中文输入、软键盘弹出、候选词窗口，这些能力在鸿蒙上有一套独立的InputMethod框架，需要单独对接。这也是很多开发者上真机后发现“输入框弹不出来”或“键盘把界面顶飞”的直接原因。
• Platform Channel：Flutter侧通过MethodChannel、EventChannel跟原生侧通信，鸿蒙上的原生侧就是ArkTS插件。官方适配层提供了一套跟Android Plugin类似的注册机制，你在Flutter里写的MethodChannel代码可以原样保留，只是原生实现从Java/Kotlin换成了ArkTS。

你不需要把上面每一项都读透才能上手开发，但了解这个边界很重要：以后遇到“页面能显示但点不动”“键盘弹不出来”“原生能力调不通”这类问题时，你能迅速定位到是哪一层出了问题，而不是在业务Dart代码里瞎找。

2.3 Impeller渲染器为什么在鸿蒙上还没普及

Impeller是Flutter新一代渲染引擎，目标是替换掉积累了多年技术债的Skia，解决iOS上最让人头疼的“首帧卡顿”和“着色器编译后掉帧”问题。Flutter官方在iOS上已经默认开启Impeller，Android也在逐步推进。

但鸿蒙适配分支目前主要还是跑Skia后端。Impeller的鸿蒙接入涉及GPU后端（Metal、Vulkan、OpenGL ES在鸿蒙图形栈上的对应关系）的完整重写，这个工程量比embedder还大。所以在鸿蒙设备上，你会遇到一些在iOS上已经消失的渲染小毛病——比如复杂模糊效果掉帧、某些Shader首次触发时的卡顿。这不是鸿蒙适配团队偷懒，而是Impeller迁移本身就有优先级排序。

给个实用建议：如果你的鸿蒙Flutter页面里有大量BackdropFilter、高阶Shader动画，先在真机上压测一遍再上线。Skia在鸿蒙上整体是稳的，但这种重渲染场景确实更容易暴露性能差异。

3. 从零搭建Flutter鸿蒙开发环境：版本坑、模拟器坑、真机坑

3.1 环境清单与版本对应关系

搭建开发环境是劝退最多人的第一关。一个干净的Flutter鸿蒙开发环境至少需要这些东西：

最大的坑是版本对应关系。Flutter的ohos分支会标明它适配的HarmonyOS API Level和DevEco版本，如果你用最新的DevEco配一个三年前的Flutter分支，大概率编译不过；反过来，老DevEco配新Flutter分支也可能遇到API不兼容。我的建议是：不要追求“全部最新”，直接看Flutter ohos仓库README里写的“已测试版本组合”，照抄一份，跑通以后再逐步升级。

3.2 “flutter新建项目后跑不起来”到底卡在哪

这个卡点几乎每个刚接触Flutter鸿蒙开发的人都会遇到，热搜词里常年挂着“flutter新建项目后 跑不起来”。我复盘了一下，根源基本就集中在四类：

• pub get失败：默认源在海外网络环境下非常不稳定。解决办法是配置国内镜像环境变量，PUB_HOSTED_URL和FLUTTER_STORAGE_BASE_URL换成可用的镜像地址，然后重跑flutter pub get。
• Gradle/AGP版本冲突：DevEco创建鸿蒙工程时用的Gradle插件版本比较特殊，如果Flutter ohos模板生成的Android工程依赖的AGP版本跟本机不一致，构建时就会直接报错。日志通常指向“Failed to apply plugin”之类。解决思路是编辑settings.gradle和build.gradle，把插件版本对齐到本地安装版本。
• 签名配置缺失或错误：真机运行需要签名。DevEco里默认有自动签名配置，但Flutter CLI直接拉起构建时未必带上，导致安装到真机时提示签名校验失败。我一般习惯在DevEco里先手动跑一次“Build > Build Hap(s)/APP(s)”，确认签名链路通，再回到命令行用flutter run。
• SDK路径没配对：Flutter工具链需要知道HarmonyOS SDK装在哪里。常见症状是报“Unable to locate HarmonyOS SDK”或“hdc not found”。检查local.properties里的sdk.dir，以及环境变量里是否把HarmonyOS SDK的toolchains目录加进了PATH。

这三个问题解决完，大部分“跑不起来”就消失了。如果还跑不起来，看日志比瞎猜靠谱——后面会讲怎么看日志。

3.3 非华为电脑连接鸿蒙手机：hdc与adb的坑

很多人拿着非华为品牌的电脑去做鸿蒙真机调试，会遇到一层又一个层的门槛。注意，这里用的不是adb，而是hdc（HarmonyOS Device Connector）。

真机调试的完整链路是：手机打开开发者模式 → 开启USB调试（部分版本还有“仅充电模式下允许ADB调试”之类的选项） → 电脑端安装/找到hdc工具 → hdc list targets能发现设备 → 再用flutter run或hdc install把HAP装到手机上。

非华为电脑上最容易出问题的是驱动和端口。Windows系统下，手机连上后如果没有正确安装HarmonyOS设备的USB驱动，hdc list targets永远显示空。处理办法是打开设备管理器，找到带感叹号的未知设备，手动指定HarmonyOS SDK里自带的驱动路径更新。还有一类坑是USB模式问题，有些手机默认“仅充电”，需要手动改成“传输文件”模式，hdc才能识别。

如果你用的是Mac或Linux，整个过程反而简单一些，基本上靠命令行就能搞定：

# 检查设备是否连接成功 hdc list targets # 安装HAP包 hdc install entry-default-signed.hap # 查看设备日志 hdc hilog

3.4 常见运行时异常与日志解读

热搜词里有一条很典型：E/flutter (31173): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception。第一次在鸿蒙设备日志里看到这段，我也慌了一下，以为适配层炸了，后来发现它就是Flutter里最普通的“Dart侧未捕获异常”。

这类日志的含义是：Dart侧抛出了一个没有被try-catch捕获的异常，Flutter引擎在日志里打了个底。真正的错误堆栈会紧跟在这行之后，仔细往下翻能看到具体的Dart文件、行号、异常类型。常见原因包括：空安全问题、JSON解析失败、底层MethodChannel返回null等。

Debug包异常和Release包异常的表现还不太一样。Debug包堆栈清晰，直接指向源码位置；Release包经过AOT编译和混淆，日志里往往只有一段难读的地址偏移。遇到后者，建议先用Debug包复现一次定位到具体代码，再决定要不要修。千万别在鸿蒙真机上用Release包做日常调试，那是给自己找罪受。

4. Flutter和ArkTS的选型博弈：没有标准答案的架构题

4.1 两个概念的错位对比

网上常有人问“ArkTS和Flutter谁更流行”，这个问题本身就有点错位。ArkTS是鸿蒙生态的原生开发语言，对应的是Android里的Kotlin、iOS里的Swift；Flutter是跨端UI框架，对应的是React Native、uni-app。一个比的是“在鸿蒙上开发用什么语言”，一个比的是“用哪套框架写跨端UI”，根本不在同一个维度上。

但我也理解为什么大家都拿它俩比——对一个具体项目来说，你确实要在“用ArkTS写鸿蒙原生”和“用Flutter写一套跨端”之间做取舍。真正的关键不是谁更流行，而是你的项目约束是什么。如果团队已经有成熟的Flutter代码库，那么走Flutter鸿蒙路线几乎是必然选择；如果团队从零开始且鸿蒙是唯一目标平台，ArkTS的原生能力和系统集成深度确实有优势。

4.2 新项目选型决策表

我给自己列过一张决策表，每次评估新项目都拿它过一遍，现在分享出来：

这张表没有对错，只有适不适合。我有朋友在工具类App团队，选了ArkTS，看中的是华为应用市场上“鸿蒙原生”标签带来的曝光和用户好感度；也有做企业办公软件的团队，选了Flutter，理由是同一套代码直接覆盖手机、平板和后续的鸿蒙PC，省掉整个桌面端的开发预算。

4.3 务实折中：Flutter界面 + ArkTS服务层

实际开发中，比“二选一”更常见的其实是“混着用”。Flutter负责UI和交互，ArkTS负责系统能力和原生服务，中间用Platform Channel通信。这条路能走通，恰恰是因为Flutter在鸿蒙上的embedder已经提供了通道能力。

举个例子：你的App需要读取鸿蒙设备上的联系人权限、调用系统的分享面板、或者跟智能家居设备做一次能力协商，这些深度系统能力用Flutter侧Dart代码做不了，需要写一个ArkTS插件封装。Flutter页面在需要的时候通过MethodChannel调用，传参和返回值走标准的数据序列化。

反过来，ArkTS侧也可以主动往Flutter页面推送数据，走的是EventChannel。社区里已经有flutter_ohos_plugin这类桥接模板，打包的时候用flutter_aar把Flutter产物打成AAR，嵌进DevEco创建的ArkTS宿主工程里。这样两个技术栈各干各擅长的活，互不干扰。你会发现组合起来以后，很多所谓的“Flutter鸿蒙做不了的事”其实都能做，只是需要一点架构上的变通。

4.4 状态管理与组件通信照搬不误

很多Flutter开发者开始鸿蒙开发前的技术焦虑是：Dart代码跑到鸿蒙上，状态管理还能用吗？组件通信会不会变？答案是：完全不用改，因为那套东西在Dart层，跟平台无关。

热搜词里的“flutter provider 怎么用”、“flutter组件通信”，在鸿蒙Flutter工程里的答案跟Android、iOS上一模一样。Provider依然靠ChangeNotifier + Consumer来驱动UI更新：

class CounterProvider extends ChangeNotifier { int _count = 0; int get count => _count; void increment() { _count++; notifyListeners(); } }

组件通信也依然是那老几样：父传子用构造参数，子传父用回调函数，跨页面用Provider/Riverpod/Bloc或者EventBus。你现有的Flutter知识在这条路上几乎百分之百平移，真正要学的新东西是鸿蒙侧的系统能力对接，而不是重新学一遍UI开发。这是Flutter鸿蒙开发跟纯ArkTS开发相比最大的舒适区。

5. 真实业务开发里那些绕不开的坎：插件、渲染与系统能力

5.1 插件生态：家底只有一半

跨端开发最忌讳自己造轮子，Flutter的优势本来是pub.dev上那几万个现成插件。但到了鸿蒙上，这个家底要打个对折。

pub.dev上的插件大致分三类：纯Dart实现、依赖Android/iOS原生API、两者混合。纯Dart的插件（比如dio、intl、decimal）在鸿蒙上直接可用，一点问题没有；依赖原生API的插件就要看有没有人做了鸿蒙移植。目前社区已经移植了一批基础设施插件，像shared_preferences、path_provider、permission_handler，主流状态管理和网络库也都能用。但再往上走，比如地图SDK、支付SDK、推送SDK、深度绑定Google服务的插件，在鸿蒙上基本无解——这些不是做一层适配那么容易的，还牵扯到服务方是否愿意提供鸿蒙SDK。

判断一个插件能不能用，别只看pub.dev上的标记，直接看它源码pubspec.yaml里有没有声明ohos的plugin实现，或者到鸿蒙Flutter社区仓库里搜一下是否有人提交过适配PR。我踩过的教训是：选型时先做“插件可用性清单”，把业务里所有依赖第三方插件的点列出来，逐个确认鸿蒙可用性。这一步做得越早，后面返工越少。

5.2 输入法、文本渲染与键盘弹起

输入法适配是鸿蒙Flutter开发里特别容易暴露问题的一环。Flutter自带的文本引擎能处理好页面的文字渲染，但软键盘的弹出行为、候选词窗口的位置、以及键盘弹出后的页面避让，需要embedder跟鸿蒙的输入法框架配合好。

实践中最常见的两个问题：一是点击输入框后键盘弹不起来，或者弹起来以后把Flutter页面盖住了没有触发避让。前者多半是输入法事件通道没打通，后者需要在鸿蒙工程里配置软键盘的模式和Resize行为。第二个是复杂文本的渲染——混排了特殊符号、emoji、上下标、多语言文本的页面，最好在真机上逐项过一遍，不同设备的中文字体渲染还是有细微差异。

另外给个建议：Flutter页面的滚动容器如果跟键盘避让逻辑叠加，很容易出现“弹键盘后页面乱跳”的情况。解决方案是统一用Flutter的MediaQuery.of(context).viewInsets判断键盘高度，自己控制底部内容的偏移，而不是依赖鸿蒙系统默认的Resize行为。

5.3 HAP打包与动态化能力重新设计

开发完以后，打包和分发又是一个需要重新理解的环节。鸿蒙的应用包格式叫HAP，类似Android的APK，但它还有一套HAR（鸿蒙静态共享包）的机制。Flutter工程通过flutter_aar等方案打进ArkTS宿主工程后，最终一起打成一个HAP发布。

这里有个业务层面的坑：Android生态里很多团队依赖热更新和动态化，通过插件化框架绕过应用市场更新。鸿蒙上的动态能力分发机制跟Android完全不同，而且受制于系统版本和分发渠道，你熟悉的“下发一段代码到客户端即时生效”的方案基本行不通。这意味着如果你原本的设计里包含大量动态化逻辑，上鸿蒙前必须重新设计。我一般建议把会频繁变动的业务规则放在服务端配置中心，用Push或轮询的方式同步，尽量避免在鸿蒙端做代码级动态下发。

这个限制反过来也印证了“Flutter + ArkTS服务层”混合架构的价值：系统能力、动态化策略、需要跟系统深度绑定的逻辑放到ArkTS层，后续调整系统交互时不用重新走一遍Flutter发版流程。

5.4 调试与性能分析工具的原始感

做鸿蒙Flutter开发，要提前降低对工具链的预期。Flutter DevTools在常规平台上很成熟，memory、inspect、timeline一应俱全；到鸿蒙上，由于调试通道还在完善，有些功能能用，有些功能会时灵时不灵，热搜词里的“flutter逆向工具箱”其实反映了开发者对性能剖析工具的需求缺口。

我的做法是“系统工具兜底”：Flutter侧的日志照常用，性能数据多依赖鸿蒙自带的hdc hilog抓日志，结合DevEco的设备监控能力看CPU和内存曲线。如果需要精确地量帧率，可以在Flutter工程里开启PerformanceOverlay，让Flutter自己绘制帧渲染数据，这个不依赖宿主平台，在鸿蒙上一样好使。整体调试效率肯定不如Android/iOS那么顺手，但熟悉了以后，对定位一般性问题足够。

6. 如果决定入局，给你几条实在建议

6.1 上手路线：先补鸿蒙基础再动Flutter

很多Flutter开发者上手鸿蒙的第一反应是直接拉分支建工程，结果被DevEco工程结构、权限声明、HAP打包这些概念搞得一头雾水。我自己反而觉得应该反过来：先用一周左右时间把鸿蒙应用开发的基础概念过一遍，再回来写Flutter。

最好从HarmonyOS应用开发基础认证的知识点看起，重点看三块：ArkTS的语法和UI描述方式、应用生命周期与Ability（Stage模型）、权限申请和系统服务调用。不需要成为ArkTS专家，但一定要理解“Ability、Page、Window、HAP”这些鸿蒙特有的概念，否则后面你在DevEco里改配置、调签名、看日志时会完全不知道在操作什么。

有了鸿蒙底子以后，再动手搭Flutter ohos环境，你会明显感觉到两边是互相对照的：ArkTS的Row/Column布局对应Flutter的Row/Column，ArkTS的@State对应Flutter的StatefulWidget，理解了对应关系以后，看适配代码、调桥接问题都会快很多。

6.2 用最小工程验证技术路线

别一上来就想把完整业务App迁移过去，哪怕产品经理嗷嗷催也说清楚：先用最小可行工程验证技术路线，把风险排掉再投入铺量。

这个最小工程应该包含三件事：一个能跑的Flutter页面、一次完整的Flutter到ArkTS的MethodChannel调用、一次打包签名安装到真机的完整链路。你甚至不妨让页面专门画几个复杂UI做压测，比如列表合并、模糊背景、图表动画。然后把这份页面装进ArkTS宿主工程，跑在真机上观察性能、内存和包体大小。

这一步的价值是花最小的成本回答最关键的几个问题：Flutter在鸿蒙上渲染性能够不够？发布链路通不通？插件缺口能不能补？如果你的核心业务页面在最小工程里能稳住，再谈规模化适配；稳不住，那也可能是选型问题，趁早换ArkTS原生反而救了团队一个季度。

6.3 值得押注的方向：多端复用与鸿蒙PC版

热搜词里“开源鸿蒙PC版”、“鸿蒙模拟器电脑版”这类词的持续热度，说明桌面端是鸿蒙确定性的方向。手机、平板、车机、PC的多端布局一旦铺开，对开发者的核心吸引力就是“一套代码多端跑”。而Flutter的桌面端支持已经打磨了很多年，Windows/macOS/Linux都能跑得很稳。

也就是说，未来很可能出现一个局面：你用Flutter写的业务页面，同一套代码既跑在鸿蒙手机上，也能跑在鸿蒙PC上，UI自适应逻辑复用跨平台的经验就行。这个想象空间，比单纯“给鸿蒙做适配”要大得多。真有团队是冲这个去的，一边搭了鸿蒙Flutter流水线，一边把桌面端的窗口管理、快捷键、响应式布局都在计划里，提前把多端复用的架构预留出来。

6.4 心态与路线图

最后这点算是交心话。做Flutter鸿蒙开发，心态比技术更考验人。工具的成熟度摆在那里，你会反复遇到“文档是旧的”、“分支版本对不上”、“插件没人适配”这类问题，很容易产生“这玩意到底能不能用”的怀疑。我的经验是：把它当成一个长期跟进的项目，而不是一次两次就能通关的短期任务。

技术动作上保持固定节奏：每周看一眼flutter_flutter的ohos分支更新日志，关注上游是否合并了什么新提交；遇到问题先查Issues，不要自己闭门造车；在社区里能查到适配进度的问题不要重复提问。业务动作上小步快走：一个页面一个页面验证，一个系统能力一个系统能力打通，别追求一步到位。我入局这一年多最大的体会是：这个方向坑是真实的，机会也是真实的，区别只在于你愿不愿意先把脏活累活干完。

最后分享一个小技巧：在DevEco和Flutter CLI之间来回切换时，容易端口冲突导致“设备已被占用”的错误，关掉DevEco的模拟器再重新插拔手机通常能解；实在不行，在命令行里把hdc server kill掉再重启一次。这个操作救过我很多次。