Show HN：Capsule——把数据存进 SQLite 的单文件 Web 应用
文章摘要
Capsule 的出发点是作者 bashtian 在 Show HN 自述里讲的一个具体困扰：现在做一个 HTML 页面已经极其简单，但一旦需要保存数据，就得找地方托管；托管之后想分享给别人，又是一道麻烦。他花了几个月，用 Rust 加 Tauri 2.0 写了 Capsule——.capsule 既是应用名也是文件扩展名——把一个 HTML 应用和它的数据一起打包进单个 SQLite 文件。
技术设计上有几个要点：
- HTML 文件和相关资源直接嵌在数据库里。 用户数据可以走两条路，一条是 localStorage 式的键值存储，另一条是受 MongoDB 启发的 collections 文档 API，存在文件内的一张表里。PDF、图片等资产也能一并塞进数据库，让整个「文档」保持完整。所有数据都能导出成 CSV 或 JSON。
- 权限模型是默认封闭的。 文档开箱即用时什么都做不了：没有文件系统访问权，联网需要显式授权。作者说权限模型仍在改进中。Capsule 文档可以调用本地或远程 AI 模型来实现文档内的 AI 功能。
- 合并机制。 作者主动点出了这个方案最大的缺点：多人协作会产生不同的副本。为了让同一文件的多份拷贝能合并，每条数据都带唯一 UUID 和时间戳。
- 格式开放计划。 他打算在 1.0 版开放文件格式规范，让其他应用也能读写 Capsule 文件。当前版本间有迁移机制，承诺升级不丢数据。
官网把定位表述为「像文档一样运行的应用」：把 UI、媒体资源和本地数据库打成一个可移植文件，像 PDF 或 Word 文档那样通过 WhatsApp、AirDrop 或邮件发出去，对方点开即用、数据预装就位；完全离线，无需账号和网络。跨平台方面，同一个文件在 macOS、Windows、Linux 上都能打开，iOS 和 Android 支持标注为「即将推出」。宿主播放器免费下载，Web 版可用于快速预览但不能直接读写本地文件。官网还主推一条 AI 生成路径：把准备好的一份 prompt 说明地址丢给 ChatGPT、Claude 或 Gemini，让它生成为 Capsule 优化的应用，再通过对话或 MCP 工具持续迭代。
HN 评论精华
这条 Show HN 拿到 377 分，讨论集中在三个问题上：这是给谁的、需不需要装宿主 App、以及为什么不直接用 Web。
关于「这是什么的现代版」，评论区给出了一串谱系。 gadders：「我有 Lotus Notes 的闪回。」p2detar 顺势做了一个很有分量的技术批评：Lotus Notes 的设计与数据是分开存储的，还有数据库模板——你可以更新设计而不破坏数据，甚至用完全不同的设计去配现有数据模型；而 Capsule 把设计本身存进了数据库，这一点他觉得别扭。另一些人给的类比是 MS Access（「数据管理在 Excel 里做得难受」正是作者自己给出的目标场景）、TiddlyWiki（单文件自包含 wiki），以及 fdeth 的一句总结：「所以就是再做一遍 Visual Basic，只不过这次配 LLM 和 Web 技术。」
关于要不要装宿主 App，是本帖最实质的争论。 lewisjoe 直接问：这要求用户先装一个能读 .capsule 的宿主应用，不会成为分发的阻力吗？既然大多数电脑本来就有跑 HTML/CSS 的能力，HTML 不是更好的分发机制？作者的回答是核心论点：问题在于你没法让单个 HTML 文件像 Word 或 Excel 文档那样保存用户数据，「你想想，Excel 表格本身也就是 UI 加数据装在一个文件里」。
这个回答引出了一整段关于浏览器能力边界的技术讨论：
- yoz 给出了最完整的现状说明：File System Access API 确实能做到，甚至在本地
file:///HTML 里也能用，但目前只有桌面 Chromium 系支持；退而求其次，任何浏览器都允许你把页面自身的新版本下载下来覆盖旧文件——哪怕是从本地 HTML 页面发起也行——但这需要用户为每一次更新手动操作一遍，「于是我们又回到了手动『保存』按钮」。 - Dwedit 补充了另一个方向的退化：浏览器正在系统性地阉割本地 HTML 文件运行有意义 JS 的能力，「想加载同目录下的一个 JS 文件？CORS 错误」，而这正是那些「为了跑不到 1MB 的 Web 代码而打包整个 Chromium 的 200MB 应用」的成因。他提了一个有意思的折中方案：浏览器可以只允许「纯本地」或「纯联网」二选一，在第一次请求发生后再决定——从网上取了张图，就不给本地文件脚本权限；从硬盘别处取了个 JS，就不给联网权限。throw101010 的反驳也很到位：这难道不正是相对良好的沙箱体验的代价吗？同样的项目一旦没了这些限制，很容易就变成极易传播的恶意软件。
- eleventen 提出了竞争方案：Chromium 系浏览器加 File System API 加 PWA manifest 就能得到一个廉价近似，还有种原生感。他自己后来又给 Capsule 说了句公道话：「Filesystem API 很别扭，UX 相当糟糕。不那么老练的用户大概会更喜欢专用工具的体验。我自己为了标准和零安装宁愿忍受更差的 UX，但很多人会反过来选。我觉得 Capsule 本来就不是给 HN 这群人做的。」al_borland 则把顾虑说得最直白：Web 原生的话任何人都能直接用，Capsule 则要先下载 App 来关联扩展名，「这感觉像个很大的门槛，几乎像 Java 运行时」。
关于「为什么不直接托管在网上」，出现了本帖最热闹的一场价值观交锋。 jawns 的立论是：如果你的应用需要更新并保存状态，那它大概就不该作为打包文件到处传——每次状态变化你都得把新文件邮件发给所有使用者，而托管在网上状态自动更新、有权限的人自动可见，「这不是简单得多吗？」
反驳分几路：
- latexr 认为这忽略了托管的经常性成本、麻烦程度和保护数据的负担，并提醒对方「我付得起所以人人都付得起」这种思路应该停止；他也指出对方把「一个笔记应用不能全设备同步就只是个文本编辑器」当成普适判断，「建议你多观察一下普通人」。
- benhurmarcel 给了最具体的一条使用场景：在企业环境里，员工基本不可能自己在任何地方托管一个应用，所以一个完全本地运行、能直接发给同事的应用确实有用。
- bithammerthunde 对「现在托管到网上不难」这句给了一个简短有力的回应：「你去跟任何一个非技术人员说说看。」有人反驳说 Netlify Drop 这种拖拽部署非技术人员也能搞定，他回了句「我问了我妈，她说的话我打出来评论会被折叠」。
- lateatdesk 提出了一个把「副本会分叉」从缺点翻转成优点的场景：我可以把一份行程发给别人，对方改日期、砍掉一半站点、加上自己的笔记，不需要谁再发一版更新回来。dizzard 的划线也很清楚：如果 capsule 是一份食谱，很酷；如果是一个食谱管理器，就会变乱。
其他值得记的点：
- razerbeans 指出了一个 AI 时代特有的痛点，也正好是 Capsule 的机会：LLM 很擅长生成视觉产物，但一旦需要在产物里承载数据，除了硬编码就没什么好办法把它分享出去。他追问合并具体怎么做，作者答：每条文档记录带 UUID 和时间戳，删除时数据移除但保留 tombstone，冲突目前取最新的一条，将来会做一个让用户确认取哪一份的合并界面。
- 安全性被多人提到。tamimio：「投毒新姿势出现了！想法很好，但肯定会被滥用。」作者回应 HTML 没有任何文件系统权限，理想状态下整个应用会跑在沙箱里，移动端本来就默认如此。redog 问能否在运行前检查文件内容。另有两位用户报告 macOS 下载的 Capsule.app 提示「已损坏」无法打开——这在一个以「随手传文件」为卖点的产品上是个尴尬的信号。
- 反 AI 的一条支线。 xd1936 只留了一句「『No cloud. No accounts. Just share it.』——关标签页」。被追问后 al_borland 代为解释：整个东西读起来像是 vibe coding 出来的，除了 AI 吐出来的之外没做任何额外工作。
- thesurlydev 给出了本帖最被认同的一条趋势判断：「在 AI 与人的能动性之争正酣的当下，我预测 local-first 桌面应用会回潮。」rglover 接着怀念 2009–2010 年那种高质量、平台原生、一次付费即可永久使用的软件形态，认为 SaaS 转型「摧毁了软件质量」。krapp 的收尾则是本帖最悲观的一句：令人沮丧的是，所有人都认定 Electron 是应用的终极形态、原生应用已死，直到 AI 出现；而如果原生应用真的回来了，它回来的形式将只是 vibe coding 出来的 slop——「我们不过是从地狱的一层挪到了另一层」。
- thederf 在评论区亮出了几乎同题的项目：他用 sqlar 作为格式规范做了同样的事，浏览器、桌面和 Android（也是 Tauri）都能跑。olaulailadila 则贡献了本帖最好的玩笑：「一个杀手级功能的点子：让作者把 capsule 暴露到互联网上，用户在 App 里输入这个 capsule 的名字（就叫它地址吧），程序就把它拉到用户设备上。」下面立刻有人接「听起来很有革命性」、「我们可以管它叫 PWA：Probably Web Again」、「不如叫 web，像蜘蛛网一样互相连着」。