表单校验要贴近用户输入过程

问题背景

这类问题常见于业务增长后的前端项目。页面还能跑，但新增需求越来越慢，问题定位越来越依赖个人记忆，最后所有人都怕改公共代码。

提交前一次性报错很省代码，但真实体验差；字段级校验和提交校验应该分层。 这篇文章更关心落地细节：怎么拆问题、怎么写代码或流程、怎么验收，而不是停在概念介绍。

真正耐用的前端方案通常不复杂，但边界会很清楚：哪些数据来自接口，哪些状态属于页面，哪些逻辑可以独立测试，哪些体验需要降级。

推荐做法

• 提交前一次性报错很省代码，但真实体验差；字段级校验和提交校验应该分层。
• 先把问题拆成数据、状态、视图、交互四个部分，不要一开始就改组件。
• 找到项目里已经稳定运行的相似实现，沿用命名、目录和错误处理风格。
• 给关键路径补最小可复现样例或测试，避免只靠刷新页面确认。

一个可直接借用的片段

export function moneyText(cents: number) {
  return (cents / 100).toLocaleString('zh-CN', { style: 'currency', currency: 'CNY' });
}

容易踩坑

• 只处理成功路径会让真实用户很痛苦。
• 不要忽略重复提交、网络中断和服务端拒绝。
• 不要把字段校验散落在多个组件里。

检查清单

1. 是否能说清楚这个改动解决的具体问题。
2. 是否有失败、空数据、慢网络或权限不足时的处理。
3. 是否留下了后续维护者能看懂的命名和边界。
4. 是否用命令、截图或真实页面验证过结果。

好的技术文章不只是告诉你“可以这么做”，还要说清楚什么时候不该这么做。前端工程 的很多经验，真正值钱的部分都在这些边界里。