Mac M3上搭建Flutter+OpenHarmony开发环境实操指南

前阵子团队接到一个意料之外的活儿：现有APP是Flutter写的，跑得好好的，但客户提了个新要求——要在一批搭载开源鸿蒙（OpenHarmony）系统的设备上跑起来。仔细看了一下需求，这批设备是各类行业终端，Android和iOS都覆盖不到，只能走OpenHarmony这条路。这就尴尬了：Flutter官方SDK默认支持的是Android、iOS、Web和桌面端，压根没有针对开源鸿蒙的正式产物。好在社区的脚步一直没停，Flutter的OpenHarmony适配分支（圈里一般就叫Flutter-OH）把这条路打通了，Dart代码可以借助OpenHarmony的ArkUI壳工程跑起来。

这篇东西就是我在这台M3芯片的Mac上，从零搭完整个Flutter-OH环境的完整记录。包括为什么要这样折腾、每一步用到的工具和参数、以及我在实操中踩进去又爬出来的坑。写这篇的初衷很简单：网上关于OpenHarmony开发环境的教程不少，但大多基于Windows或者Intel芯片的Mac，换成M3之后，架构、SDK选型、编译链都会冒出一堆新问题。如果你手里正好也是一台M系列芯片的Mac，想尽快把Flutter工程跑到OpenHarmony模拟器或真机上，这篇文章应该能让你少走很多弯路。

1. 为什么要在Mac M3上跑Flutter+开源鸿蒙：从跨平台开发的实际场景说起

1.1 Flutter的跨平台边界，恰恰卡在OpenHarmony这一端

先理清一个很多人没想明白的底层逻辑：Flutter所谓的跨平台，靠的不是把Dart代码翻译成各平台的语言，而是把Dart代码编译成机器码，再用一套自绘渲染引擎（Skia或Impeller）把UI画出来。这套自绘引擎不依赖系统自带的控件，所以理论上只要能在目标系统上启动一个"引擎嵌入层"（embedder），Flutter就能跑。

Android有官方写好的embedder，iOS也有，Windows、macOS、Linux、Web同样都有。但OpenHarmony不在官方默认列表里，因为Flutter官方维护的重点就那几个平台，开源鸿蒙没有进入官方主线的产品节奏。替代方案就是社区维护的Flutter-OH适配分支，它做的事情本质上就是在OpenHarmony的ArkUI框架里补上这个embedder：一行Flutter代码经过编译后，会启动一个OpenHarmony的Ability（类似Android的Activity），Ability里嵌入了FlutterView，Dart侧的Widget树最终通过OpenHarmony的图形栈显示出来。

用个不严谨但好懂的类比：Flutter就像一个自带舞台道具的剧团，Dart剧本写好了，只需要在每个剧场里找到能搭舞台的场地。Android、iOS是官方已经谈好的剧场，OpenHarmony则是社区自己动手租了个场地，把台子搭起来了。你要做的，就是把剧团（Flutter引擎适配产物）送进这个场地，并保证它能稳定演出。

所以这个方案的价值很明确：如果你团队里已经有一支Flutter团队，产品逻辑、状态管理、网络层、数据层都是Dart写的，那么迁移到OpenHarmony时，上层的业务代码几乎不用动，真正要处理的就是端侧能力调用（蓝牙、串口、摄像头、扫码等）的通道桥接，以及把OpenHarmony壳工程打包出来的那一套流程。

1.2 为什么选M3当演示平台

M3芯片的Mac在搭建OpenHarmony开发环境时，有个先天优势：M系列芯片是ARM架构，和手机端SoC的指令集同源。OpenHarmony SDK里带的那一组native工具链，编译出来的目标产物大多是ARM指令集。x86_64架构的Mac虽然在模拟器环节也能跑，但构建出来的某些中间产物、LLVM工具链的行为会和真机上的表现有细微差别，遇到链接错误时排查起来更费劲。

M3的另一个实际优势是功耗和散热的控制。第一次编译Flutter引擎和OpenHarmony侧native代码时，CPU会满载很长一段时间，Intel老款Mac在这个环节经常风扇狂转、整机卡顿。M3这边虽然也会升温，但整体体验要平稳得多。而且从团队现实角度讲，这两年新配发的开发机几乎都是M系列芯片，如果教程还是按Intel工具链的路径写，很多人照着做会遇到莫名奇妙的小毛病，最后很难判断是自己操作问题还是架构问题，干脆就用M3做演示基线，把架构相关的坑提前拆开讲清楚。

