用户填错不是异常，而是表单的正常路径。一个只在提交后显示“存在 3 个错误”的页面，把定位和修正成本全部交给用户。好的校验会明确指出字段、原因和修正方法，并让用户在修正后顺利回到任务。
01 错误提示至少要回答三个问题：哪里、什么问题、怎么改
“格式错误”“无效输入”只回答了一半。更具体的提示如“手机号应为 11 位数字，不包含空格”能直接指导修正。
如果规则复杂，可以在输入前就给说明，例如密码要求，而不是用户提交后才突然公布规则。
02 校验时机不要过早，也不要全部等到最后
用户刚在邮箱框输入一个字母就出现红色“邮箱格式错误”，会制造不必要压力，因为他还没输入完。
常见策略是在字段失焦后校验格式，提交时统一检查必填和跨字段规则。已经显示错误的字段可以在修正后及时反馈成功。
03 字段级错误要靠近输入框，并与控件建立程序关联
视觉上把红字放在输入框下面是第一步。W3C 表单教程还强调清晰标签、说明和错误关联，让屏幕阅读器用户同样能理解。
不要只把输入框边框变红，也不要依赖 Placeholder 充当 Label，因为输入后提示会消失。
04 长表单可以同时提供顶部错误汇总
一个 30 项企业申请表提交后有 6 个错误，只靠字段旁红字，用户可能不知道下面还有问题。顶部可以显示错误数量和可点击列表，帮助快速跳转。
汇总不能取代字段级提示。最好两者同时存在：顶部负责定位，字段附近负责修正。
05 错误文案不要责备用户
“你输入了错误的地址”可以改成“请输入有效邮箱地址”。产品只需要描述需要什么，不需要判断用户能力。
系统错误和用户输入错误也应区分。“服务器暂时无法提交”不能写成“请检查输入”，否则用户会反复修改正确数据。
06 服务器返回的技术错误要翻译成用户语言
API 返回 422、duplicate_key、permission_denied 对开发有意义，对用户没有。界面应映射为“该邮箱已注册”“你没有权限修改此项目”等可行动信息。
同时保留错误追踪 ID 或日志给客服和工程排查，但不要让技术码成为主文案。
07 修正后不要让用户重新填写已经正确的内容
表单提交失败后整页刷新、所有字段清空，是非常严重的恢复问题。除密码或安全敏感字段外，应该尽量保留用户已输入内容。
如果错误发生在上传文件，也要清楚说明是否需要重新上传，避免用户以为文件仍然存在。
08 表单 QA 必须主动制造错误场景
只测试一次“全部填写正确并提交成功”远远不够。要测试必填为空、格式错误、重复值、网络失败、超时、权限变化、服务器异常和移动键盘。
表单体验的质量，往往不是顺利时看出来的，而是在出错后用户是否仍然知道怎么完成。
09 错误状态也要考虑国际化和格式差异
日期、手机号、邮编和姓名格式在不同国家差异明显。把中国手机号规则复制到海外站，或者强制姓名必须包含两个字，会造成合法输入被拒绝。
表单规则应由目标市场和真实业务需求决定，错误文案也需要本地化，而不是只翻译“Invalid format”。
10 不要自动修正到用户不知道发生了什么
系统可以去掉手机号空格、把邮箱转小写等低风险标准化，但如果自动修改地址、金额或日期含义，就应该让用户看到变化。
输入辅助的目标是减少错误，不是悄悄替用户做重要决定。
11 复杂错误可以提供保留数据的人工恢复路径
企业长表单提交遇到服务器故障时，可以生成草稿、临时保存或提供客服编号，避免用户重新填写半小时。
高成本任务的错误恢复能力往往比“成功页多漂亮”更影响用户对系统可靠性的判断。
常见问题
表单应该实时校验吗？
部分规则适合实时或失焦校验，但不要在用户尚未输入完成时过早报错。
错误提示要放顶部还是字段下面？
短表单字段级即可，长表单可增加顶部汇总，同时保留字段附近具体提示。
Placeholder 可以代替 Label 吗？
不建议。Placeholder 输入后消失，也不适合作为稳定可访问标签。
错误一定要用红色吗？
可以使用语义色，但不能只靠颜色，应配合文字和其他视觉提示。
服务器错误怎么提示？
说明系统暂时无法完成以及用户可采取的下一步，不要把技术状态码直接展示为主要信息。
相关服务与进一步咨询
链接复制成功
