复杂度规则需在输入前展示
别名: 密码规则前置 · composition policy visibility · 密码要求说明
概念解释
密码框若在提交后才说「必须含大写、数字与符号」，人已经按自己的策略想好一串，再被规则打回。在输入前展示指焦点进入字段时（或更早）就能看见将要执行的约束，并且输入过程中只标记尚未满足的项，而不是事后用一句「不符合要求」概括。这条管规则的可见时机，不管规则本身是否过严，也不管能不能粘贴。
机制
设密是一次规划：人从记忆里取出或从管理器里生成候选，再对照规则裁剪。规则后置把规划变成试错：每失败一次就改候选，工作记忆里的秘密被反复改写，最后留下的往往是「在原串末尾加 1!」这种可预测补丁。前置展示让规则成为规划输入，而不是审判。实时勾选（长度已够、尚未含数字）把约束从一段法律文本变成可逐项完成的清单，减少「到底差哪一条」的猜测。若规则写在远离字段的帮助链接里，等于没有前置——人在字段上时看不见。
怎么研究
比较「提交后才报规则」「焦点时列出规则」「逐项实时满足标记」，看尝试次数与最终密码的结构。
自变量：规则首次出现的时机、是否逐条勾选、失败文案是总括还是指出未满足项。 因变量：提交前失败次数、在末尾追加字符的比例、完成时长、能否在不提交的情况下复述全部规则。
实验室常给假账号，人会用符合规则的固定测试串，测不到规划被打断。要用对方自己的密码策略（或管理器生成）才看得出后置规则的补丁行为。不要把实时标记的「更快完成」直接读成更强密码——速度和秘密结构要分开看。NIST SP 800-63B 讨论的是该不该设组合规则；即便产品仍保留规则，可见性仍是独立变量。
边界
密码管理器生成并填入时，人可能根本不看规则；前置清单对这些人价值低，但失败时仍需指出是哪一条与生成器策略冲突（例如禁止某些符号）。极短的「至少 8 位」一条规则，用占位符重复一遍即可，不必做成仪表盘。登录框不是设密框：登录失败不应展示注册时的复杂度清单，那会给旁观者额外信息。屏幕阅读器用户需要规则与字段用可访问描述关联，只靠字段下方变绿的图标不够。
怎么落地
- 在密码字段获得焦点时展示将执行的全部约束，逐条列出；输入过程中把已满足项勾掉，提交时只高亮仍未满足的项。
- 规则文本与校验器同源，禁止帮助中心与前端校验各写一套。
- 登录页不要复述设密规则；设密与重置页使用同一份前置清单。
- 验证：让未参与设计的人在不提交的情况下说出所有规则；再故意违反其中一条后提交，看反馈是否指向那一条而不是「密码不符合要求」。录屏统计有多少人在第一次提交前改了候选串——前置成功应让多数规划发生在首次提交前。