适合谁看想理解鸿蒙系统入口模型的人已经熟悉 Deep Link但还没接过 Intents Kit 的开发者正在做搜索直达、系统理解型入口的人问题背景很多跨端开发者一开始会问既然已经有路由和 Deep Link为什么还要 Intents Kit这个问题本质上是在问鸿蒙系统希望理解的是链接还是意图。Deep Link 的思路是给一个 URL应用收到后解析并跳转。系统只负责传递 URL不理解 URL 的含义。Intents Kit 的思路是应用声明自己支持哪些意图系统理解这些意图后在合适的时机调起应用执行。项目中的真实场景食界探味当前的 Intents Kit 链路层文件职责配置层insight_intent.json声明意图名称、参数、搜索关键词执行器InsightIntentExecutorImpl.ets校验参数、调用插件插件层IntentNavigationPlugin.ets桥接 FlutterFlutter 层intent_navigation_channel.dart路由跳转核心实现一、Deep Link 更像地址普通 Deep Link 的思路通常是用户点击链接: foodvoyage://dish/beef-001 ↓ 应用收到 URL ↓ 应用自己解析: beef-001 是菜品 ID ↓ 跳转到详情页它重点在地址能不能打开。系统只负责传递 URL不理解 URL 里的内容。Deep Link 的特点特点说明格式URL 字符串scheme://host/path系统理解不理解只传递参数传递靠 URL 解析搜索集成不支持系统搜索找不到语义化弱URL 不表达意图发现性用户需要知道 URL二、Intents Kit 更像结构化意图Intents Kit 的重点则是用户搜索搜索美食 ↓ 鸿蒙系统找到 JumpFunctionPage 入口 ↓ 系统知道这个入口支持搜索功能 ↓ 系统调起应用传入 pageIdsearch ↓ 应用执行跳转Intents Kit 的配置insight_intent.json{ intentName: JumpFunctionPage, inputParams: [{ properties: { pageId: { type: string, enum: [ { value: search, displayName: 搜索美食, keywords: [搜索, 找菜, 查菜], displayDescription: 搜索全球美食与食材 } ] } } }] }这段配置告诉系统入口名叫JumpFunctionPage支持 5 种页面跳转每种都有displayName、keywords、displayDescription系统会根据keywords和displayName在搜索结果中展示这些入口。用户搜索搜索时系统会推荐搜索美食入口。Intents Kit 的特点特点说明格式结构化 JSON 配置系统理解理解意图名称和参数参数传递结构化参数pageId, dishId搜索集成✅ 支持系统搜索可直达语义化强displayName keywords发现性高系统主动推荐三、两者最大的区别——系统理解层Deep Link 通常是应用自己解释 URL。系统只负责这个 URL 属于哪个应用不理解 URL 的含义。Intents Kit 则是先把能力描述给系统再由系统决定何时调起。Deep Link: 系统: 这个 URL 属于 foodvoyage 应用 应用: 我来解析 URL决定跳哪里 Intents Kit: 系统: foodvoyage 支持 JumpFunctionPage 意图有 search、explore 等页面 系统: 用户搜索了搜索匹配到 search 入口 系统: 调起 foodvoyage传入 pageIdsearch 应用: 收到 pageId跳转到搜索页关键差异Intents Kit 让系统参与了用户意图理解的过程而 Deep Link 只是传递一个地址。四、代码层面的差异Deep Link 的代码// Deep Link: 应用需要自己解析 URL void handleDeepLink(Uri uri) { if (uri.host dish) { final dishId uri.pathSegments.first; context.push(/dish/$dishId); } }应用需要自己解析 URL 结构容易出错。Intents Kit 的代码// Intents Kit: 系统已经解析好参数应用只需要路由 static void _navigate(_NavigationPayload payload) { final route _pageIdToRoute[payload.pageId]; if (route null) return; _router?.go(route); }系统已经把参数结构化了应用只需要根据pageId路由。五、Intents Kit 的 3 层优势优势Deep LinkIntents Kit搜索直达❌ 系统搜索找不到✅ 用户搜索关键词可直达语义化入口❌ URL 不表达意图✅ displayName keywords参数校验❌ 应用自己校验✅ 系统 执行器双重校验搜索直达是最关键的优势。在鸿蒙设备上用户可以在系统搜索框输入搜索美食系统会直接推荐你的应用入口。Deep Link 做不到这一点。语义化入口让系统能理解你的应用能做什么。displayName: 搜索美食keywords: [搜索, 找菜, 查菜]让系统知道这个入口和搜索相关。参数校验在执行器层完成非法参数在到达 Flutter 之前就被拦截了。六、什么时候用 Deep Link什么时候用 Intents Kit场景推荐方案原因应用内页面跳转Deep Link简单直接从其他应用跳转Deep Link通用性好系统搜索直达Intents KitDeep Link 做不到语义化入口Intents Kit系统能理解被系统推荐Intents Kit系统搜索集成需要参数校验Intents Kit执行器层校验食界探味选择 Intents Kit 的原因它需要被鸿蒙系统搜索理解和推荐。用户在鸿蒙搜索搜索时应该能看到搜索美食入口并直达。七、Intents Kit 的完整架构┌─────────────────────────────────────────────────┐ │ 鸿蒙系统层 │ │ │ │ 系统搜索 → 匹配 keywords/displayName │ │ → 找到 JumpFunctionPage 入口 │ │ → 调起应用传入 pageId │ └──────────────────────┬──────────────────────────┘ │ intentName params ▼ ┌─────────────────────────────────────────────────┐ │ 执行器层InsightIntentExecutorImpl │ │ │ │ 校验 pageId 合法性 │ │ 校验额外参数dishId │ │ → 调用插件 │ └──────────────────────┬──────────────────────────┘ │ pageId dishId ▼ ┌─────────────────────────────────────────────────┐ │ 插件层IntentNavigationPlugin │ │ │ │ channel 可用 → 推给 Flutter │ │ channel 不可用 → 暂存 pending │ └──────────────────────┬──────────────────────────┘ │ pageId dishId ▼ ┌─────────────────────────────────────────────────┐ │ Flutter 层intent_navigation_channel│ │ │ │ pageId → Flutter 路由映射 │ │ → 执行跳转 │ └─────────────────────────────────────────────────┘关键代码位置文件作用app/ohos/entry/src/main/resources/base/profile/insight_intent.json意图配置app/ohos/entry/src/main/ets/entryability/InsightIntentExecutorImpl.ets参数校验app/ohos/entry/src/main/ets/plugins/IntentNavigationPlugin.ets桥接 Flutterapp/lib/core/platform/intent_navigation_channel.dart路由跳转Deep Link vs Intents Kit 对比表维度Deep LinkIntents Kit本质URL 跳转结构化意图系统理解不理解只传递理解意图名称和参数搜索集成❌✅ 系统搜索可直达语义化弱强displayName keywords发现性低用户需知道 URL高系统主动推荐参数校验应用自己做执行器层校验适用场景应用内/应用间跳转系统搜索/语义入口实现复杂度低中需配置执行器鸿蒙特色通用方案鸿蒙平台能力常见坑把 Intents Kit 当成 URL 跳转替代品— 它的价值在系统理解不在跳转没有定义清楚 pageId 这类稳定参数— 页面语义和路由路径不能混原生侧不校验参数直接把任意值传给 Flutter— 需要白名单校验Flutter 路由命名和系统意图命名混在一起— pageId 是语义路由是实现keywords 覆盖不全— 用户搜索查菜时找不到入口没有处理 pending navigation— Flutter 未 ready 时入口丢失Deep Link 和 Intents Kit 混用没协调— 同一个入口不要两种方式都接可复用模板Intents Kit 配置模板{ insightIntents: [{ intentName: JumpToPage, domain: YourDomain, intentVersion: 1.0.0, srcEntry: ./ets/entryability/IntentExecutorImpl.ets, uiAbility: { ability: EntryAbility, executeMode: [foreground] }, inputParams: [{ properties: { pageId: { type: string, enum: [ { value: home, displayName: 首页, keywords: [首页, 主页, 推荐], displayDescription: 浏览推荐内容 } ] } } }] }] }选择决策模板选择 Deep Link 还是 Intents Kit 需要被系统搜索发现 → Intents Kit 需要语义化入口 → Intents Kit 需要系统推荐 → Intents Kit 只是应用内跳转 → Deep Link 从其他应用跳转 → Deep Link 需要通用性 → Deep Link本篇总结Intents Kit 和 Deep Link 的差别核心在系统是否理解你的入口Deep Link偏地址——系统只传递 URL应用自己解析Intents Kit做结构化意图——系统理解意图名称和参数在合适时机调起应用做鸿蒙系统入口时Intents Kit 更能体现平台能力搜索直达— 用户在系统搜索框输入关键词可直达语义化— displayName keywords 让系统理解入口含义参数校验— 执行器层拦截非法参数发现性— 系统主动推荐用户不需要知道 URL食界探味选择 Intents Kit是因为它需要被鸿蒙系统搜索理解和推荐。这不是另一种 Deep Link而是完全不同的入口模型。