我对表单验证非常严格。因此，在为当前项目中的申请表单创建“出生日期”（DOB）字段的验证器时（在这种情况下，平台/语言是中性的），我想要防止'淘气'输入。
我使用了一个日期选择器，并将最大日期限制为距离当前日期XX年。对于此场景来说，XX是有意义的，因为任何年龄小于此年龄的人都不应该申请该工作。
验证错误消息是：“您似乎太年轻了，无法申请此工作。”
然后我开始冒险。如何呢？
如果DOB早于120年前，则显示消息：“您不可能那么老!!!”
如果DOB在未来，则显示消息：“你一定在开玩笑，你还没有出生!!!”
最终，我没有部署最后两个，因为它们对我的认真客户来说太过俏皮。
我想知道，为了良好的可用性（或幽默），你们会走多远/多少来验证DOB字段，以及如“婚姻日期”，“毕业年份”等日期的情况。
另外：
我很惊讶大多数人对验证并不太关注。我在这里重复我的评论：
如果用户输入的日期错误（非常明显），无论是故意还是错误，验证器的目的之一就是捕捉它。当数据进入系统时，站点所有者只知道输入是错误的，他/她不会知道实际值而不询问用户。如果此字段非常重要，则情况将不会很好。
幽默是一件相当主观的事情，也非常依赖于项目，所以很难沿着这些方向回答。话虽如此，如果应用程序支持正式流程，例如申请工作，我可能会保守一些，保持相当客观。
至于验证，我认为你在这里付出的努力应该与无效数据从 UI 传递的影响成比例。回到求职申请表，我想在某个时候会有人工审核过程，因此无论数据是故意还是无意地输入不正确，无效数据的风险都很小。
如果您担心“叛逆”或机器人驱动的输入，请使用验证码。话虽如此，我认为您使用的验证规则相当安全。
嗯，我不是程序员（更像是业务分析师），但我正在努力获得一些开发技能，因为我认为这可能会帮助我成为一个更好的业务分析师。我做过一点VBA（别笑）。
无论如何，在考虑这个问题时，这是我的两分钱：
1）放弃幽默。现在对你来说有趣的东西对别人来说可能并不有趣。此外，经过两三次尝试后觉得有趣的东西，在进行了25或30次之后就不再有趣了，即使你面对的是一个爱开玩笑的人群！ 2）我开始认同这样的想法：除非你可以明确地验证某些东西是明显错误的，例如，你不想让某人输入小于0的值，否则你应该考虑通过警告而不是通过对话框或操作系统标准来进行预防。
嘿，我知道什么，一周后我会改变主意（我是业务分析师），然后要求开发人员立即回应 ;->
让我们在所有地方都使用两位数的年份。1999年之后，没有人会再使用我们的软件！
作为一个完美主义者，我会在这里去150：D
虽然机会很低，但人们已经通过了120，谁知道未来30年会发生什么:D
不过我觉得这并不是那么重要。
这完全取决于应用程序。订单处理的业务线（LOB）应用程序与跟踪历史或未来数据非常不同。
人们可以认为它需要是一个有效的日期，但要考虑到有多个日历（例如月份可以是13，年份可以超过5000）。
验证整数并提供帮助；我认为其他任何事情：滥用/大兄弟/过度工程化的系统都是一个坏主意。
如果人们愿意，应该允许他们在这些表格上撒谎；这不是法律问题，而是一个网站。
不要太认真了。
让用户选择日期。用户应该掌控，而不是系统/开发者。关于出生日期，您唯一需要避免的日期是未来日期，因为那是不正确的（即通过设计防止错误）。您提供的日期选择器应处理任何日期格式问题。
绝对不要弹出任何俏皮的异常/消息。您的消息应帮助用户识别和从错误中恢复。
希望这有所帮助。
