静态网站上的文件上传：你的真实选择

文本字段很简单--难题出现在需求文档写着"申请人应附上简历"的时候。静态网站无法接收文件；根本没有服务器来接收它。以下是从最差到最好的实际可选方案。

方案一："发邮件给我们"（投降方案）

让用户通过邮件发送附件。从技术上讲它能用，就像传真机能用一样：文件与表单数据脱节地抵达收件箱，没有结构，也没有大小控制。对于任何反复发生的场景--求职申请、支持工单附件、印刷文件--它会永远变成手动归档。

方案二：直传云存储（DIY 路线）

前端 JavaScript 可以直接上传到对象存储（S3 风格的预签名 URL）。这是一种合理的架构--但要安全地做好，工作量出乎意料地大：得有东西来生成这些预签名 URL（所以你终究还是得写一个无服务器函数），你要自己实现大小和类型校验，把上传的文件和它所属的表单提交关联起来，还要决定那个存储桶放在世界的哪个地方--一旦上传内容包含简历这类个人数据，这一点就至关重要。

当上传功能本身就是你的产品时，选这条路。而如果只是"给表单附加一个文件"，这就是一大堆管道工程。

方案三：通过表单后端进行 multipart 上传（枯燥但正确的方案）

HTML 支持文件字段差不多已经有永远那么久了：

大家最容易忘记的一点是 enctype="multipart/form-data"--没有它，浏览器发送的是文件名而不是文件本身。由表单后端接收 POST 请求时，文件会与其提交一起保存：在仪表盘中打开这条咨询，附件就在那里。大小和类型限制在端点处强制执行，垃圾信息防护也适用于整条提交，文件也不例外。

在 Formhook 中，文件上传功能从Pro 套餐起可用，而且--这一点对欧洲网站很重要--上传的文件存储在 Cloudflare R2 的欧盟区域，所以欧盟申请人附上的简历，其数据驻留答案与文本字段完全一致：它永远不会离开欧盟。（存储细节见文档。）

无论选哪个方案都适用的实用规则

1. 约束输入。把 accept 属性（accept=".pdf,.png,.jpg"）当作用户体验层面的提示来用，但要视其为建议性的--真正的校验发生在端点处。
2. 在用户碰到限制之前就告诉他们。字段旁边写上"最大 10 MB"，总好过一次缓慢上传之后才报错。
3. 文件也是个人数据。简历可以说比周围的表单字段更敏感。保留、删除和导出策略必须覆盖附件，隐私政策中关于存储位置的声明也必须把它们包含在内。（参见GDPR 合规清单。）
4. 保持无 JS 路径可用。一个纯粹的 multipart 表单不需要任何脚本也能正常提交；在此基础上添加 AJAX 打磨，而不是取而代之。

静态网站的模式已经很成熟：网站保持静态，表单后端接收 multipart POST 请求，文件落在它随附的消息旁边。表单依然只是一个属性--外加一个 enctype。