为什么这个鸿蒙 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.etsapp/ohos/entry/src/main/ets/entryability/InsightIntentExecutorImpl.etsapp/ohos/entry/src/main/ets/plugins/核心实现如果这篇只停在“把公共代码收进core/比较整洁”信息密度还是不够。对鸿蒙 Flutter 教程来说更重要的是解释哪些东西天然该离开 feature 页面为什么这些东西在 HarmonyOS 场景下更应该被收进core/一、AI 不属于某一个 feature 页面它本质上是跨场景能力层虽然当前 AI 助手有独立页面但AgentServiceAiExploreCoordinator工具调用本质上都不是单页私有逻辑。把它们放在core/ai说明它们是“可被多个场景消费的能力层”。这点对鸿蒙项目也成立。因为 AI 助手不是只会被某个按钮调用它还可能和语音输入TTS 播报系统直达后的页面承接一起协作。这类能力如果仍然塞在单个 feature 目录里后面很容易越写越散。二、平台能力本身更不应该塞进 feature 目录因为它们代表的是鸿蒙平台边界像speech_recognition_channel.darttext_to_speech_channel.dartintent_navigation_channel.dartanti_peep_protection_channel.dart这些都应该收进core/platform。因为它们代表的是平台边界不是业务页面边界。而且当前项目里这条边界并不是抽象想象出来的而是和鸿蒙原生层一一对应的intent_navigation_channel.dart对应IntentNavigationPlugin.etsspeech_recognition_channel.dart对应SpeechRecognitionPlugin.etstext_to_speech_channel.dart对应TextToSpeechPlugin.etsanti_peep_protection_channel.dart对应AntiPeepProtectionPlugin.ets这说明core/platform在当前项目里的职责非常明确它不是业务 service也不是页面 controller它是 Flutter 和 HarmonyOS 原生层之间的稳定边界三、系统入口相关逻辑也应该优先落在core/边界层而不是 feature 页面里很多鸿蒙教程最容易漏掉的一点是系统入口本身也是一种“跨页面能力”当前项目里最典型的样板就是app/lib/core/platform/intent_navigation_channel.dartapp/ohos/entry/src/main/ets/entryability/EntryAbility.etsapp/ohos/entry/src/main/ets/entryability/InsightIntentExecutorImpl.ets这里的逻辑如果直接散到搜索页愿望单页详情页这些 feature 里后面系统直达链会非常难维护。所以它被放进core/platform本质上是在保护路由和页面层。四、网络、配置、存储天然适合基础层而不是和鸿蒙平台逻辑混在一起像api_client.dartapp_config.darttoken_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.dartapp/lib/core/config/app_config.dartapp/lib/core/storage/token_storage.dartapp/ohos/entry/src/main/ets/entryability/EntryAbility.etsapp/ohos/entry/src/main/ets/entryability/InsightIntentExecutorImpl.etsapp/ohos/entry/src/main/ets/plugins/鸿蒙侧实现对鸿蒙 Flutter 项目来说这种分层尤其重要。因为来自 ArkTS 的系统能力回调不应该直接落到某个页面里而应该先收进core/platform再由业务层消费。当前项目里无论是EntryAbility带进来的pageId / dishIdIntentNavigationPlugin推回来的入口事件防窥插件推回来的可见性事件都更适合先经过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 业务侧隔开这样做能让系统入口、平台事件、原生能力先收口再进入路由和页面后面维护会稳很多