开头直接进入主题，聊聊在 OpenHarmony 上跑 Flutter 这件事。说实话，Flutter for OpenHarmony 从出现到真正可用，中间经历过一段“看起来很美、用起来想哭”的阶段，但最近大半年，工具链和插件生态已经扎实了不少。这篇实战系列的第一期，我会以“每日热点 App”为具体落地场景，完整走一遍项目初始化、鸿蒙插件配置、工程结构设计、编译联调的全流程，把其中踩过的坑和绕过的弯都摊开来讲。

如果你是刚接触 OpenHarmony 的 Flutter 开发者，或者已经在做鸿蒙原生开发、想用 Flutter 做跨端统一，这篇文章应该是能直接抄作业的。项目初始化是最容易出幺蛾子的环节，很多问题都出在“环境对了但配置不对”或者“插件路径没配对”，我会把每一步的命令、参数、配置文件内容都贴出来，并解释为什么这么配。

1. 内容整体设计与思路拆解

1.1 项目背景：为什么是“每日热点”这个 App

在 OpenHarmony 生态里做 App，最缺的其实是“能跑、能看、能扩展”的示例工程。官方文档和 Demo 偏向单点能力展示，比如一个列表、一个组件、一个 canvas 绘画，但真实的业务 App 涉及网络请求、状态管理、多页面路由、平台通道调用等组合动作。

“每日热点”这个题材选得比较讨巧：它天然需要一个信息流页面、一个详情页面，还要处理网络数据解析、下拉刷新、加载状态，这些组合在一起能覆盖 Flutter 日常开发 80% 的高频场景。而且热点数据源可以直接用公开 API 或者本地 Mock 数据，不用纠结后端服务，项目初始化阶段就能把大部分技术链路跑通，对后续扩展也友好。

1.2 技术选型：为什么选用 Flutter 而非 ArkUI 单独开发

在 OpenHarmony 上开发应用，原生选择自然是 ArkUI，但如果你手里已经有一个 Flutter 版本的应用，或者在 Android、iOS 上已经用 Flutter 积累了组件库和业务逻辑，直接用 Flutter for OpenHarmony 可以把这些资产复用过来。

这里需要补一个认知：Flutter for OpenHarmony 不是简单地把 Flutter Engine 交叉编译到 OpenHarmony 上，而是由 OpenHarmony 团队维护了一个独立的适配分支，提供 flutter_flutter 的社区版本，同时通过 ohos 平台目录完成针对 OpenHarmony 的构建产物生成。这意味着你可以用一套 Dart 代码，同一套 Flutter 组件树，同时构建出 Android、iOS 和 OpenHarmony（HAP/APP）三个平台的应用。

实践下来，这个方案最大的好处是业务代码的复用率极高。比如我自己维护的一个资讯类项目，Android 端和鸿蒙端的 UI 逻辑基本零改动，只有平台通道那部分需要针对 OpenHarmony 的特性做适配。而 ArkUI 学习成本虽然不算高，但如果是成熟团队，从 Flutter 切过去反而浪费了已有的代码资产。

1.3 整体架构规划：项目初始化阶段需要想清楚的事

我习惯在写第一行代码前先把目录结构和依赖关系画清楚，避免后面越写越乱。每日热点 App 的项目初始化阶段，至少要确定这几件事：

• 使用什么样的状态管理：个人推荐 Riverpod 或者 Provider，前者更灵活，后者更简单，看团队熟悉度；
• 网络层用哪套：dio 基本是事实标准，拦截器、取消请求、日志打印都方便；
• 路由方案：直接用 Navigator 2.0 或者 go_router，考虑到后面要加 Web 端，go_router 会更合适；
• 鸿蒙插件需要哪些：第一版先跑通系统能力（比如剪贴板、传感器），后续再看业务需要接入哪些 ohos 插件。

这些决策不复杂，但需要在项目初始化时落实到位。因为 Flutter for OpenHarmony 的工程结构和标准 Flutter 工程有个重要差异——它会多出一个 ohos 目录，这个目录对应着 OpenHarmony 的工程配置，包括 module.json5、build-profile.json5 这些鸿蒙特有的配置文件，后续集成插件、配置权限、声明 ability 都要在这里操作。

2. 核心细节解析与实操要点

2.1 Flutter for OpenHarmony 开发环境的完整准备清单

环境准备是项目初始化的第一道坎。官方文档写得比较分散，我根据实际安装过程整理了一份自检清单：

这里有个关键点容易被忽略：如果你本机已经装了官方 Flutter SDK，需要区分 flutter 命令指向的是哪套 SDK。我当时就是吃了这个亏，`f