1.3 这篇文章覆盖的范围

我给自己定的目标很具体，不涉及任何项目业务代码，只解决"环境能不能跑起来"：

• 在M3 Mac上装齐OpenHarmony SDK、Flutter-OH适配分支、Java、hvigor构建工具、ohpm包管理器；
• 手工构造一个最小的OpenHarmony工程，能单独编译出HAP安装包；
• 把Flutter工程与ohos平台目录关联起来，让Dart代码真正编译进OpenHarmony模拟器/真机；
• 解决我在这个过程中真实遇到的三类坑：架构错位、构建脚本对Mac系统的特殊要求、版本不一致导致的连锁报错。

动手之前先打个预防针：这个环境不像Android那样装个SDK就能立刻编译，OpenHarmony的构建链里既有GN+Ninja的native构建，又有nodejs驱动的hvigor构建，还有类型标注和资源编译的环节，第一遍跑通大概需要半天时间，主要时间都花在下载SDK和首次编译上。以下每一步我都按实际情况记录，连踩坑的排查思路也一起写了。

2. 环境准备：Mac M3需要补齐的工具链清单

2.1 第一步：确认你的终端是原生ARM环境

别笑，这一步真不是废话。我见过不少同事明明用着M3，却因为在某些旧项目里装过Rosetta转译的Homebrew，导致终端里运行的所有命令都被x86_64解释执行。这些命令装出来的Java、Node、Python，清一色是x86_64版本。OpenHarmony SDK自带的工具链大多是arm64构建的，两边混在一起，编译时就会出现各种诡异的"看不懂"报错。

先运行下面两个命令自查：

arch # 结果是 "arm64" 说明当前终端是原生ARM模式 uname -m # 同理，"arm64" 或 "aarch64" 均正常

如果arch返回的是i386或x86_64，说明你的终端走了Rosetta转译模式。解决办法：在"访达 -> 应用程序 -> 终端"里右键，勾选"使用Rosetta打开"的选项去掉，然后重新启动终端。这一步不处理好，后面装的所有东西都可能白装，相当于地基就歪了。

另外一个常用判断技巧：在命令行执行node -p "process.arch"，输出arm64才是正常。Java的话用java -version看，如果返回类似Java HotSpot(TM) 64-Bit Server VM这种没标注架构的，再用file $(which java)看路径下的二进制类型。

2.2 基础依赖：Homebrew、编译工具与系统组件

在M3上，我还是一贯推荐用Homebrew管理基础依赖。安装命令是标准的：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

如果你的网络拉取GitHub比较慢，Homebrew同样支持配置镜像源，把HOMEBREAK_BOTTLE_DOMAIN之类的环境变量指向国内镜像即可，这块建议按你所在网络环境的实际情况处理，避免反复超时。

装好之后，一次性把后面要用的工具装齐：

brew install git ninja ccache node python3 openjdk@17

逐一说下这些工具在这个场景里是干什么用的：

注意openjdk@17装完之后，Homebrew默认不会帮你设置JAVA_HOME，需要在~/.zshrc里手动配置。具体方法我放到JDK小节里一起讲。

另外特别提醒一点：Flutter调试时经常要用到iOS模拟器，所以Xcode Command Line Tools也建议提前装好。哪怕你完全不开发iOS，OpenHarmony的native编译链在某些场景下也会借用macOS自带的clang/ld等底层工具，缺了命令行工具，链接阶段会报ld: library not found for -l...这类错误。

xcode-select --install

2.3 安装适配OpenHarmony的Flutter SDK分支

这里需要明确一个容易混淆的概念：官方Flutter SDK和Flutter-OH适配分支不是同一个仓库。官方仓库的管理命令、接入标准平台没问题，但它不识别ohos这个设备类型；适配分支则是在Flutter引擎层加入了OpenHarmony的embedder支持，同时补上了flutter create --platforms=ohos这类平台模板。

实际的安装流程是：用git clone社区维护的适配仓库，切换到对应的适配分支（分支名要看社区仓库的说明，一般会明确标注OpenHarmony版本对应关系），然后把它当成普通Flutter SDK使用。

