Capsule: 将应用打包为单文件文档

Show HN: Capsule – Single-file web apps that save their data into SQLite

▲ 304bashtian121 HN 评论区
Capsule: 将应用打包为单文件文档

Capsule 颠覆了传统应用分发模式，将 UI、数据和逻辑封装进一个便携的 .capsule 文件中。无需云端、无需账号，用户只需像分享 PDF 一样通过 WhatsApp 或 AirDrop 发送文件，接收方点击即可立即运行。内置 SQLite 数据库确保所有数据本地存储，支持完全离线使用，彻底告别服务器依赖和供应商锁定。无论是任务追踪器还是个人笔记，Capsule 让应用像文档一样自由流动，且完全跨平台运行。

如果应用仅仅是一个文档会怎样？忘掉云端账号、服务器和订阅，Capsule 将你的界面、媒体和本地数据库打包成单个文件，像发送 PDF 一样分享，点击即开，数据完全归属自己。
阅读原文 →HN 评论区RSS

HN 评论区

121
  1. mg

    > 但尝试保存数据需要找个地方托管它

    如今借助 File System Access API，网页可以像桌面应用一样读写本地文件：

    https://developer.chrome.com/docs/capabilities/web-apis/file...

    试试这个文本编辑器：

    https://googlechromelabs.github.io/text-editor/

    它在桌面端和移动端都能很好地运行。

  2. nater5000

    我不太确定，这似乎是一个在特定场景下可行的想法，却被过度泛化到了原本逻辑不再成立的程度。

    如果用户需要下载一个特定的应用来运行这些 Web 应用，那为什么不直接一开始就发送那个初始应用呢？既然最终都能到达同一个终点，为什么还要绕弯子去用 Capsule？

    如果这是一个近乎普遍采用的应用，那倒还说得通。但事实并非如此，而我们最接近这种普及度的东西就是浏览器……而浏览器本身就已经实现了你所描述的功能？

    将数据与应用打包在一起在某些情况下确实合理，但适用的场景非常狭窄。如果我愿意随 Web 应用一起分发数据，那我完全可以直接把数据嵌入 HTML 文件中。如果预期用户会修改这些数据，那我就不认为应该以这种方式分发。

  3. thederf

    我一直在实现这个完全相同的想法，使用 sqlar 作为“格式规范”。它可以在浏览器中运行，并通过 Tauri 在桌面端和 Android 上运行。

    https://github.com/JoshTheDerf/uapp

    演示应用和游戏：https://thederf.com/uapp/demo/

  4. jawns

    我的观点是：如果你的应用需要更新并保留状态（使用 SQLite 或任何其他数据库），那么它可能不适合以打包文件的形式传递。

    或者至少，与如今并不困难的“托管在网络上”相比，这种方式极其受限。

    想想这个工作流程：每次状态发生变化，你都需要将新的 Capsule 文件发送给所有其他使用该应用的人。而且你应该认为状态至少会偶尔发生变化，否则使用数据库的理由就不充分了。

    或者，你可以直接将其托管在网络上，数据库状态动态更新，任何拥有应用访问权限的人都能自动获取。这难道不是简单得多吗？

  5. eleventen

    你可以通过 Chromium 浏览器 + Filesystem API 以及一个 PWA manifest 来获得这种体验的低成本近似版，从而获得那种类似原生的感觉。AI 重新点燃了我基于 100% 浏览器原生功能进行构建的兴趣。

    https://developer.mozilla.org/en-US/docs/Web/API/File_System...

  6. razerbeans

    我喜欢这个想法！我观察到 AI 广泛采用带来的一个后果是：它们非常擅长生成视觉元素，但如果你需要在这些元素中提供数据，除了硬编码之外，你并没有很好的方式来分享它。

    > 这种方法的一个缺点是，多人协作会产生不同的副本。为了使合并同一文件的不同副本成为可能，每个数据条目都有一个唯一的 UUID 和时间戳。

    这是我脑海中浮现的第一个问题：来自两个来源的更改以及它们的协调。我看到你有一段关于如何处理来自不同来源的数据条目的说明，但我没看到具体是如何协调的？例如，如果两个用户各自拥有一份 .capsule 副本并进行了修改，然后想将更改分享给对方，那么你就有了两个包含不同数据的独立 .capsule 文件。

    你该如何合并它们？

  7. andix

    我真的很喜欢这个想法。现在用 AI 创建小工具非常容易，但将它们安装为本地应用或分享却很困难。

    不过我觉得还缺少一些相关功能：

    1. 在设备之间同步数据和应用（capsules）。不一定非要通过单一的 SaaS，也许是 P2P 或某些现有服务。

    2. 我认为数据和应用程序应该分开，我可能只想与他人分享应用而不分享数据。

    3. 应用应支持更新，再次安装同一个应用时只需替换现有应用的代码，但保留数据。同时，更新既可以作为文件分享，也可以发布到仓库（仅仅是公共 HTTP 服务器上的一个文件文件夹或 GitHub 仓库）。

    我知道，在设备间保持数据同步并提供离线能力是很困难的。

  8. m-p-3

    这有点让我想起 MS Access，它最终成了 IT 部门的噩梦，但也确实满足了一些资源有限部门的需求。

    非常好奇这个方向会走向何方。你计划开源客户端，还是仅仅在规范稳定后公开文件格式规范？

同日更多故事

2026-09-15