适合谁看

• 正在同时使用 Flutter 和 DevEco Studio 的开发者

• 经常分不清问题该在哪个工具里查的人

• 想建立工具链分工意识的人

问题背景

很多人刚开始做鸿蒙 Flutter 项目时，会下意识地把工具链也想得很简单：

• 页面开发用 Flutter

• 原生开发用 DevEco

这个方向没错，但还不够具体。
因为真实开发里，你会不断遇到下面这些混合场景：

• flutter run -d ohos 能启动，但原生能力不工作

• Flutter 页面没问题，但 module.json5 或权限配置不对

• ArkTS 插件逻辑需要排查，但你还在用 Flutter 命令层思路看问题

如果工具链职责没有分清，最常见的结果就是：

• 在错误的工具里找错误

• 明明是壳工程问题，却一直改 Dart

• 明明是页面和路由问题，却反复在 DevEco Studio 里打转

项目中的真实场景

食界探味当前的工程结构很适合拿来说明这件事，因为它同时具备：

• Flutter 主应用：app/lib/

• HarmonyOS 壳工程：app/ohos/

• ArkTS 插件：app/ohos/entry/src/main/ets/plugins/

• Ability 与卡片入口：app/ohos/entry/src/main/ets/entryability/、formability/

• Hvigor 构建脚本：app/ohos/hvigorfile.ts、app/ohos/entry/hvigorfile.ts

• 本地 SDK 路径配置：app/ohos/local.properties

换句话说，这个项目里已经天然存在两套开发视角：

• Flutter 业务视角

• HarmonyOS 壳工程视角

而且两者并不是完全割裂的，中间还夹着一层真正把鸿蒙构建跑起来的配置和脚本层。

核心实现

先给一个最有用的结论：

Flutter 工具链更适合高频开发和业务联调，DevEco Studio 更适合理解壳工程、观察鸿蒙入口和排查原生层问题。

只要先把这个分工记住，很多“到底该去哪边查”的问题就会简单很多。

如果把真实开发流程再压缩一下，可以记成这张分工表：

Flutter CLI       -> 跑应用、改 Dart、看页面、做日常联调
DevEco Studio     -> 看壳工程、改 ArkTS、查 Ability、看鸿蒙配置
Hvigor / 配置层   -> 真正执行鸿蒙构建、依赖、模块打包

一、Flutter 工具链更适合做什么

在食界探味里，如果你现在的工作重点是下面这些内容，优先在 Flutter 工具链一侧工作通常更高效：

• 页面和交互开发

• 路由与状态管理

• 网络请求和数据层调整

• app/lib/core/platform/ 里的边界封装

• 日常高频运行联调

对应的典型命令包括：

• flutter pub get

• flutter run -d ohos

• flutter analyze

• flutter test

这一侧更像“应用体验工作台”。
它解决的是：

• 页面有没有按预期工作

• Dart 代码有没有问题

• Flutter 侧边界层封装是否合理

如果你这一天的工作重点是下面这些问题，通常都不需要先打开 DevEco Studio：

• GoRouter 路由是否正确

• Riverpod 状态有没有更新

• 接口数据有没有渲染到页面

• app/lib/core/platform/ 的 Dart 封装是否合理

• 某个按钮点击后有没有正确发起 channel 调用

二、DevEco Studio 更适合做什么

如果你现在的重点变成下面这些事情，那更适合回到 DevEco Studio 一侧：

• 阅读和理解 app/ohos/ 结构

• 查看 module.json5、build-profile.json5 这类鸿蒙配置

• 观察 EntryAbility、Want、FormExtensionAbility

• 查看和调试 ArkTS 插件

• 关注 HarmonyOS 原生日志、原生工程上下文和 SDK 环境

这一侧更像“壳工程观察台”。
它解决的是：

• 鸿蒙模块到底怎么声明

• 原生插件有没有接住调用

• Ability 和卡片入口是不是按系统方式工作

再具体一点，下面这几类文件在 DevEco Studio 里读会更顺手：

