Flow-Like 是一个强类型的企业级工作流平台（Built for scalability, speed, seamless AI integration）。它的 Packages（包）机制允许你把**自定义节点（WASM Nodes）和自定义 UI 组件（Package Widgets）**打包成可复用的单元，在多个项目之间共享，或发布到包注册表（Package Registry）供他人安装。本文带你走通"开发 → 本地测试 → 打包 → 发布 → 安装使用"的完整闭环，并给出 15 种语言模板与官方示例的指引。

核心概念：节点、组件与包三者如何配合

在动手之前，先弄清三个角色：

包在三个层级上被管理：

1. 注册表（Registry）：发现与安装包，查看其能力声明；
2. 设备（Device）：本机已安装的包缓存，在Packages › Library中管理；
3. 应用（App）：每个 App 显式记录自己依赖的包与版本，做到"版本锁定、可追溯"。

这种分层让你可以本地迭代开发而不必每次都提交发布，也保证线上 App 始终使用经过验证的版本。

选择包模板：15 种语言与能力矩阵

仓库内置了覆盖两种运行时模型的模板（详见 templates/wasm-capability-matrix.md，它是模板能力一致性的唯一权威来源）：

• Component Model 模板（推荐用于新包，类型化绑定、按权限授予 WASI 网络）： wasm-node-rust、wasm-node-go、wasm-node-cpp、wasm-node-zig、wasm-node-csharp、wasm-node-swift、wasm-node-python、wasm-node-typescript
• Core Module 模板（兼容既有工具链）：wasm-node-assemblyscript、wasm-node-kotlin、wasm-node-nim、wasm-node-lua、wasm-node-java、wasm-node-grain、wasm-node-moonbit

UI 组件侧同样有整套前端框架模板：widget-vanilla、widget-react、widget-vue、widget-svelte、widget-solid、widget-preact、widget-lit。

💡选型建议：业务逻辑偏系统/数据处理选 Rust 或 Go；团队熟悉前端、想快速交付带 UI 的包选 TypeScript；需要连接企业 Java 生态可评估 core module 模板。不确定时，直接以 Rust 模板起步，它的 SDK 与文档最完整。

开发 WASM 自定义节点：五步跑通

1. 复制模板：在 Flow-Like Desktop 中进入Packages › Mine › New package选择语言模板，或手动复制templates/下对应目录；
2. 更换包 ID：把模板默认的com.example.反向域名 ID 改成你控制的名字（如com.你的团队.image-tools）。ID 规则：必须全局唯一（忽略大小写与结尾点号后仍不能重复），且一经发布不可变更；
3. 实现run：用模板 SDK 定义节点输入/输出引脚（Pin 支持 String、Integer、Float、Boolean、Struct、PathBuf 等类型，可为数组或哈希表），并实现执行逻辑；
4. 声明最小权限：每个节点在代码中声明它真正需要的能力——HTTP、WebSocket、TCP/UDP、DNS、存储读写、数据库、变量、缓存、模型调用等。沙箱按节点粒度授予权限，未声明的能力调用会直接失败，这也是商店页面"权限清单"的由来；
5. 运行测试与构建：执行模板自带的测试，然后Reload into catalog在本地目录中加载并验证节点。

清单文件flow-like.toml只描述节点代码无法表达的包级信息：

manifest_version = 2 id = "com.example.image-tools" version = "0.1.0" [permissions] memory = "standard" # 内存档位：16 MB ~ 4 GB timeout = "standard" # 超时档位：5 秒 ~ 30 分钟

WASM 节点运行在 Wasmtime 沙箱中，受 fuel、超时、内存与能力（capability）四重控制；同一份.wasm既能被桌面端加载，也能被托管执行器加载，天然跨环境。更多细节见 包清单说明 与 沙箱与权限。

开发 UI 组件：用类型化契约连接界面与工作流

包组件运行在不透明源（opaque origin）沙箱 iframe内，只能通过与宿主的类型化契约（flw/1）通信。契约在widget.config.ts中用defineWidget<Inputs, Events, Queries>声明，编译后自动生成工作流侧的类型化引脚：

• Inputs→ 变成Instantiate Widget/Update Widget Inputs节点的输入引脚（支持默认值、枚举下拉、JSON Schema 校验）；
• Events→ 用户点击/操作时发出，可触发工作流事件；
• Queries→ 工作流可通过Query Widget节点反向读取组件的实时状态。

一个典型开发循环：

