适合谁看

• 正在规划鸿蒙 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 业务侧隔开

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