为什么这个鸿蒙 Flutter 项目把 AI、平台能力、业务逻辑分层放在 ‘core/’

适合谁看

• 正在规划鸿蒙 Flutter 项目目录的人

• 不确定core/应该放什么的人

• 想把鸿蒙平台能力和业务页面分开的开发者

问题背景

项目越往后做，越会出现一批“不属于某个单一页面”的能力：

• AI 服务

• 路由桥接

• 平台通道

• 网络客户端

• 本地存储

• 应用配置

如果这些东西不收口，就会散在 feature 目录里，最后很难维护。

而在鸿蒙 Flutter 项目里，这类“跨页面能力”还会继续增加：

• 系统直达入口参数

• 语音识别和 TTS 这类原生能力

• 防窥状态这类平台事件

• 卡片和系统入口的桥接逻辑

也就是说，core/在这里不只是目录习惯，而是架构分工的需要。

项目中的真实场景

食界探味当前的core/主要包含：

• app/lib/core/ai/

• app/lib/core/config/

• app/lib/core/network/

• app/lib/core/platform/

• app/lib/core/storage/

• app/lib/core/theme/

• app/lib/core/utils/

而和鸿蒙侧形成直接对应的还有：

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

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

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

核心实现

如果这篇只停在“把公共代码收进core/比较整洁”，信息密度还是不够。
对鸿蒙 Flutter 教程来说，更重要的是解释：

• 哪些东西天然该离开 feature 页面

• 为什么这些东西在 HarmonyOS 场景下更应该被收进core/

一、AI 不属于某一个 feature 页面，它本质上是跨场景能力层

虽然当前 AI 助手有独立页面，但：

• AgentService

• AiExploreCoordinator

• 工具调用

本质上都不是单页私有逻辑。
把它们放在core/ai，说明它们是“可被多个场景消费的能力层”。

这点对鸿蒙项目也成立。
因为 AI 助手不是只会被某个按钮调用，它还可能和：

• 语音输入

• TTS 播报

• 系统直达后的页面承接

一起协作。
这类能力如果仍然塞在单个 feature 目录里，后面很容易越写越散。

二、平台能力本身更不应该塞进 feature 目录，因为它们代表的是鸿蒙平台边界

像：

• speech_recognition_channel.dart

• text_to_speech_channel.dart

• intent_navigation_channel.dart

• anti_peep_protection_channel.dart

这些都应该收进core/platform。
因为它们代表的是平台边界，不是业务页面边界。

而且当前项目里这条边界并不是抽象想象出来的，而是和鸿蒙原生层一一对应的：

• intent_navigation_channel.dart对应IntentNavigationPlugin.ets

• speech_recognition_channel.dart对应SpeechRecognitionPlugin.ets

• text_to_speech_channel.dart对应TextToSpeechPlugin.ets

• anti_peep_protection_channel.dart对应AntiPeepProtectionPlugin.ets

这说明core/platform在当前项目里的职责非常明确：

• 它不是业务 service

• 也不是页面 controller

• 它是 Flutter 和 HarmonyOS 原生层之间的稳定边界

三、系统入口相关逻辑也应该优先落在core/边界层，而不是 feature 页面里

很多鸿蒙教程最容易漏掉的一点是：

• 系统入口本身也是一种“跨页面能力”

当前项目里最典型的样板就是：

• app/lib/core/platform/intent_navigation_channel.dart

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

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

这里的逻辑如果直接散到：

• 搜索页

• 愿望单页

• 详情页

这些 feature 里，后面系统直达链会非常难维护。
所以它被放进core/platform，本质上是在保护路由和页面层。

四、网络、配置、存储天然适合基础层，而不是和鸿蒙平台逻辑混在一起

像：

• api_client.dart

• app_config.dart

• token_storage.dart

这些能力会被多个功能模块复用，单独沉到core/更合理。

这一步还有一个很重要的好处：

• 让core/platform可以专注平台边界

• 让core/network、core/storage、core/config专注基础设施

这样到了鸿蒙项目里，你就不会把：

• 网络请求

• token 存储

• 原生入口桥接

混成一锅。

五、这样做能让 feature 目录更聚焦业务，让 HarmonyOS 能力不直接污染页面

当前features/目录更像：

• 探索

• 搜索

• 收藏

• 愿望单

• 个人中心

也就是面向用户的产品功能。
这正好和core/形成分工。

在鸿蒙项目里，最危险的一种退化就是：

• 页面一边写业务

• 一边直接调MethodChannel

• 一边自己判断系统入口参数

一旦这样写，feature 目录就会同时承担：

• 业务逻辑

• 路由判断

• 平台桥接

• 原生兜底

当前项目把这些东西先收进core/，本质上是在保护页面层。

关键代码位置

• app/lib/core/ai/

• app/lib/core/platform/

• app/lib/core/network/api_client.dart

• app/lib/core/config/app_config.dart

• app/lib/core/storage/token_storage.dart

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

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

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

鸿蒙侧实现

对鸿蒙 Flutter 项目来说，这种分层尤其重要。
因为来自 ArkTS 的系统能力回调，不应该直接落到某个页面里，而应该先收进：

• core/platform

再由业务层消费。

当前项目里，无论是：

• EntryAbility带进来的pageId / dishId

• IntentNavigationPlugin推回来的入口事件

• 防窥插件推回来的可见性事件

都更适合先经过core/platform这一层，再进入 Flutter 路由和页面。

Flutter 侧实现

Flutter 侧当前这套分层已经很明确：

• core/放跨模块能力

• features/放业务功能

• data/models放内容对象

这是一套比较稳的中型项目结构。
而且放到鸿蒙项目里，它还有一个额外价值：

• 能把 Flutter 体验层和 HarmonyOS 平台层通过core/platform隔开

这样你写教程时，才能很清楚地讲：

• 哪些属于页面

• 哪些属于跨模块能力

• 哪些属于平台桥接

常见坑

• core/变成杂物箱，什么都往里扔

• 平台通道直接写在页面文件里

• AI 服务既在页面里，又在服务层里重复一份

• core/和features/职责边界不清

• HarmonyOS 入口逻辑散落在多个页面里，最后没人说得清系统直达链从哪开始到哪结束

• core/platform里既放业务判断又放原生桥接，最后边界重新变糊

可复用模板

core/ ai/ config/ network/ platform/ storage/ features/ explore/ search/ collection/

HarmonyOS 原生侧 -> core/platform -> features 系统入口、平台事件、原生能力先经过 platform 边界层 页面只消费整理后的结果

本篇总结

• 把 AI、平台能力和基础服务收进core/，核心是职责分层

• 对鸿蒙 Flutter 项目来说，core/的价值不只是目录整洁，而是把 HarmonyOS 原生侧和 Flutter 业务侧隔开

• 这样做能让系统入口、平台事件、原生能力先收口，再进入路由和页面，后面维护会稳很多