form-field--invalid必须挂到字段级容器（如<div class="form-field">）上，不可作用于input或form元素；它作为唯一JS主动控制的修饰符，驱动label、message、icon等关联样式，且与form-field--valid互斥。
不能把 --invalid 加在 input 上，也不能同时用 --invalid 和 --valid；必须挂到字段容器上，且只用一个主动状态类。
form-field--invalid 该挂在哪一层？
必须挂在字段级容器（div）上，比如 <div class="form-field">。这个容器要包裹 label、input、错误文案等所有相关节点。
- 挂错位置的典型错误：
input.form-field__input--invalid—— 这样无法控制 label 颜色或错误消息显隐 - 更糟的是挂到
form根元素上：form--invalid—— 一个邮箱输错，整张表单变红，用户根本找不到问题字段 - 正确结构示例：
<div class="form-field form-field--invalid"><label>邮箱</label><input><div class="form-field__message">格式错误</div></div>
为什么不能同时定义 form-field--invalid 和 form-field--valid？
验证状态是互斥的，但 --valid 容易引发语义误判和视觉混乱。
- 用户刚输入合法邮箱，JS 立刻加
form-field--valid，可此时密码还没填、手机号为空——业务上它根本不“有效” - 空
required字段初始是:valid，若靠form-field--valid控制绿色边框，会导致未输入就显示成功态 - 正确做法：只保留
form-field--invalid作为 JS 主动控制的唯一状态信号；初始态、已输入态靠form-field--touched或:not(:placeholder-shown)区分
多个验证规则共存时，修饰符怎么命名才不爆炸？
别堆砌 --required --email --max-len，BEM 修饰符不是日志，而是契约。
立即学习“前端免费学习笔记（深入）”；
- 每个字段同一时刻对外只暴露一个状态：
form-field--invalid就够了，具体错误类型由form-field__message的文本内容承载 - 若需区分前端/后端错误来源，可用
form-field--invalid-server，但这是例外，不是默认策略 - 禁止写
form-field__input--error：Element（__input）不能带 Modifier（--error），违反 BEM 原则，也破坏复用性
修饰符命名本身有哪些硬约束？
类名必须符合 BEM 基础语法，否则选择器失效、JS 查不到元素，直接报 Cannot read property 'classList' of null。
- Modifier 只能作用于 Block 或 Element 本身，不能“跨层”：✅
form-field--invalid，❌form--field-invalid或form-field__input--invalid - 值必须小写 + 连字符分隔，禁用驼峰、下划线、大小混写：
form-field--user-invalid✅，form-field--UserInvalid❌ - 不表达样式细节：
form-field--red-border是错的；form-field--invalid才对——边框颜色由 CSS 决定，不是类名职责
真正容易被忽略的是：修饰符不是“加完就完”，它必须和 JS 校验函数返回值严格对齐——isValid 为 false 时加类，为 true 或 undefined 时移除，中间不能有缓存、延迟或条件遗漏。否则 UI 状态和校验逻辑就会脱钩。