mkdir -p ~/development cd ~/development git clone -b master <社区维护的适配仓库地址> flutter-ohos

这里不写死具体仓库地址，是因为不同时期的适配分支会跟随OpenHarmony版本演进，建议以社区文档里的最新地址为准。拉下来之后，把SDK的bin目录加入PATH，并把PUB_HOSTED_URL和FLUTTER_STORAGE_BASE_URL配置成可用的镜像地址，否则后面创建工程时拉取依赖也会很痛苦。

验证是否生效：

~/development/flutter-ohos/bin/flutter --version

如果输出里能看到基于OpenHarmony相关的版本描述，说明适配分支装对了。再看一下它能识别的设备平台：

flutter config --list

正常配置下会出现enable-ohos一类的选项，把它打开：

flutter config --enable-ohos

这一步不做，后面flutter create --platforms=ohos会直接告诉你平台不可识别。

2.4 JDK版本与JAVA_HOME的坑

OpenHarmony的构建链比较依赖Java生态，hvigor工具本质上就是一个基于Gradle思路的构建框架，没有JDK寸步难行。我建议直接装OpenJDK 17，别用老掉牙的8，也不要上21，17是目前OpenHarmony工具链验证最充分的版本。

Homebrew装完openjdk@17后，它会提示你路径在/opt/homebrew/opt/openjdk@17。把下面几行写进~/.zshrc：

export JAVA_HOME=/opt/homebrew/opt/openjdk@17 export PATH="$JAVA_HOME/bin:$PATH"

配置完重开终端，java -version应该显示17.0.x。这里还有一个容易踩的坑：如果你没重开终端，或者之前装过其他JDK，java命令指向的可能还是旧版本。可以用/usr/libexec/java_home -V列出系统里所有JDK，确认当前激活的是不是arm64版本。file $(which java)如果出现Mach-O 64-bit executable x86_64字样，说明JDK装成Intel版了，这种在M3上属于最典型的地基错误，后面编译到一半才发现就麻烦了。

3. 从零开始搭建OpenHarmony SDK环境（M3芯片专属路线）

3.1 下载OpenHarmony SDK并理解目录结构

OpenHarmony的SDK不像Android Studio那样有统一的SDK Manager界面，更像是一套解压即用的目录集合。在开源鸿蒙官网的SDK下载页里，选择三件套：标准版SDK、macOS平台、arm64架构。下载下来是一个压缩包，解压到固定路径，我习惯放在~/ohos-sdk。

解压之后，目录结构大致长这样：

你不用死记每个目录，但必须清楚一件事：OpenHarmony的编译链分两层，一层是hvigor负责的应用层资源、ArkTS编译、HAP打包，另一层是native工具链负责的C/C++ so库交叉编译。这两层在环境变量和PATH配置上是分开的。

3.2 环境变量配置：一份可以直接复制的配置

在~/.zshrc里追加以下内容（注意路径换成你实际解压的位置）：

export OHOS_SDK_HOME=$HOME/ohos-sdk export DEVECO_SDK_HOME=$OHOS_SDK_HOME export PATH="$OHOS_SDK_HOME/command-line-tools/bin:$PATH" export PATH="$OHOS_SDK_HOME/toolchains:$PATH"

DEVECO_SDK_HOME是hvigor在构建时读取的SDK根目录，如果不设置，它可能会默认去IDE安装目录找SDK，而你未必装过那个体积庞大的IDE，所以这里显式指定最稳妥。

配置完后，顺手把ohpm包管理器也加进PATH。ohpm在旧版本SDK里放在toolchains/ohpm/bin，新版本可能在command-line-tools/ohpm/bin下。验证：

ohpm --version hdc --version

两个命令都能输出版本号，说明SDK环境基本就位。

3.3 安装hvigor与ohpm，管理构建和依赖

OpenHarmony应用工程的依赖管理逻辑和前端生态很像：用ohpm安装ArkTS组件依赖（类似于npm包或pub包），用hvigor执行构建任务（类似于Gradle任务）。hvigor本身可以通过ohpm安装：

ohpm install -g @ohos/hvigor ohpm install -g @ohos/hvigor-ohos-plugin

安装完之后，hvigorw这个wrapper命令通常就全局可用了。这里有个值得注意的版本约束：hvigor的版本必须和SDK的API版本匹配，否则构建时大概率报api version mismatch之类的错误。最稳妥的做法是先看SDK里面自带的hvigor版本，然后按它指定的版本安装。

