form-field--invalid 必须挂在字段级容器（如 ）上，以同步控制边框、label、错误文案和图标；挂 input、form 根元素或复用型元素均为错误做法。
直接挂 form-field--invalid 在字段容器上，别碰 input 元素本身——这是唯一能同步控制边框、label、错误文案和图标的可靠方式。
form-field--invalid 该挂在哪一层？
必须挂在字段级容器（如 <div class="form-field">）上。常见错误包括：
<ul>
<li>加在 <code>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 权重失控，改一个可能意外影响另一个
- 把校验逻辑泄漏到类名里，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 切换）都必须依赖它驱动，而不是分散在多个元素上各自响应不同状态。
