无服务器联系表单："serverless"在这里到底意味着什么

"Serverless"最初是一个精确的术语：您的代码以函数的形式运行在别人的基础设施上，您自己永远不需要配置、打补丁或扩展服务器。应用到联系表单上，这个术语的含义发生了偏移--如今它被用来指两种真正不同的方案，而您选择哪一种，决定了您要承担多少工作量。

下面是它们的区别，以及托管表单后端在其中的位置。

"无服务器联系表单"可能指的两件事

搜索这个短语，您会发现两种不同的答案混在一起：

• 您编写一个函数。一个 AWS Lambda、一个 Cloudflare Worker、一个 Vercel 或 Netlify 函数--一个您部署的小型处理程序，接收 POST 请求，通过 SES 或 Resend 之类的服务商发送邮件，并返回响应。
• 您完全不编写后端代码。您的表单直接向一个已经存在的托管服务发送 POST 请求--没有函数需要编写、部署或做版本管理。

从狭义上说，这两者都是"serverless"：都不涉及您需要 SSH 登录并打补丁的机器。但它们在工作量这条尺度上，落点相差很远。

方案 A：您自己的函数

编写自己的处理程序，让您对负载内容、邮件模板和存储去向拥有完全的控制权。这种控制权伴随着实实在在的责任：

• 冷启动。一个最近没有运行过的函数需要一点时间才能启动，在访问量较少的网站上，这会表现为第一次提交很慢。
• 邮件送达率由您负责。SPF、DKIM 和 DMARC 记录，需要维护的发信信誉，以及需要配置和监控的服务商账户。
• 垃圾信息过滤由您负责。除非您自己搭建速率限制、蜜罐字段或 CAPTCHA 验证，否则没有任何东西能阻止机器人直接向您函数的 URL 发送 POST 请求。
• 如果您想要任何历史记录，存储也由您负责。如果函数内部没有调用数据库，一条邮件发送失败的提交就直接消失了。

当表单会触发真正的业务逻辑时--写入 CRM、启动某个工作流，或任何超出"把消息送到人手里"的事情--这是正确的取舍。而对于一个普通的联系表单来说，这是大量需要您自己承担的、没有差异化价值的基础设施工作。

方案 B：完全不写后端代码

对"serverless"的另一种理解，是把函数这一环完全跳过。您的 <form> 直接向一个已经存在、由别人运营的端点发送 POST 请求，接收、垃圾信息过滤、通知和存储都已经搭建好并正在运行。您不写任何后端代码，也不部署任何东西--没有您自己的函数需要冷启动、打补丁或监控，因为这里根本就没有您自己的函数。

这里的取舍是控制权：您得到的是服务商的垃圾信息过滤器、服务商的保留政策、服务商的通知渠道--而不是您自己定制的逻辑。对于一个全部工作就是"可靠地把提交内容送到我这里"的表单来说，这几乎从来都算不上真正的代价。

哪一种真正适合联系表单

大多数联系表单并不需要定制的工作流逻辑--它们需要的只是可靠地送达某个人，而不会中途丢失或被误判为垃圾信息。如果这就是全部工作，那么编写并维护一个函数，其实是在解决一个您根本没有的问题：您会把真实的时间花在 SPF 记录和速率限制逻辑上，去重新发明一个托管后端早已实现的东西。当表单要驱动的不只是一个收件箱时--比如写入数据库、启动付费工作流、通用服务无法表达的多步骤流程--再去选择自己的函数。（关于表单后端日常究竟做了什么，更完整的图景见什么是表单后端。）

Formhook：那个已经存在的端点

Formhook 就是第二种 serverless。把表单指向 https://formhook.app/f/{apiKey}，就没有任何东西需要部署、冷启动或打补丁--连一个函数都不需要。垃圾信息过滤（蜜罐字段、速率限制，以及默认开启的 Cloudflare Turnstile）、存储、可搜索的仪表盘，以及通知--邮件加上所有套餐（包括免费版）都提供的 Web 推送--在您写下第一行代码之前就已经在运行了。出站 webhook 支持自动识别 Discord、Slack 和 Teams，覆盖了您确实想把提交内容交给另一个系统的场景，而且同样不需要您自己编写那个接收函数。

免费套餐每月可处理 250 次提交，无需信用卡。Pro 套餐增加了最高 10MB 的文件上传和带回复地址的已验证发信域名；Studio 套餐把上限提高到每月 25,000 次提交，适合团队使用。集成方式请见文档，完整明细见定价页面。