bem类名是自动化测试最可靠的dom定位锚点，因其语义化、作用域明确且规避标签选择器误匹配、文本动态变化、computedstyle不稳定等问题；但需防范构建哈希、modifier单独使用及后代选择器退化等失效场景。
BEM 类名是自动化测试中 DOM 定位最可靠的锚点，不是因为它“看起来规范”，而是因为它的结构天然规避了常见定位失效场景——只要类名写对、没被构建工具意外改写，cy.get('.search-form__submit') 就只会命中那个提交按钮，不会误选弹窗关闭按钮、表格操作项，或第三方组件里同名的 button 元素。
为什么 cy.get('button') 在真实项目里基本不可用
标签选择器等于放弃控制权：button 会匹配页面上所有 <button></button>，包括 Ant Design 的 Button、自定义封装的 <mybutton></mybutton> 渲染出的底层 button，甚至被 v-show 隐藏但仍在 DOM 中的按钮。
-
button[type="submit"]依然可能跨表单误命中，无法区分“搜索表单提交”和“注册表单提交” -
cy.contains('提交')依赖可见文本，但按钮文字常动态变化（“提交中…”、“重试”），或被 i18n 替换，定位立刻断裂 - 浏览器渲染层不保证元素顺序或层级唯一性，仅靠标签名无法建立稳定映射
为什么 classList.contains('button--disabled') 比 getComputedStyle 更可靠
运行时验证修饰符是否生效，classList.contains('button--disabled') 是确定性判断；而 getComputedStyle(el).opacity 会因多种原因返回非预期值：
- 浏览器可能压缩声明值（如
opacity: 0.5→opacity: .5），正则匹配易失败 - CSS 变量未被 JS 设置时，
getComputedStyle返回空字符串或默认值，和真实渲染不一致 - 继承、层叠、媒体查询激活状态都会干扰 computedStyle 的稳定性，CI 中复现率低
哪些 BEM 类名在测试中实际会“消失”或失效
不是所有带双下划线的类名都适合当 locator。以下情况会让测试脚本找不到目标：
- 构建后 CSS Modules 或 CSS-in-JS 自动哈希类名（如
search-form__submit_abc123），但测试仍写原始名——需确保测试环境启用localsConvention: 'camelCaseOnly'并使用styles['search-form__submit']导出，或统一用data-test属性兜底 - Modifier 被错误地单独使用：
cy.get('.button--disabled')失败，因为真实 DOM 是<button class="button button--disabled"></button>，BEM 要求 modifier 必须与 block 同时存在 - 写了
.modal--open .modal__content这种含空格的选择器，退化为后代选择器，破坏 BEM 的作用域隔离，PostCSS 插件应拦截这类写法
真正难测的不是单个类名，而是 modifier 组合互斥性——比如 button--disabled 和 is-loading 同时加在元素上时，样式是否按预期覆盖。这需要显式构造多状态组合断言，而不是只测单一 modifier。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
