文本框（Text fields），也常被称作输入框，广泛存在于各种界面中。Material Design对其的解释是：“文本框允许用户在界面中输入和编辑文本，经常出现在表单和对话框中。”那么，当用户在文本框内的输入内容不符合文本框设定的校验要求时（比如，输入字数超过限定字数），就会出现报错提示。前段时间刚完成一个面向B端用户招商的项目，根据项目要求，交互方案中出现了大量供用户填写的文本框。结合项目过程中的一些思考，本文将对文本框的校验机制和报错提示进行比较和总结。
举个例子：一个文本框的最大限制字数为10字。当用户输入的文本超出了10字，需要出现报错提示。我们依次来看一下可能的方案，各方案的示例如下图所示。
方案1：采用失焦校验的方式，报错提示为“超出限定字数”。
的确是起到了报错的作用，但是其提示文案却不够清晰。用户看完后，仍然不知道这个输入框到底可以输入几个字。
方案2：采用失焦校验的方式，报错提示为“超出限定字数10字”。
看似是解决了方案1存在的问题。因为这句提示既指出了报错原因，又告知了解决方案。
然而，这句文案却存在着歧义：限定字数是10字？还是现在已经超出限定字数10字？对于10字这种数量不多的情况，用户在比照着输入框内现有的字数后，还可以较快地辨别。但是，在允许输入较多字数的文本框中，辨别的难度就增大了很多。比如，当用户看到“超出限定字数200字”这句提示时，就很难辨别出是限定字数为200字，还是在限定字数的基础上超出了200字。
方案3：采用失焦校验的方式，报错提示“最多可输入10字”。
解决了方案1中存在的问题，而且不像方案2那样存在歧义。是一个可行的解决方案。
方案4：采用输入校验（oninput，输入过程中就实时地进行校验）的方式，始终在输入框下方显示当前的输入字数与限定字数。
这个方案能实时地反馈给用户现在已经输入了多少字，还可以输入多少字，或者是超出了多少字。相比于失焦校验，输入校验能让用户在输入的过程中就获得及时的反馈，而非输入完成后。因此，在当前的例子下，方案4也是一个可行的解决方案。
说到输入校验，最为大家所熟知的形式应该就是Twitter的推文输入框和微博的博文输入框了。由于推特和微博都会对单条博文进行字数限制，因此，采用输入校验的方式，让用户实时地知道已输入字数以及还能输入的字数，是再合适不过的了。如下图所示，Twitter在字数未超长时模糊提示，接近超长时则通过输入校验的方式精确提示剩余可输入字数，在已经超长时提示已超出字数并将其高亮显示，方便用户分成多条发送。
另外，输入校验还可以被运用于点评的场景中，一方面是通过输入校验做字数限制，另一方面还可以通过输入校验来鼓励用户适当地多写一点。下图中的截图来源于驴妈妈旅游的点评页面，通过输入校验与提示文案的配合，鼓励用户产出更优质的点评内容。
那么，输入校验的方式是否存在着一些问题呢？当然存在。比如，对于某些需要服务器验证的内容，这种校验方式会加大服务器的压力。举个例子：一个文本框，需要进行敏感词校验。如果采用输入校验的方式，服务端需要在数据库中查询敏感词，然后与用户输入的文本进行对比，每一次查询可能需要较多的时间。如果大量且连续地查询服务器，可能造成服务器无法响应的问题。这时，失焦后都不会出现报错提示，更别说实时地出现报错提示了。
另外，输入校验也不适合于某些唯一性的文本校验。比如，在一般情况下，用户名都要求是唯一的，那就适合用失焦校验的方式：当用户输入完毕并移出光标后，再判断并提示是否已经被别人使用。如果这种情况下使用输入校验来校验其唯一性，用户在输入的过程中，就可能会被不断弹出的报错提示弄得十分烦恼。
综上所述，总结如下：
1、当文本框出现报错提示时，不仅要告诉用户出现了什么问题，还要告诉用户如何解决这个问题；
2、报错提示文案需简洁易懂，避免使用具有歧义的提示文案；
3、输入校验在微型博客和点评的场景下比较适合。在点评的文本框中，恰当地使用输入校验能起到激励用户的效果；
4、对于需要服务器验证的内容，或某些唯一性的文本校验，则不适合使用输入校验，而适合采用失焦校验。
（在写这篇文章的过程中，向前端组的同事请教了很多问题。感谢前端组同事们的耐心解答。）
参考
Text fields - Material Design, https://material.io/design/components/text-fields.html
文章修订记录
1、2018年11月12日：增加了图5（对文本唯一性的校验）以及文末的参考。
2、2018年12月4日：将标题由“关于文本框报错提示的思考”改为了“文本框的校验机制与报错提示”；增加了图3（Twitter对推文的字数校验）以辅助说明；将图4（驴妈妈旅游网的点评模块）改大了一点，以便于在移动端阅读时也能看得清；将图5（对文本唯一性的校验）进行了更新和替换。
