我重写了我的加密表单工具，因为我厌倦了 Cloudflare 掌控我的设置

Source: Dev.to

概览

formseal-embed 是一个即插即用的客户端加密联系表单工具。你把它嵌入页面后，它会在浏览器中对提交内容进行加密，然后再发送，后端收到的就是密文，能够自行决定何时解密。

最初的版本能够工作，但它像纸牌屋一样脆弱：每次我动手都要想到 Cloudflare（KV、Workers、challenge/verify 流程）。上游的一个配置改动，就会让下游的所有功能悄然失效。于是我重新开始，不断自问：这东西该放在这里吗，还是我只是在重建我讨厌的东西？

唯一的真实约束

我给自己定了一个规则：工具必须能够与任何接受 POST 请求的端点配合使用。不能对后端做任何假设，不能依赖特定厂商的钩子，不能有“针对 X 优化”。只要有 URL，就能工作。

听起来很简单，却改变了一切。嵌入代码不能使用巧妙的后端技巧，CLI 也不能假设特定平台，每个功能都必须通过同一个测试：这会破坏厂商无关性吗？ 许多想法因此被淘汰。

嵌入代码的功能比你预期的要少——有意为之

我最初的直觉是让嵌入代码变得聪明：字段级别验证、自定义错误信息、自动生成 markup。但这些决定应该由使用该工具的开发者来做，而不是工具本身。

于是我把它简化了。formseal-embed：

• 读取 name 属性，
• 管理按钮状态，
• 加密负载，
• 发送 POST 请求。

仅此而已。HTML 由你全权掌控。虽然听起来有点受限，但这确保了 formseal-embed 能兼容你已有的任何表单结构。

为什么 CLI 用 Python 而不是 Rust 或 Go

我考虑过 Rust（快速、单二进制、无运行时）和 Go，但总是想到用户第一次在自己的机器上运行 fse init 时，机器上已经装好的东西。

Python 几乎必定存在，无需编译步骤，几乎没有摩擦。对于一个设置类 CLI，这种取舍是合理的：工具应该让位，而不是成为负担。

即将推出：fse doctor

在测试过程中，我屡次遇到一个小的错误配置导致所有东西悄然失效——错误的端点、无效的公钥等。调试过程非常痛苦。

fse doctor 将在 fse init 之后运行，检查整个配置：配置文件、端点可达性、公钥有效性、schema 字段等。它会精准指出哪里出错以及该运行哪个命令来修复。虽然尚未正式发布，但已经在开发中，感觉它本该从第一天就存在。

我一直在抵制的东西

这次重写中最难的并不是加密或 CLI 结构，而是抵制添加功能的冲动。每一个看似合理的新增都会把工具推向对后端、平台或验证逻辑的强制约束。

厂商无关性不是可以随意添加的功能，而是通过对许多合理想法说 不 来强制的约束。

来看看吧

npm 上的包名是 @formseal/embed。源码在 。

如果你对 fse doctor 应该检查哪些内容、CLI 还缺少哪些功能，或只是想研究加密流水线，欢迎提交 issue 和 PR。我很想听听大家认为在表单上线前值得验证的点。

你是否遇到过第三方表单工具导致的厂商锁定问题？是绕过去还是直接接受并继续？我真的很好奇。