■ 基本概念
我们先把这个概念同步一下，这里讨论的“前端扩展”，不是泛指所有扩展能力，而是特指简道云自建插件中的前端扩展功能。
在这个能力里，一个大家比较容易理解的形态是页面弹窗：用户配置一个第三方页面链接，点击按钮后，简道云以弹窗的方式把这个页面打开。
这种方式当然能用，但它有一个很现实的前提：你必须先有一个第三方页面。
而在实际工作里，“先有一个第三方页面”通常并不只是做一个页面文件这么简单，它往往意味着：
- 先把页面开发出来
- 再部署到服务器
- 再拿到一个可访问链接
- 最后再把这个链接配置进简道云弹窗中
如果这个页面承担的是一个长期独立运行的业务系统，这样做很正常；但如果只是为了展示一张图、渲染一段说明、打开一个小工具、补一个输入窗口，这条链路就显得有些重了。
内嵌式微应用，正是为了解决这个“太重”的问题。
■ 效果示例
[点击这里查看视频演示]
■ 它是什么
本次所说的内嵌式微应用，不是“再做一个外部页面，再嵌进来”，而是直接在简道云的前端扩展脚本里部署页面代码，再把这个页面作为弹窗打开。
它的核心实现可以浓缩成下面这个最小示例。这个示例会直接在弹窗中打开一个带基础样式的页面，并在页面中央显示 HELLO WORLD：
示例代码： HELLO WORD 应用示例.txt (1.28 K)
本示例代码部署方式：
- 开放平台 > 自建插件 > 新增插件
- 新增函数 > 前端扩展 > 代码
- 粘贴代码 > 保存并调试 > 执行代码
这组代码的关键意义在于：
- 页面内容不是放在外部服务器上等待访问
- 页面内容是脚本在运行时直接生成的
- 弹窗打开的不是第三方链接，而是一个
data: URL 页面
也就是说，这里的“内嵌”，不是把现成网页接进来，而是在简道云当前使用场景里，现场生成一个页面，并立刻把它打开。
所以，更准确地说，内嵌式微应用是一种基于 dataUrl + $g.utils.openModal() 的轻量页面形态：它不依赖预先部署好的第三方页面，就可以在简道云当前界面中直接承载展示、输入、渲染和交互能力。
■ 它解决什么问题
很多轻量需求，并不是做不到，而是没必要，或者暂时做不起。
一种情况是，问题本身并不大。
它可能只是某个流程里的一块补充信息、一个临时查看页、一个小型输入窗口，确实需要页面承载，但又没有大到值得专门开发一个独立页面、再部署、再维护的程度。
另一种情况是，需求本身也许有价值，但现实条件并不具备。
例如团队没有自己的服务器，没有现成的页面发布环境，不想为了一个轻量场景单独补一套部署链路，或者当前阶段就是希望先快速验证，而不是先做基础设施准备。
比如下面这些场景：
- 想在当前节点里打开一张订单趋势图
- 想把一段 Markdown 内容变成可阅读页面
- 想补一个一次性的填写与提交窗口
- 想临时加一个操作引导页或轻量交互页
- 想在业务现场就地打开一个智能助理
这些需求往往都有一个共同点：它们需要页面，但未必值得先做一个独立站点；有时是不值得投入这么多精力，有时是现实里根本没有这类部署条件。
内嵌式微应用的价值，就在于把这条较重的路径，收缩成一种更短的实现方式：直接在插件脚本里生成页面，再由弹窗承载它。
因此，它真正降低的，不只是开发量，更是部署门槛、接入成本和试错成本。
■ 它能做什么
从实际使用场景来看，内嵌式微应用最适合承载的，不是“大而全”的系统页面，而是围绕单一任务展开的小型页面能力。
常见形态通常包括：
▶ 1. 数据展示
例如在弹窗里直接打开一个订单看板、趋势图或统计图。
这类页面的重点通常不是复杂分析，而是围绕当前业务动作，让用户立刻看到结果。它可以接收数据、做基础整理、完成图表渲染，并提供少量必要交互，比如排序切换、刷新或尺寸自适应。
对很多业务场景来说，用户真正需要的并不是再去设计一套复杂的可视化看板，而是在当前动作里顺手打开一张足够清楚的图。
▶ 2. 内容渲染
例如把 Markdown 文本直接渲染成一个可阅读页面。
很多时候，系统里保存的是结构化文本，但用户需要的并不是原始内容，而是一个更易读、可复制、可浏览的阅读界面。对于这类场景，一个轻量页面就足以显著改善体验。
▶ 3. 互动页面
例如一个操作引导页、一个互动演示页，甚至一个小游戏式页面。
这类场景说明，内嵌式微应用不只是静态展示容器，也可以承载完整的交互逻辑、状态变化和局部反馈。这里的“微”，说的是接入方式和业务边界，而不是交互深度必须很浅。
▶ 4. 智能助理
例如在当前页面里就地打开一个智能助理。
它可以承担问答、解释、摘要、文本改写、上下文辅助判断等工作。它的价值不在于“多了一个聊天框”，而在于把智能能力嵌进了业务动作本身，而不是要求用户跳到另一个独立 AI 产品里处理。
▶ 5. 结果回写
这一类场景更准确的说法，不是“信息采集”，而是“在弹窗里完成一段个性化交互，再把结果回写给宿主页面”。
简道云本身就擅长做常规的信息采集，如果只是普通录入，很多时候根本不需要额外做一个内嵌式微应用。
它真正有意义的地方在于：当交互过程本身比较个性化，不适合直接用原始表单承载时，可以先在弹窗里完成这段交互，再把结果回传给当前页面，比如问卷式交互、引导式填写等。
■ 它的特征
虽然呈现形态不同，但这类微应用通常有几个共同点。
▶ 1. 目标明确
它通常只服务一个具体动作：
- 看一张图
- 读一段内容
- 做一次输入
- 完成一次交互
- 获得一次即时辅助
它解决的是“当前这一小步怎么完成”，而不是“整个系统怎么重做”。
▶ 2. 接入够轻
它的成立前提之一，就是不值得先走一轮完整的外部页面建设流程。
如果一个需求本来就只需要一个局部页面能力，那么“脚本内生成 HTML + Data URL 打开弹窗”这条路径，天然会比“先开发外部页面、再部署服务器、再配置链接”更轻。
▶ 3. 贴近现场
大多数内嵌式微应用，都不是为了脱离简道云独立存在，而是为了补齐某个按钮、某个节点、某个局部动作所需要的页面能力。它的价值在于贴近现场，而不是扩张成另一个系统入口。
■ 为什么值得重视
因为在企业数字化场景里，最常见的需求往往不是“再建一个系统”，而是“在现有流程里多补一块刚刚好的能力”。
比如：
- 某个按钮点开后，希望看到更直观的信息
- 某个流程节点里，希望多一个填写或确认面板
- 某段文本，希望变成更好的阅读体验
- 某个业务动作里，希望临时多一层智能辅助
- 某个轻量场景，希望快速试一个交互页面
这些需求如果全部按独立页面方案处理，成本经常偏高；但如果完全不做，业务体验又会长期停留在“能用，但不好用”的状态。
内嵌式微应用的意义，就在于它提供了一个非常实用的中间层：
- 不必上升到完整系统建设
- 不必先准备服务器和页面链接
- 但又不只是停留在原始表单能力上
它让很多原本“不值得单独建站”的需求，也有了可落地、可交付的实现方式。
■ 它的边界
内嵌式微应用很有价值，但它不是万能钥匙。既然它建立在前端扩展脚本直接生成页面、再通过 Data URL 打开的机制上，那么它天然就更适合承担：
而当需求开始走向另一种形态时，就要谨慎得多，比如：
- 强依赖复杂宿主通信
- 强依赖稳定的跨页面联动
- 必须可靠调用外部系统深层能力
- 长期演变成独立业务平台
- 权限、角色、流程、状态都明显复杂化
这时，它可能就已经超出了“微应用”的合理范围，更适合走独立页面或独立系统方案。
成熟的做法，不是把所有需求都塞进内嵌式微应用里，而是让它专注于自己最擅长的那一段：以尽可能低的接入成本，补齐一个具体场景中的小型页面能力。
■ 最后的定义
所以，这里所说的内嵌式微应用，本质并不是“给简道云配置一个第三方页面链接”，而是：在简道云自建插件的前端扩展中，直接使用脚本生成 HTML，并通过 dataUrl + $g.utils.openModal() 立即打开，从而在无需服务器部署第三方页面的前提下，快速补齐某个具体场景所需的小型页面能力。
它可以是图表看板，可以是内容阅读器，可以是轻量交互页，可以是智能助理，也可以是一次性输入与提交窗口。
这些能力单看都不庞大，但一旦被放在正确的业务节点上，就会立即显现价值：少一次建站，少一层部署，少一套链接管理，却多了一段真正可用的业务体验。
这就是内嵌式微应用最值得被重视的地方。
本文中部分概念仍在探索之中，不足之处敬请谅解，请以最终实现效果与官方信息为准；思路有多宽，路子就有多宽，打开思路，迎接更多可能。
■ 补充说明
内嵌式微应用 并非官方定义，只是为便于表达和讨论所使用的一个自定义名称。相关思路早期受到官方群内 石佳浩 案例分享的启发，后续在实践与整理中逐步形成本系列内容。
| 
