评估从目标环境开始
先确认目标设备运行 HarmonyOS 商用系统还是 OpenHarmony 发行版，再据此选择 SDK、API、应用模型和 Flutter 适配仓。本文整理的是项目评估路径与公开资料核对结果；架构示意只用于说明组件职责，实际能力仍要对应到目标分支的构建记录或设备验证。
系统与适配仓分别核对
把系统身份和工具链版本写进评估记录，避免把相近的产品名称当成兼容性结论：
| 检查对象 | 评估记录 | 核验材料 |
|---|---|---|
| HarmonyOS 商用系统 | 系统版本、目标 API、应用模型 | 工程配置、Ability 入口及目标设备文档 |
| OpenHarmony 社区 Flutter | 适配仓、分支与 commit，SDK 和插件版本 | 仓库 README、构建脚本、Samples 与构建日志 |
| HarmonyOS NEXT 目标设备 | 设备型号、API 和所需系统能力 | 对应版本的官方文档、适配仓说明和真机结果 |
每份评估至少应能追溯到系统产品线、API、适配仓 commit 和测试设备。华为开发者的测试服务说明列出了兼容性、稳定性、性能、功耗、安全和 UX 六项质量维度；提交前还要核对目标版本当前有效的规范。
按组件职责评估适配仓
Flutter 工程可以从 Framework、Engine 和平台 Embedder 三层查起。下面的问题用于定位配置、代码和构建产物，最终结论应落到具体仓库版本或设备记录：
| 层次 | 核验内容 |
|---|---|
| Flutter Framework | 现有 Dart 页面、插件 API 和路由在目标分支上的支持情况 |
| Engine | Flutter commit、Engine 构建产物和目标 ABI |
| 平台 Embedder | 窗口、生命周期、输入与任务调度对应的代码位置 |
| 系统能力 | 应用模型、权限、图形接口和设备 API 的实现与覆盖范围 |
OpenHarmony SIG 的 Flutter 仓库及 Samples 可作为社区工具链入口。对 Rosen、ArkUI 或具体插件的支持情况，逐项对照所选分支的代码和示例确认。
判断项目是否适合复用 Flutter
评估是否复用 Flutter 时，把业务目标、目标设备、现有代码资产和插件覆盖放在一起比较：
- 目标产品运行哪一套系统，设备、API 和应用模型分别是什么？
- 社区分支列出的支持范围是否覆盖目标系统版本、架构与设备？
- 登录、推送、支付和定位等关键插件在目标平台上有哪些实现？
- 插件缺口由自研、原生页面替换或调整业务范围，哪种成本更合适？
- 目标应用市场当前的兼容性、安全与 UX 要求有哪些？
用目标设备文档、适配仓说明、构建结果和业务需求支撑这些判断，再决定采用 Flutter、混合栈还是原生实现。
启动前准备
| 类别 | 需要明确的内容 | 启动动作 |
|---|---|---|
| 组织 | 跨端框架负责人、鸿蒙研发接口人 | 建立固定的评审和问题跟进机制 |
| 资产 | Flutter 版本、插件平台覆盖、私有原生能力 | 逐项标记可复用、需替换和待验证的依赖 |
| 工具 | DevEco Studio、OpenHarmony SDK、Flutter-Harmony 分支 | 按目标分支配置构建链，并将构建纳入 CI |
| 规范 | 设计、交互和测试要求 | 准备目标设备及系统版本对应的测试矩阵 |
发布评估按目标 HarmonyOS 版本和市场要求检查 UX、兼容性、稳定性、性能、功耗与安全；涉及审核条款时，以提交时生效的官方规范为准。
用可验证的交付物安排评估
把进度拆成可以复现和复核的交付物：
- 范围确认：列出系统产品线、API、应用模型、设备与 Flutter 适配仓 commit。
- 工具链验证：按目标分支 README 安装工具并构建最小示例，保存完整日志。
- 插件盘点：逐个记录核心依赖的平台实现、替代方案和未覆盖能力。
- 关键流程验证：在目标设备检查启动、权限、网络、存储、后台恢复和图形表现。
- 发布评估：按目标市场的当前审核规范完成安全、兼容性和 UX 检查。
需要持续跟踪的风险
| 风险 | 评估方法 |
|---|---|
| 社区分支和上游 Flutter 版本不一致 | 锁定仓库、分支、commit 和 Engine 产物；升级前重新构建 |
| 插件未覆盖目标平台 | 查源码和目标分支 Samples；关键能力安排真机验证 |
| 应用模型或系统 API 不匹配 | 以项目配置文件和目标 API 文档确定，不跨模型复制代码 |
| 性能或稳定性缺少基线 | 在目标设备的 profile/release 构建中记录场景、日志和帧数据 |
| 发布要求变化 | 提交前核对当期应用市场规范，不引用未经核验的固定比例或旧版本条款 |
团队需要的知识与工具
- 系统层面：OpenHarmony 架构、Stage/Ability 模型、分布式软总线。
- Flutter 层面：Embedder API、Engine 编译流程、Platform Channels。
- 跨端经验：原生能力封装、混合栈导航、性能调优、CI/CD。
- 合规要求：HarmonyOS 应用审核标准、安全能力调用规范。
参考资料
- 官方文档
- 社区实践
- Flutter-Harmony 开源适配项目（GitHub/Gitee）
- 社区鸿蒙插件列表与 Demo 仓库
本文的核验范围
本文核对了公开资料；当前没有可复现的设备型号、系统 build/API、DevEco 版本、Flutter 适配仓 commit、构建命令和日志，因此没有把 Stage Ability、页面渲染或真机流程列为已验证项。基础适配篇中的命令针对 OpenHarmony SIG 社区工具链，可用于相应分支的环境核对。
补充实测时，记录设备型号、系统 build/API、DevEco 版本、适配仓 commit、构建命令、结果和日志。工具链核对可从OpenHarmony 社区基础适配篇继续。