form-field--invalid 必须挂在字段级容器（如 ）上，以同步控制边框、label、错误文案和图标；挂 input、form 根元素或复用型元素均为错误做法。

直接挂 form-field--invalid 在字段容器上，别碰 input 元素本身——这是唯一能同步控制边框、label、错误文案和图标的可靠方式。

form-field--invalid 该挂在哪一层？

必须挂在字段级容器（如

）上。常见错误包括：

• 加在 input 上：比如 form__input--error，这会让样式只作用于输入框本身，无法联动 label 颜色或 form-field__message 显隐
• 加在 form 根元素上：导致“一个字段错，整表单红”，语义错乱、用户无法定位问题
• 加在复用型元素上：比如 search-input--error，该输入框若被挪到搜索框里，修饰符就失去上下文

正确结构示例：

<div class="form-field form-field--invalid">
  <label class="form-field__label">邮箱</label>
  <input class="form-field__input" type="email"><div class="form-field__message">请输入有效的邮箱地址</div>
</div>

为什么不能同时用 form-field--invalid 和 form-field--valid？

验证状态是互斥的，而 form-field--valid 极易引发语义误判：

• 用户刚输完合法邮箱，JS 立即加了 form-field--valid，但其他字段仍是空的——业务逻辑上它根本不“有效”
• 空字段未获焦前显示绿色边框（因 :valid 或 form-field--valid 生效），用户误以为已通过
• 提交后端校验失败又跳红，造成预期崩塌和信任错乱

推荐做法：只保留 form-field--invalid 作为 JS 主动控制的唯一反馈类；初始态靠 .form-field__input:not(:placeholder-shown) 或 form-field--touched 区分是否已输入。

多个规则共存时，修饰符怎么命名才不爆炸？

别堆砌 form-field--required--email--max-len 这类多修饰符：

CSS工具箱(专业版)

全功能 CSS 工程手册，覆盖性能优化、无障碍、设计系统与跨浏览器兼容。

下载

• CSS 权重失控，改一个可能意外影响另一个
• 把校验逻辑泄漏到类名里，JS 得反复拼字符串，维护成本指数上升
• BEM 修饰符不是日志，而是契约：一个字段同一时刻只暴露一个对外状态信号

统一用 form-field--invalid 表达“校验失败”，具体错误类型由 form-field__message 的文本内容决定。如需区分前端格式错 vs 后端冲突，可配合 data-error-type="backend-conflict" 属性，而非新增修饰符。

JS 怎么安全地添加/移除这个类？

操作必须干净、可预测、易调试：

• 校验函数返回 false 时添加：fieldEl.classList.add('form-field--invalid')
• 返回 true 或 undefined 时移除：fieldEl.classList.remove('form-field--invalid')
• 禁用 toggle 做“自动判断”，避免因返回值非布尔（如字符串、null）导致误判
• SSR 场景下，服务端渲染的 class 必须与客户端初始状态严格对齐，否则触发 FOUC 或 React Hydration mismatch

最易被忽略的是：form-field--invalid 是唯一需要 JS 主动干预的修饰符；所有视觉反馈（边框变红、label 变色、message 显隐、icon 切换）都必须依赖它驱动，而不是分散在多个元素上各自响应不同状态。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！