BEM修饰符应作用于字段级块（如form-field）而非整个form，用form-field--invalid等单一语义修饰符统一控制状态，避免叠加、强耦合及语义错乱，并同步更新aria属性与错误文案显隐。
怎么用BEM修饰符表示表单字段的验证状态
直接加 is-valid 或 is-invalid 这类修饰符最稳妥，前提是你的 BEM 命名根元素是字段级块（比如 form-field），而不是整个 form。很多人误把状态挂到 form 上，结果一个字段出错，整表单变红——这既不符合语义，也干扰用户定位问题。
常见错误现象：form__input--error 看似合理，但一旦输入框被复用在非表单场景（比如搜索框），这个修饰符就语义错乱；更糟的是，它和校验逻辑强耦合，JS 里得反复操作 class 名字符串。
- 推荐结构：
<div class="form-field form-field--invalid"><input class="form-field__input"><span class="form-field__message">邮箱格式不对</span></div> - 修饰符作用在容器上，样式可统一控制子元素（
.form-field--invalid .form-field__input边框变红，.form-field--invalid .form-field__message显示） - 避免用
js-前缀修饰符做状态，比如form-field--js-invalid——CSS 不该依赖 JS 的实现细节
为什么不能只靠 :valid/:invalid 伪类做状态反馈
浏览器原生 :valid/:invalid 只响应 checkValidity() 和用户交互后的“脏状态”（touched），没输过内容的必填字段初始就是 :valid，哪怕它是空的。用户点提交才触发校验，但视觉反馈必须提前跟上。
使用场景：登录页邮箱字段，用户还没输任何字符，此时 :invalid 不生效，但设计要求“空状态显示浅灰边框+提示文字”，这就必须靠 JS 主动加修饰符。
立即学习“前端免费学习笔记（深入）”；
-
:invalid在input[type="email"]值非法时才触发，但空值不触发（除非加required且字段已获焦） - 移动端 Safari 对
:user-invalid支持差，别指望它替代 JS 控制 - 性能影响小，但逻辑不可靠——状态必须由校验函数返回值驱动，不是 CSS 自己猜
多个验证规则共存时，修饰符怎么命名才不打架
别堆砌 --invalid --required --email，CSS 选择器权重会失控，维护时改一个状态可能意外影响另一个。用单一、语义明确的状态修饰符，背后由 JS 统一决策最终状态。
例如邮箱字段同时要校验“非空”“格式正确”“域名白名单”，JS 校验函数返回 "empty" / "format" / "domain"，再映射为 form-field--empty / form-field--format ——但更推荐全收归为 form-field--invalid，错误文案由 form-field__message 内容决定，而非 class 名。
- 错误做法：
form-field--required form-field--email form-field--max-length（状态叠加，无法表达优先级） - 正确做法：JS 校验后只设一个修饰符，如
form-field--invalid，并更新data-error-type="format"供 CSS 或 JS 读取 - 兼容性注意：IE11 不支持
data-*属性选择器，若需兼容，可用form-field--invalid-format这种带上下文的修饰符，但最多两层（--invalid+--format），别嵌套
动态切换状态时，class 操作容易漏掉哪些环节
只增删修饰符不够，还得同步处理 aria-invalid、aria-describedby 和错误文案的显隐。否则屏幕阅读器看不到变化，或者旧错误信息残留。
典型坑：用户输错后提示“密码太短”，接着输对了，JS 移除了 form-field--invalid，但忘了清空 aria-describedby，导致辅助技术仍读出已隐藏的错误 ID。
- 每次状态变更必须同步三件事：
element.classList.toggle("form-field--invalid")、element.setAttribute("aria-invalid", "true/false")、element.setAttribute("aria-describedby", "msg-id / null") - 错误文案容器（
form-field__message）建议始终存在 DOM 中，用display: none控制显隐，别用innerHTML = ""清空——避免重排和焦点丢失 - 如果用
requestAnimationFrame批量更新多个字段状态，注意 class 切换和 ARIA 属性必须在同一帧完成，否则辅助技术可能读到中间态
复杂点在于状态来源不止用户输入：可能是异步校验（如用户名是否已被注册）、表单级联动（选了“其他”才显示文本框）、甚至服务端返回的字段级错误。这些都得收敛到同一套修饰符更新逻辑里，不能让每个校验分支各自操作 class。
