格式要求应在输入前而非提交后给出
别名: 事前格式提示 · error prevention format · 提交后才报格式
概念解释
日期怎么写、密码要几种字符、编号中间有没有横线，这些约束如果只在点了提交之后才第一次出现，人已经按错误模型写完了整串。输入前约束（pre-input format constraint）要求规则在动手之前就能被看见，让第一次按键就朝合法形状走。它管的是规则出现的时刻，不是规则该用例子还是用抽象句子，也不是提示要不要在出错后还留着。
机制
人会先形成一份「这类格子该长什么样」的假设，再按假设一口气写完。提交后的红字是在假设已经执行完才来推翻它：整串作废，工作记忆里的内容被清空，还要再读一条刚才看不见的规则。事前可见的约束把假设的生成前移，按键被规则形状吸引（几段、要不要符号），错误被挡在组装阶段。这是预防，不是更漂亮的报错。延迟到提交还有一层社交代价：公开场合填表时，错误横幅等于当众宣布失败，人会匆忙改、或放弃。
怎么研究
同一格式分别在「提交后才告知」「聚焦时告知」「渲染时就告知」三种时机下填写，记录第一次提交的合法率、重写整串的次数、完成时间。自变量：约束复杂度、是否允许粘贴、用户是否见过该格式。因变量：首申合法、规则首次被读到的时间点（可用眼动）。经典的错误预防实验逻辑在这里仍然适用：把信息放到动作之前，比把同一句话放到失败之后更能减少返工。不要把即时校验的成功算成事前提示的成功——校验仍是事后，只是事后来得更早。
边界
人人都熟的格式（本国手机号）即使事后告知，首申合法率也高，事前提示的增量小。约束本身会随地区、账户策略变，写在输入前的句子必须跟着变，否则事前提示会指导出一套过期规则。安全问题（密码不能与旧密码相同）有的规则在输入前无法诚实给出，因为答案依赖服务器上的秘密；这类约束只能事后说，不要假装事前能预防。超长规则清单会把动手时间往后推，事前提示变成一份读不完的说明书。
怎么落地
- 在字段旁、动手之前写出必须遵守的格式，不要把第一次告知留给提交按钮之后的红字。
- 把「提交后才知道」的规则逐条搬到对应槽的事前位置，而不是在页顶堆一条总错误。
- 对确实只能事后判定的规则（与旧值冲突、服务端唯一性），在事前写清「这一条要等提交才能确认」，避免用户以为事前清单已经穷尽。
- 验证：禁止看提交后的错误，只凭事前文案填一页。首申合法率仍低，就说明规则还藏在失败态里。