验证失败时应使用bem修饰符form__field--error，而非通用类error；状态类必须绑定具体块、用--连接、避免布尔前缀，按字段类型细化如form__field--email--invalid-format，并协同:invalid伪类分层控制样式。
验证失败时 class 名怎么起才不和业务类冲突
直接加 error 或 invalid 这种通用名，很容易被全局样式污染，或者和 JS 框架自动生成的类撞车。BEM 要求状态类必须绑定到具体块或元素上，比如表单域是 form__field，那失败态就该是 form__field--error，而不是单独一个 error。
常见错误是写成：<input class="form__field error">——这等于把状态“抽离”了，后续维护时根本看不出这个 error 是属于 field 还是 label 还是整个 form。
- 状态类必须带双连字符
--，且紧贴它所修饰的块/元素名，如form__label--error - 避免用
is-error或has-error：这类布尔前缀在 BEM 中属于反模式，BEM 的--modifier本身已表达状态语义 - 如果需要支持多状态叠加（比如既 invalid 又 disabled），顺序按语义优先级排：
form__field--error--disabled，而非反过来
如何让 :invalid 伪类和 BEM 状态类协同工作
CSS 原生 :invalid 在表单控件失去焦点或提交时才触发，且无法控制具体错误类型（比如邮箱格式错 vs 必填未填）。而 BEM 状态类由 JS 主动添加，可控性高，两者不该互斥，而是分层使用：
-
:invalid仅用于最轻量的视觉反馈（如边框变红），不承担业务逻辑 - JS 校验后，根据错误类型添加对应 BEM 状态类，如
form__field--email-format-invalid或form__field--required-missing - 确保 CSS 优先级：BEM 类的样式要能覆盖
:invalid，否则状态类可能失效；建议统一用单个类选择器，别嵌套
示例：
.form__field:invalid {
border-color: #f00;
}
.form__field--email-format-invalid {
border-color: #d32f2f;
background-image: url("data:image/svg+xml,%3Csvg...%3E");
}
为什么不要把验证样式写死在 --error 里
form__field--error 听起来很省事，但实际项目中，“错误”的表现往往因字段而异：密码字段要显示强度条，邮箱字段要加图标，下拉框可能只变文字颜色。硬塞进一个通用 --error 类，后期必然要加 !important 或覆盖规则，破坏 BEM 的可预测性。
- 按字段类型定义状态类：
form__field--password--weak、form__field--email--invalid-format - 共性样式抽到基础类：
form__field统一定义边框过渡、字体大小等，状态类只负责“变化部分” - 如果真需要统一兜底行为（比如所有错误字段都抖动），用 JS 控制
form__field--shaking这类瞬态类，而非绑定在验证逻辑里
JS 添加状态类时最容易漏掉的三个时机
只在表单提交时加 --error 类，用户会卡在输入环节毫无反馈。BEM 状态要跟输入节奏走：
- blur 时校验当前字段并设状态类（防用户跳过）
- input 事件做防抖校验（针对邮箱、手机号等格式敏感字段）
- submit 失败后，对所有错误字段批量补状态类（防止用户改完一个就点提交，其他仍无提示）
注意：不要在 focus 时清空 --error 类——用户还没输完，清除了反而造成困惑。应在 input 或 blur 后重新校验再决定是否移除。
真正难的不是写对一个 --error，而是让每个字段的状态类既能独立表达含义，又不会在 DOM 上堆出一长串难以调试的 class 名。BEM 不是命名规范，是状态可见性的约束机制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