Node方面，OpenHarmony工具链对Node版本要求不算苛刻，18以上基本没问题。但如果你机器上之前为了跑前端项目装了Node 16甚至更老的版本，建议升一下，某些构建脚本里的语法在旧Node上会报错，排错成本高。

3.4 手工构造并编译最小OpenHarmony工程

为了验证SDK环境是否完整，先别急着上Flutter，手工构造一个最小的OpenHarmony HAP工程跑通构建。目录结构如下：

sample_hap/ ├── AppScope/ │ ├── app.json5 │ └── resources/ ├── entry/ │ ├── src/main/ │ │ ├── ets/ │ │ │ ├── entryability/ │ │ │ └── pages/ │ │ └── module.json5 │ └── build-profile.json5 ├── build-profile.json5 ├── hvigorfile.ts └── oh-package.json5

核心配置build-profile.json5不要想得太复杂，按最简模板来：

{ "app": { "signingConfigs": [], "compileSdkVersion": 12, "compatibleSdkVersion": 12 }, "modules": [ { "name": "entry", "srcPath": "./entry", "targets": [ { "name": "default", "runtimeOS": "HarmonyOS" } ] } ] }

compileSdkVersion和compatibleSdkVersion写SDK对应的API级别即可，如果具体版本和你装的SDK不一致，改成SDK里实际支持的版本号。

工程文件准备好后，执行依赖安装和构建：

ohpm install hvigorw assembleHap

第一次构建会把hvigor相关的依赖、gradle wrapper等都拉下来，耗时比较久。执行成功后，在entry/build/default/outputs/default目录下会生成.hap文件。看到这个产物，说明OpenHarmony侧的工具链已经全线打通，后面的Flutter集成才有基础。

4. 配置Flutter工程：让Dart代码真正跑进OpenHarmony模拟器

4.1 创建Flutter工程并追加ohos平台

SDK和工具链都验证过之后，接下来把Flutter工程接进来。先创建普通的Flutter工程：

flutter create my_app cd my_app

然后用Flutter-OH适配分支提供的平台命令，为工程追加ohos平台目录：

flutter create --platforms=ohos .

这时候工程根目录下会多出一个ohos文件夹，里面是一整套OpenHarmony壳工程，Shell层已经帮你配好了Flutter引擎的依赖关系。如果这一步提示平台不支持，回到前面检查flutter config --enable-ohos是否生效，或者适配分支是否切换正确。

4.2 读懂ohos子工程的结构和桥接原理

ohos目录本质上就是一个OpenHarmony工程，它包含entry/src/main/ets、oh_modules、build-profile.json5等我们前面手工建过的内容。但它和普通工程有一个关键区别：entry模块里多了一个MainAbility，这个Ability在onWindowStageCreate回调里会加载Flutter引擎的产物，并在首页上挂载FlutterView。

用大白话说，壳工程是一个带孔的App，孔就是FlutterView，孔后面跑着一台完整的Flutter引擎。Dart代码通过引擎解释/编译后，每一帧UI都被Flutter的自绘引擎渲染成纹理，再交给OpenHarmony的图形栈上屏。所以你在Dart里写的Text('Hello')，最终画出来的并不是ArkUI的Text，而是Flutter引擎自己画的位图。这也是为什么Flutter在OpenHarmony上能做到跨端UI一致性——它压根不借用系统控件，只是借了一个能容纳自绘内容的"容器"。

4.3 启动模拟器并把HAP装上

Flutter工程编译输出的最终形态，依然是HAP包。所以脱不开hdc这个命令行工具。hdc是OpenHarmony的通用设备连接工具，常用命令如下：

hdc list targets # 查看已连接的模拟器/真机设备 hdc install my_app.hap # 安装应用 hdc shell aa start -a EntryAbility -b com.example.my_app # 启动应用

如果你用的是OpenHarmony官方模拟器，先在SDK管理界面把模拟器跑起来，然后再执行hdc list targets确认设备出现在列表里。第一次安装HAP如果提示签名校验失败，是因为工程没有配置签名信息，本地调试时把build-profile.json5里的signingConfigs留空，并在项目里关闭签名校验即可，具体开关字段以构建工具报错提示为准，不同SDK版本写法略有差异。