# 1. 用 Vite 本地预览 bun run dev # 打开 http://localhost:5173/src/widgets/hello-widget/index.html # 2. 构建并打包为可发布产物 bun run build bunx @flow-like/widget-bundler validate . bunx @flow-like/widget-bundler pack --project . --out widgets.flwb bunx @flow-like/widget-bundler validate widgets.flwb

没有宿主时 SDK 自动降级：$props回落到契约默认值，emit()输出到浏览器控制台，可在 DevTools 里用window.__flw.query("getCount")调用查询。想要更接近真实环境的预览，运行bunx @flow-like/widget-bundler dev，可获得主题、视口控制与事件日志面板。

⚠️网络访问需申报：组件默认无法访问任何站点。若确需请求外部 API，请在widget.config.ts的csp中按用途声明域名（如 widget-react 模板 中的 weather-widget 示例），查看者会看到你的用途说明并逐项批准。始终声明最小域名集合。

打包与验证：官方 Sales Insights 示例

仓库内置了一个"节点 + 组件"混合的完整示例 examples/sales-insights/：3 个 Rust WASM 节点（生成演示数据、应用筛选、汇总）+ 2 个 React 组件（Sales Chart 图表、Filter Panel 筛选面板），完美演示组件三大交互模式：

完整演示流：用户在 Filter Panel 点击 Apply → 事件触发工作流 → 查询面板状态 → 节点过滤数据 → 更新图表；点击柱形图又反向查询 Top3 系列并回写标题。它展示了包组件如何与工作流形成双向数据闭环。

常用命令（基于 mise 编排，见 examples/sales-insights/mise.toml）：

mise run build # 产出 node.wasm + widgets.flwb mise run validate # 校验契约与打包产物 mise run test # Rust 节点单元测试 mise run dev # mock 宿主调试面板

测试清单：发布前必做的 4 件事

1. 包工作区 Test 标签页：在 Desktop 包工作区用自定义输入运行每个节点，检查Nodes标签页的 lint 结果；
2. 桌面端预览组件：Packages › Mine打开包 →Debug & test › Preview widgets，在真实宿主中检查输入、事件与查询；
3. 在代表性 Flow 中加载：把包加入一个真实 App 的依赖，跑通端到端场景；
4. 权限审计：移除未使用的权限声明，确认密钥未嵌入二进制或清单，文档中说明外部数据传输与预期成本。

发布与上架：从私有到公开审核

发布只能在Flow-Like Desktop完成（因为它基于本地包文件夹）。向导分三步：

1. 包信息：确认 ID 与版本号（会检查唯一性），核对名称、描述、许可证、链接、关键词；
2. 权限与资源：审查内存/超时档位与allowed_hosts（包级出站域名白名单）。注意：能力清单位于节点定义，由注册表从编译后的二进制中自动派生，清单里手写的权限标志会被覆盖；
3. 构建并提交：生成发布产物并上传。后端会对二进制做哈希、拒绝重复版本、提取节点定义。

几个关键治理规则：

• 📦新包默认私有：私有版本可立即对成员生效，适合团队内部先行使用；
• 🔍公开需走审核：在Listing标签页补齐图标、缩略图、描述、关键词后，"Request publication review" 进入pending_review状态，由持有ManagePackages权限的管理员审核；
• 🧊版本不可变：ID + 版本组合一经发布不可替换。发布新版本会创建新的版本记录，审核通过后才提升为活跃版本——未审核的更新不会悄悄改变线上行为；
• 🏷️状态流转：pending_review→active，也可能rejected/deprecated/yanked/disabled。Releases标签页是唯一的状态事实来源。

审核主要检查：二进制有效性、权限与实现是否匹配、节点契约自洽性、元数据准确性、外部访问是否合理、维护信息与许可证是否清晰（详见 注册表与治理文档）。

安装、链接与更新：让包真正被用起来

• 安装到设备：在Explore › Packages商店搜索并Install，包会下载到本地注册表缓存，出现在Packages › Library；
• 链接到 App：打开目标 App →Packages › Add Package→ 选择包与版本。安装与链接是两个独立动作——只有两者都完成，节点才会出现在 App 的节点目录中；
• 自动更新：在线 App 可为依赖开启自动更新，离线 App 则锁定显式版本。修改生产 App 的包版本前请先评估可用更新；
• 卸载前检查：确认哪些 App 链接了该包——移除本地副本可能让节点在本地编辑或执行时不可用。

常见问题速查：

下一步学习路径

从模板起步、最小权限声明、用官方 Sales Insights 示例校准预期，你的第一个可复用包就能在一天内跑通"开发—测试—发布"全流程 🚀。