• app/ohos/build-profile.json5

• app/ohos/entry/build-profile.json5

• app/ohos/entry/src/main/module.json5

• app/ohos/entry/src/main/ets/entryability/EntryAbility.ets

• app/ohos/entry/src/main/ets/plugins/*.ets

• app/ohos/entry/src/main/ets/formability/*.ets

三、Hvigor 和本地 SDK 配置在这套协作里扮演什么角色

很多人会把问题理解成“Flutter vs DevEco”，但真正执行鸿蒙构建时，中间其实还有一层不能忽略：

• app/ohos/hvigorfile.ts

• app/ohos/entry/hvigorfile.ts

• app/ohos/local.properties

在食界探味里：

• 根目录的 hvigorfile.ts 把 flutter-hvigor-plugin 接进了应用级构建流程

• entry/hvigorfile.ts 负责模块级 hapTasks

• local.properties 记录本机 hwsdk.dir 和 flutter.sdk

这意味着：

• Flutter 命令并不是凭空把鸿蒙包跑起来的

• DevEco Studio 也不是独立于 Flutter 工具链之外的另一套世界

• 两者最终都会落到壳工程配置、Hvigor 构建脚本和本地 SDK 环境上

所以一旦出现“命令能跑但构建怪异”“工程能开但 SDK 不认”“插件代码改了但打包行为不对”这类问题，就要把 Hvigor 和本地配置一起拉进来看。

四、食界探味里，两套工具链分别对应哪些位置

如果回到真实目录，会更容易建立映射关系。

更偏 Flutter 工具链的区域

• app/lib/features/

• app/lib/data/

• app/lib/core/

• app/lib/core/platform/

这些目录里的问题，大多数时候更适合先用 Flutter 视角处理。

更偏 DevEco Studio 的区域

• app/ohos/build-profile.json5

• app/ohos/oh-package.json5

• app/ohos/entry/src/main/module.json5

• app/ohos/entry/src/main/ets/entryability/

• app/ohos/entry/src/main/ets/plugins/

• app/ohos/entry/src/main/ets/formability/

这些目录里的问题，大多数时候都更像鸿蒙工程问题，而不是普通 Flutter 页面问题。

五、最容易混淆的 5 类场景

场景 1：页面能打开，但某个鸿蒙能力不起作用

这时候很多人第一反应是继续改 Dart。
但更稳的做法通常是分两步：

• 先用 Flutter 视角确认页面调用是否正常发出

• 再去 DevEco Studio 视角看 ArkTS 插件是否真的接住了调用

场景 2：flutter run -d ohos 失败

这时不应该只盯着 Flutter 命令本身。
因为它背后已经涉及：

• 壳工程配置

• 构建系统

• 签名和 profile

这类问题往往要回到鸿蒙工程视角里看。

更准确地说，这一类问题通常要按这条顺序排：

1. Flutter 设备识别有没有问题

2. app/ohos/local.properties 里的 hwsdk.dir、flutter.sdk 是否正确

3. build-profile.json5、entry/build-profile.json5 有没有明显配置异常

4. Hvigor 构建脚本有没有接上 Flutter 壳工程

场景 3：Intent 或卡片入口行为不对

如果问题涉及：

• EntryAbility

• InsightIntentExecutorImpl

• DailyRecommendFormAbility

那它已经明显不是“普通 Flutter 页面路由问题”，而是系统入口问题。
这时 DevEco Studio 一侧会更有帮助。

场景 4：页面布局和业务逻辑不对

这类问题就没必要一开始跑去壳工程里找。
优先还是：

• Flutter 路由

• 状态管理

• 页面层代码

场景 5：工程能打开，但某些鸿蒙配置改了没生效

这种情况常见的原因不是“Flutter 热重载失效”，而是你改动的本来就是壳工程配置或原生代码。
比如：

• module.json5 改了权限

• build-profile.json5 改了产品或签名

• EntryAbility.ets 改了启动参数承接

这类内容本来就更靠近壳工程，需要回到 DevEco Studio 和鸿蒙构建视角理解。

六、日常开发时，最省时间的切换方法是什么

如果你不想每次都纠结“到底开哪个工具”，可以直接套用这套顺序：

1. 日常页面和业务开发时，以 Flutter CLI 为主

2. 要看 app/ohos/ 目录、Ability、插件、卡片时，切到 DevEco Studio

3. 一旦报错里出现签名、模块、构建、SDK、Hvigor 关键词，就回壳工程和配置层排查

4. 一旦报错只落在 Dart 页面、状态、路由、接口上，就继续用 Flutter 视角

这套切换方法的核心不是“熟练切软件”，而是先判断问题属于哪一层。

七、为什么不能只用其中一套工具链

这也是很多初学者最容易卡住的地方。

如果只用 Flutter 工具链，你会逐渐看不清：

• app/ohos/ 到底做了什么

• 原生插件层到底怎么接系统能力

• 系统入口为什么不等于 Flutter 路由

如果只用 DevEco Studio，你又会逐渐脱离：

• Flutter 页面主线

• 业务状态流

• 跨平台共享层

所以更准确的理解不是“二选一”，而是：

Flutter 工具链负责让你高频推进应用层，DevEco Studio 负责让你真正看懂和处理鸿蒙壳工程层。

关键代码位置

• app/lib/

• app/lib/core/platform/

• app/ohos/

• app/ohos/entry/src/main/ets/

• app/ohos/entry/src/main/module.json5

• app/ohos/hvigorfile.ts

• app/ohos/entry/hvigorfile.ts

• app/ohos/local.properties

鸿蒙侧实现

从鸿蒙侧看，DevEco Studio 更接近这几类信息：

• Ability 生命周期

• 原生插件实现

• 模块声明

• 卡片能力

• 原生日志与 SDK 环境

• Hvigor 构建脚本

• 本地 HarmonyOS SDK 配置

所以只要你面对的是“系统入口、原生插件、构建配置”这类问题，优先回到鸿蒙工程视角通常更快。

Flutter 侧实现

从 Flutter 侧看，工具链的价值主要在于：

• 高频修改和运行

• 页面和状态层迭代

• 平台边界层联调

对食界探味这种 Flutter 主体很重的项目来说，这依然是日常开发主线。

但也要记住一个边界：

• Flutter CLI 很擅长让你高频推进

• 它并不会自动替你解释 app/ohos/ 里的模块声明、窗口生命周期和构建细节

所以真正高效的方式不是“只用 Flutter 命令”，而是“先用 Flutter 推进，再用 DevEco Studio 读懂壳层”。

常见坑

• 原生问题一直在 Flutter 命令层排

• Flutter 路由和业务问题却跑去 DevEco Studio 里找

• 看到能运行就以为不需要理解 app/ohos/

• 把工具链切换频繁理解成“麻烦”，而不是“分层协作”

• 只知道 flutter run -d ohos，却不知道它背后还依赖 Hvigor 和本地 SDK 配置

• 改了 module.json5、EntryAbility.ets 之类的壳层内容，却还用纯 Dart 视角理解问题

可复用模板

Flutter 工具链更适合
- 页面
- 业务
- Dart 代码
- 高频联调

DevEco Studio 更适合
- 壳工程
- Ability
- ArkTS 插件
- 鸿蒙配置和原生日志

Hvigor / 本地配置更适合检查
- 构建脚本
- SDK 路径
- 模块打包链路

判断顺序
1. 先问问题更像页面层还是壳工程层
2. 页面层优先 Flutter 视角
3. 壳工程层优先 DevEco Studio 视角
4. 构建层问题回到 Hvigor 和 local.properties

本篇总结

DevEco Studio 和 Flutter 工具链不是互斥关系，而是同一个项目里两个不同层级的工作入口。
对食界探味这种鸿蒙 Flutter 项目来说，最实用的思路不是“我更喜欢哪一个工具”，而是先判断问题落在哪一层，再决定回到哪一边处理。