4.4 第一次flutter run：引擎编译是个大工程

跑通的命令行其实很简单：

flutter run -d ohos

但实际执行却是另一个故事。第一次运行时，Flutter-OH适配分支会把你本地的Flutter引擎源码编译成OpenHarmony能加载的产物，这一过程在M3上可能持续20到40分钟，具体取决于机器性能和ccache缓存情况。期间终端会反复滚动C/C++编译日志，这是正常状态，别假死就等着。

如果嫌慢，有个立竿见影的操作：在~/.zshrc里声明export CCACHE_DIR=$HOME/.ccache，并且把ccache的缓存大小调大一点，比如ccache -M 20G。第二次编译、以及后续改了一点C++引擎代码再编译时，能省下大量时间。

第一次跑通之后，你会在ohos目录看到生成的Flutter引擎so库，后续的调试就快多了。

5. 实操踩坑记录：M3上最容易翻车的几个环节

5.1 架构错位：x86_64 JDK带来的连环报错

这个坑我印象最深，因为报错出现的位置完全在预期之外。当时我随手用java -version确认过能找到Java，就没多想，结果hvigor在解析工程配置时直接抛异常，提示某个so库无法加载。排查了很久，最后发现罪魁祸首是Homebrew的Intel兼容版本装出来的JDK8。

排查链路是这样的：

java -version file $(which java)

file输出显示是x86_64，而OpenHarmony工具链要求arm64。为什么会装出x86_64的JDK？因为那台机器之前用/usr/bin/java指定过老版本路径，Homebrew在Rosetta模式下安装的openjdk8被全局PATH优先命中了。解决办法：删掉旧JDK，换成openjdk@17，并且在~/.zshrc里把JAVA_HOME写死。这个坑的教训是：别只看有没有Java，一定要看当前PATH里生效的Java是什么架构，尤其M系列芯片上，file命令是你的排查利器。

5.2 native链接阶段找不到系统库，根因是Command Line Tools不完整

另一个高频报错出现在OpenHarmony native编译的链接阶段，典型信息是ld: library not found for -lz或ld: library not found for -lc++。这个报错在Intel Mac上很少见，因为老的MacOS SDK默认带了很多系统库。M3搭配新版macOS时，Command Line Tools如果没装全，系统库路径就不完整。

我推荐直接用xcode-select --install安装最新的命令行工具。装完后可以用xcode-select -p确认路径，正常情况下会输出/Library/Developer/CommandLineTools。如果还报缺库，再检查一下/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/目录下有没有对应的libz.tbd文件。这类问题通常是安装RDC版本工具链时漏了某个组件，重装一次基本能解决。

5.3 构建脚本里的Python解释器路径问题

OpenHarmony SDK的某些工具脚本，尤其是和native层构建相关的部分，对Python解释器的查找路径是写死的。有的脚本默认找/usr/bin/python3，在系统自带的新版macOS里这个路径通常存在；但也有部分遗留脚本还在用python2风格语法，M3的新系统根本没有python2。

我遇到的情况是：执行hvigor构建时，脚本报ImportError: No module named 'xx'，乍一看以为是缺Python包，实际是它调用了某个旧的sys.path结构。处理办法是把Python版本统一到3.9以上，并且用python3 --version确认默认解释器；如果还不行，用type -a python3看看有没有多个解释器混用，必要时在环境变量里显式指定：

export PATH="/opt/homebrew/bin:$PATH"

5.4 hvigor版本与API级别不一致：典型报错与应对

hvigor和SDK版本不匹配的问题，比前几个坑更隐蔽，因为它往往不是一开始就报，而是构建到某个阶段突然中断。我整理了两个最常见的报错，以及对应的处理方式：

有一种更省心的做法：很多OpenHarmony项目会在仓库里内置hvigor的wrapper脚本，改用一个具体版本号。这样团队里每个人构建用的hvigor版本完全一致，能避免很多不可控的版本漂移问题。

5.5 依赖下载慢和镜像配置

OpenHarmony开发过程中，ohpm包下载、npm包下载、pub包下载三个环节都可能遇到网络延迟问题。严格来说这不算是M3特有的坑，但M系列芯片用户如果不提前处理，体验会非常差——因为首次构建本来就要下很多东西，网络再慢直接让人崩溃。

