威廉穆斯利最近我接到一个不太一样的任务：把公司内部一直在用的商用项目看板应用，从既有 Flutter 代码库延伸到鸿蒙端。换两年前，听到“鸿蒙开发”四个字，我第一反应大概率是“又要重写一套原生界面”，但现在情况变了——Flutter 框架对鸿蒙的适配已经能支撑实际业务，跨平台方案里又多了一个值得认真评估的落地点。
这篇文章不聊空洞概念，就围绕标题里的几个关键词展开：Flutter 框架、跨平台、鸿蒙、项目看板。我会完整复盘一遍从环境准备、工程初始化、看板核心功能实现，到鸿蒙原生能力接入、调试上架遇到的问题清单。比较适合正在评估“要不要用 Flutter 做鸿蒙端”的团队，也适合已经决定上手、但还没把坑踩完的客户端开发同学。
1. 先确认业务边界和技术选型，比急着写代码重要得多
1.1 这个项目要交付的到底是什么
项目看板不是个人待办工具，它天生是多角色协作场景。老板要看整体进度，产品要拖卡片排迭代，开发要更新自己的任务状态，测试要在卡片下面挂缺陷记录。这些角色分布在手机、平板、PC 不同设备上，而且要求界面观感基本一致，不能今天 Android 上看起来是个样，明天鸿蒙上又变了另一个样。
商用两个字意味着很多“隐形需求”不是 demo 能覆盖的。除了核心的看板列、卡片、拖拽流转，还要有登录态、权限控制、图片附件上传、后端接口同步、离线缓存、操作日志、异常上报。再加上客户使用的设备五花八门，有的还在用低端机，有的已经换到鸿蒙平板，很多边界情况只能在真机上验证。
我们当时的处境是：Flutter 代码库已经维护了两三年，iOS 和 Android 两端跑得很稳，Web 端也能兼顾后台预览。现在客户明确提出需要鸿蒙端，最理想的方式当然是复用同一套业务代码，而不是让客户端团队再养一条 ArkTS 原生线。于是“Flutter 跨平台鸿蒙开发”这个命题就摆到了桌面上。
1.2 Flutter 和其他跨端方案对比，各自的账要算清楚
在确定技术路线的时候，我认真比较过几条路。第一是直接用 ArkTS 写鸿蒙原生应用，系统能力调用最顺手，HarmonyOS 的意图框架、服务卡片这些独占特性也能第一时间支持，但团队要新增一条完整的技术栈。对一个已经有 Flutter 业务代码的团队来说，等于以后每次改需求都要同步两套客户端，成本是成倍上涨的。
第二是考虑 React Native 或其它跨端框架，跨端社区确实都有人在适配鸿蒙，但很多第三方原生组件、推送 SDK、地图 SDK 并没有完整打通，商用项目一旦碰到某个关键依赖没有鸿蒙实现，就会卡在中间层进退两难。
第三就是 Flutter。Flutter 自带渲染引擎，UI 不依赖系统原生控件，这意味着在 Android 上画出来的卡片样式，在鸿蒙上大概率也能保持同样效果；而且项目看板这类应用恰好是大量自定义卡片、拖拽反馈、动画细节密集的场景，Flutter 的自绘模式天然占优。不过它的短板也很明确：鸿蒙适配仍在快速演进，大量 pub 生态里的三方插件没有鸿蒙原生实现，遇到这种情况需要自己在 MethodChannel 上补一层桥接。
三种路线放在一起，用表格会更直观：
| 对比维度 | ArkTS 原生 | React Native 跨端 | Flutter 跨端 |
|---|---|---|---|
| 系统能力接入 | 最直接 | 依赖第三方桥接 | 依赖 MethodChannel / 三方插件 |
| 多端 UI 一致性 | 各端各自维护 | 较好但组件渲染不一致 | 自绘渲染，最容易统一 |
| 现有 Flutter 代码复用 | 无法复用 | 只能复用 JS 逻辑 | 可复用绝大部分 UI 和业务 |
| 团队学习成本 | 需要新增技术栈 | 中 | 中低 |
| 拖拽/复杂列表场景 | 需要大量原生代码 | 一般 | 强项 |
| 适配鸿蒙最新能力 | 最快 | 较慢 | 中等，视社区进度 |
做完对比，结论很清楚：如果今天从零开始只做鸿蒙一个平台，ArkTS 原生不是不能选，但我们是给成熟产品增加客户端形态，而不是重新发明轮子。Flutter 在跨平台和 UI 一致性上的收益，远远大于那部分需要自己补的原生桥接成本。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 鸿蒙下搭建 Flutter 开发环境，重点在版本匹配和依赖管理
2.1 先检查 Flutter SDK 和 DevEco Studio 是否匹配
鸿蒙端的 Flutter 开发环境和传统 Android 开发有一个显著差异：不能随便从官网拿一个最新版 Flutter 就当鸿蒙用，必须使用社区维护或官方发布的鸿蒙适配分支，版本和 DevEco Studio、HarmonyOS SDK 之间是绑定的。这里没有什么捷径，严格按照你安装的适配版本文档来。
我当时整理的依赖清单大概是这样的：
- DevEco Studio 5.x，包含 HarmonyOS SDK API 12 及以上；
- Flutter SDK 用适配鸿蒙的分支，而不是默认 stable 分支；
- JDK 版本需满足 DevEco 和 Gradle 的双重要求；
- 鸿蒙真机或官方模拟器，用于运行和调试。
环境变量也需要单独配置。比如把鸿蒙 SDK 的路径指给 Flutter，常见操作是执行 flutter config --ohos-sdk，指向 DevEco 自带的 SDK 目录；有些版本还需要设置 OHOS_SDK_HOME。 配置完以后，执行 flutter doctor -v，看输出里有没有 ohos toolchain 相关的可用提示。
注意：如果你刚安装完 Flutter，命令行提示找不到
flutter命令，别急着怀疑安装包坏了，大概率是 PATH 环境变量没有在已经打开的终端里刷新。新开一个终端窗口再执行一次，通常就正常了。这个细节很小，但第一次接触 Flutter 的人几乎都会遇到。
2.2 初始化同时包含 Android、iOS、鸿蒙的工程
当 Flutter 鸿蒙分支准备好之后，初始化工程和传统 Flutter 项目很相似，只是多了一个鸿蒙平台目录。通常可以用下面的命令创建：
bash复制flutter create --p