表单校验状态必须挂载在字段级 block 容器（如 form-field）上，而非 input 或 form；挂错位置会导致视觉不同步、JS 操作分散、无障碍属性难维护；应统一用 form-field--invalid 表示校验失败，禁用多修饰符和 form-field--valid。
表单校验状态该挂哪个 DOM 节点上
必须挂到字段级 block 容器上，比如 form-field 或 field-email，而不是 form__input、input 或整个 form。挂错位置会导致三类问题：视觉反馈无法精准同步（label 颜色、input 边框、error 文案显隐不同步），JS 操作分散易漏（得分别 toggle 多个 class），无障碍属性（如 aria-invalid、aria-describedby）难以统一维护。
常见错误现象：
-
form__input--error—— 把修饰符加在 input 上，样式只能作用于自身，无法控制 label 和 error 元素 -
form--invalid—— 一个邮箱字段出错，整张表单变红，用户找不到具体错在哪 - 用
input的:invalid伪类直接驱动样式 —— 空必填字段初始不触发，iOS Safari 对:user-invalid支持极差
修饰符命名要不要区分空值、格式错、后端冲突
不要堆砌 field-email--empty--format--domain 这类多修饰符。CSS 权重会失控，JS 切换逻辑爆炸，aria-describedby 指向难同步，且违背 BEM “单一语义状态”原则。
推荐做法是只用一个语义明确的修饰符：
立即学习“前端免费学习笔记（深入）”；
- 统一用
form-field--invalid表示“当前字段未通过校验” - 错误文案内容由
form-field__message的innerText决定，不是靠 class 名区分 - 若需差异化提示（如空值 vs 域名白名单失败），JS 动态更新
aria-describedby指向不同id，而非靠 class 控制样式 - 禁用
form-field--js-invalid这类带实现细节的修饰符 —— CSS 不该知道校验是正则还是 API 返回
为什么不能同时用 form-field--valid 和 form-field--invalid
验证状态本质是三态：未校验、无效、有效。但 form-field--valid 极易引发语义误判和交互错乱。
典型问题：
- 用户刚输完合法邮箱，JS 立即加
form-field--valid，边框变绿；但提交时后端返回“用户名已存在”，又切回红 —— 视觉信任崩塌 - 空字段在未获焦前显示绿色边框，违背“未输入即未校验”的直觉
- 业务上“有效”常依赖多字段联动或后端确认，单字段的
valid并无实际意义
更稳妥的方案：
- 只保留
form-field--invalid作为主动反馈类，JS 校验返回false时添加，返回true或undefined时移除 - “已输入”状态用
form-field--touched（配合blur或input事件） - 初始态不依赖任何修饰符，靠默认样式或
.form-field__input:not(:placeholder-shown)区分
BEM 结构里 label 和 input 的 DOM 关系怎么对齐
再规范的类名，如果 HTML 结构没对齐，屏幕阅读器、:focus-within、自动化检测都会失效。
必须确保：
-
label和input在同一个字段容器内，例如：<div class="form-field"> <label class="form-field__label">邮箱</label> <input class="form-field__input" type="email"> <p class="form-field__message"></p> </div>
-
label必须用for属性或包裹input，确保语义绑定 - JS 更新
form-field--invalid时，同步设置input的aria-invalid="true"和aria-describedby指向form-field__message的id - 避免把
form-field__label和form-field__input拆到不同父容器下 —— 即使类名正确，focus-within也会失效
复杂点往往不在 class 怎么写，而在 label/input/error 是否真在同一个可语义化感知的上下文里 —— 这一步漏掉，所有 BEM 命名都只是视觉补丁。