配置思路和大家熟知的npm镜像、pub镜像一样，ohpm也支持把注册表指向可用的镜像源。在~/.ohpmrc里配置源地址，或者通过ohpm config set registry指定。把这一步放到环境搭建阶段做，后面能省下大量等待时间。

提示：镜像配置虽然是常规操作，但具体地址一定要以你所在网络环境能稳定访问的为准，不要盲抄搜索引擎给的过时配置。

6. 更深入一步：端侧插件、渲染策略与团队工程化

6.1 用方法通道调用端侧能力：一个极简示例

环境跑通只是开始，真实项目里Flutter侧往往要调用OpenHarmony的端侧能力，比如读取设备SN、调用扫码模块、操作串口等。Flutter的标准做法是MethodChannel。

Dart侧：

import 'package:flutter/services.dart'; class DeviceBridge { static const MethodChannel _channel = MethodChannel('com.example.device'); static Future<String> getDeviceInfo() async { final String result = await _channel.invokeMethod('getDeviceInfo'); return result; } }

OpenHarmony壳工程的ETS侧，在FlutterPlugin的初始化逻辑里注册channel，处理Dart侧发过来的方法调用：

import { FlutterPlugin } from '@ohos/flutter_ohos'; export class DevicePlugin implements FlutterPlugin { onAttachToEngine(binding: FlutterEngineBinding) { const channel = new MethodChannel(binding.getBinaryMessenger(), 'com.example.device'); channel.setMethodCallHandler((call, result) => { if (call.method === 'getDeviceInfo') { result.success('device-info'); } else { result.notImplemented(); } }); } }

这里提醒一下：Flutter-OH在不同版本的适配分支里，ETS侧FlutterPlugin的API形态有过调整。如果你拿到的示例编译不过，优先去仓库的example目录看它自带的调用方式，那是最新的真实用法。

6.2 Skia/Impeller取舍和包体积简化

目前社区适配分支的渲染后端，大多数以Skia为主，Impeller的OpenHarmony支持还在打磨阶段。这个现实意味着：如果你在Android上开了Impeller，到OpenHarmony端会默认退回到Skia路径，某些动画帧率可能有差异。做性能调优的时候，先别急着怪Dart代码，确认两端的渲染后端是否一致，再去比对帧率数据才有意义。

包体积方面，Flutter引擎so库占了大头。OpenHarmony同样支持flutter build --split-debug-info和--obfuscate这类参数，能压缩调试信息并混淆Dart代码。不过混淆后的堆栈需要用对应版本的符号表还原，CI环境里记得把debug info归档留底。

6.3 用fvm与版本锁定保证多人协作一致

如果你的团队不止一个人在搞Flutter-OH，最烦人的就是"我这边能跑，你那边跑不了"。这种问题八成是Flutter版本或SDK版本不一致导致的。建议直接用fvm管理Flutter版本，把fvm use <适配分支版本>写入项目配置。同时把OpenHarmony SDK版本、hvigor版本、ohpm源地址都写进团队的README，维护一份环境版本清单，比让每个人自己摸索高效得多。

6.4 值得继续深入的方向

在我的实际体验中，环境跑通之后有几个方向可以继续挖：

• 桌面形态设备：OpenHarmony不止跑在手机上，很多行业终端是带大屏的盒子设备，Flutter-OH在桌面形态下的窗口适配还比较粗糙，值得关注；
• CI/CD打包：在M3上手动打包只是第一步，真正规范的做法是搭一条自动构建流水线，让开发提交后自动触发HAP构建、签名、归档，把环境问题隔离在构建机上；
• 原生插件生态：OpenHarmony侧的端侧能力调用，最终会沉淀成一套团队私有的方法通道封装，这部分设计得好不好，直接决定了Flutter层代码的跨端复用率。

最后分享一点个人体会：这套环境最容易让人放弃的节点不是报错本身，而是"未知的等待"。第一次编译引擎期间，终端长时间没有动静，很多人会以为卡死，然后反复重启，反而把缓存的编译进度全废了。我的建议是，在第一次编译之前就开好ccache，并且耐心等它跑完。真跑到第二次的时候你会发现，整个流程其实非常顺。这个环境给我最大的感受是：Flutter代码在Android、iOS、OpenHarmony三端几乎零改动跑起来这件事，从现在开始已经不只是"理论上可行"了。