Conform：用 Web 标准渐进增强 HTML 表单的类型安全库

表单是 Web 上最古老也最容易写糟的交互。过去主流做法是用 React 受控组件把每个输入值塞进 state，再在前端手写校验——但这既破坏了无 JS 可用的渐进增强，又让类型与校验规则容易脱节。Conform 走了另一条路：不接管你的标记，而是在原生 HTML Form 之上做类型安全的校验增强。本文基于其官方文档 conform.guide 与 GitHub 仓库梳理。

一、背景：受控表单的代价

React 生态里的表单库大多建立在”受控组件”之上：每敲一个字符都触发 re-render，状态在前端集中管理。这在单页应用里很顺，但当你用 Remix、Next.js App Router 这类以服务端为中心、强调渐进增强的框架时，就会出现割裂——表单本该直接 POST 给服务端，却被前端 state 截胡。Conform 的作者 Edmund Hung 正是 Remix 生态出身，它的设计明显带着”让表单回到 Web 标准”的取向。

二、是什么：一个 type-safe 的表单校验层

Conform 官方定位：一个类型安全的表单校验库，利用 Web 基础技术渐进增强 HTML 表单，并完整支持 Remix、Next.js 等服务端框架。它通过 useForm() hook 暴露表单状态，但不限制你的标记——可以和任何合法的 HTML 表单一起用。官方当前版本为 1.21.1，MIT 协议。

它的核心卖点（官方文档列得很清楚）：

• 渐进增强优先的 API：无 JS 时表单仍能正常提交；
• 类型安全的字段推断（field inference）：schema 定下来，字段名与类型自动推导；
• 细粒度订阅（fine-grained subscription）：只订阅需要更新的字段，避免整表重渲染；
• 内建可访问性助手：自动处理 aria 属性、错误关联；
• 配合 Zod 自动做类型强制转换（type coercion）。

三、技术机制：FormData + Schema + 服务端复用

Conform 的关键是同一份校验逻辑在客户端与服务端复用。表单值通过浏览器原生的 FormData Web API 从 DOM 采集，再通过事件委托同步到 React 状态——而不是每个输入都受控。

在服务端（Next.js Server Action 或 Remix action）里，用 parseWithZod(formData, schema) 一次性完成解析、类型转换与校验，得到一个 submission 对象。官方文档代码展示了典型写法：

从截图可见：服务端先 await request.formData()，再 parseWithZod 校验；若 submission.status !== 'success'，就 return submission.reply() 把错误回传客户端；登录失败时还能通过 submission.reply({ formErrors: [...] }) 追加业务错误；成功后 redirect('/dashboard')。同一份 Zod schema 在前后端各跑一次，客户端即时反馈、服务端做最终可信校验。

四、Schema 集成：Zod、Valibot 与 Standard Schema

和主流受控表单库放在一起，Conform 的路线分歧就更清楚。React Hook Form 也主张”少用受控 state”，靠 ref 从 DOM 取值来减渲染，但它的校验与提交逻辑仍主要跑在浏览器端，服务端往往还要再写一遍。Formik 则是典型的”全受控 + 前端集中 state”，成熟、资料多，但与渐进增强几乎不兼容。Conform 的独特之处是把校验的真相源（schema）和提交的终点（服务端 action）统一起来：前端的即时校验不是另写一套，而是同一份 Zod 在客户端的快速副本；一旦 JS 失效或被禁用，表单照样 POST 到那个服务端 action，用的还是同一份校验。这种”客户端快、服务端准、且两者永不漂移”的模型，是它相比 RHF/Formik 真正的差异化，而不只是又一个 useForm。代价也随之而来：你得接受”校验以服务端那次为准”，客户端提示只是锦上添花，不能把它当成最终防线——这恰恰是渐进增强思路下应有的安全观。

五、优势与局限

优势：

1. 渐进增强：表单不依赖 JS 也能提交，对可访问性与弱网友好；
2. 前后端同一份 schema：Zod/Valibot 定义一次，客户端与服务端复用，杜绝两端校验不一致；
3. 不绑定标记：不强迫你用特定组件库，原生 <input> 即可；
4. 细粒度订阅 + 可访问性助手：性能与 a11y 都有内建考虑。

局限（需客观看待）：

1. 本质是 React 库：虽然主打”Web 基础”，但 @conform-to/react 说明它仍绑定 React，并非框架无关的 Vanilla 方案；
2. 渐进增强有学习成本：要正确实现无 JS 可用的服务端 action、错误回传（submission.reply），比写纯受控表单多一层心智模型；
3. 强依赖 schema 生态：类型推导与自动类型转换的红利主要在你用 Zod/Valibot 时才拿得到；
4. “细粒度订阅更快”是设计取向而非公开 benchmark：官方未给出与 React Hook Form 的量化对比数字。

六、谁该用

• Next.js App Router / Remix 项目：Conform 与 Server Action、action 函数天然契合；
• 重视渐进增强与可访问性的表单：登录、注册、付款等关键流程；
• 已经在用 Zod/Valibot 的团队：schema 复用几乎零成本；
• 纯客户端、无服务端表单处理的项目：渐进增强的优势用不上，受控表单库可能更简单。

参考来源

• Conform 官方文档
• Conform GitHub 仓库 edmundhung/conform
• Koala 项目库条目：Conform