1个表单库死过1次后，我砍掉了90%的API

2年前写的代码几乎没人用，最近重新打开仓库才发现：问题不在技术，在思路。

这是开发者 Kadir 的真实经历。他的 React 表单库第一次发布时彻底失败，第二次却换了个完全不同的方向——不是加功能，而是砍到只剩一行配置。

表单库的通病：越强大，越累人

React 生态不缺表单工具。从 Formik 到 React Hook Form，每个都标榜"强大""灵活"。

但 Kadir 发现，每次写表单他都在重复同样的机械劳动：注册字段、绑验证规则、处理错误状态、同步提交逻辑。即便用了 React Hook Form，"心智负担依然存在"。

他的观察很直接：大多数场景下，开发者不需要更多能力，需要更少阻力。

解法：把整个表单变成一段数据

第二次尝试，Kadir 换了个极端思路——放弃手动控制每个输入框，改用纯数据描述表单结构。

代码长这样：

没有 useForm 钩子，没有 register 函数，没有手动错误处理。字段、选项、联动条件全部塞进一个数组。

这种"配置即表单"的模式，本质上是在用声明式接口替代命令式编码。Kadir 的目标很明确："让表单愚蠢地简单"。

为什么这次可能不一样

第一次失败的核心原因，Kadir 归结为"方法错了"——当时可能也在追求功能完整性，却忽略了真实使用场景。

这次重构的取舍很激进：砍掉所有非必要 API，只保留最常见的 80% 场景。动态显示条件用对象描述，而非函数；验证规则内联，而非外置 schema。

这不是技术突破，是产品定位的修正。从"能做多少"转向"能省多少步"。

目前项目处于验证阶段，代码已开源在 GitHub（kadirulislam/ki-forms），npm 包同名。Kadir 自己也承认："我还在验证这个想法。"

一个值得注意的信号

这个案例的有趣之处，在于它踩中了前端工具的一个周期性趋势。

2015-2018 年，Redux 式的"显式控制一切"是主流；2019 年后，React Query、Zustand 等"约定优于配置"的方案崛起。表单领域也在经历类似轮回——从 Formik 的精细控制，到 React Hook Form 的精简，再到 KiForm 这种极端声明式。

Kadir 的两次尝试，恰好落在这个曲线的两端。第一次失败在"过度工程"，第二次赌的是"过度简化"能否成立。

他的判断依据很务实：日常开发中，表单逻辑高度同质化，重复编码的收益极低。如果能把常见模式固化成配置，省下的不只是代码量，是每次上下文切换的认知成本。

这个赌注能否成立，取决于两个变量：一是配置语法能否覆盖足够多的真实场景而不变得臃肿，二是社区是否愿意让渡一部分灵活性换取开发速度。

目前 KiForm 的 API 设计显示，Kadir 在刻意抵抗"功能蔓延"的诱惑。问题是，这种极简主义是表单工具的终局，还是又一个轮回的起点。