移动端H5用BEM核心优势是防宿主样式劫持、单类名匹配快、Computed面板3秒定位生效规则；因其block前缀（如user-card__title）天然不匹配宿主.text等全局样式，避免Android X5/iOS WebView下样式莫名失效，且单类名哈希查找高效，Computed中搜属性可直击真实生效规则。
移动端H5用BEM不是为了“看起来专业”，而是防止样式在Android X5或iOS WebView里突然失效——核心优势就三点：防宿主样式劫持、单类名匹配快、Computed面板里3秒定位真实生效规则。
为什么BEM能防WebView样式劫持
Android壳App或微信/支付宝WebView会向页面注入全局样式，比如.text { color: #666 !important; }。如果你写.title，它就会被覆盖；但user-card__title这种带明确block前缀的类名，天然不匹配宿主规则，样式不会“莫名变灰”。
- 宿主注入的
.btn无法命中checkout-form__submit-btn - iOS Safari对
:nth-child()解析弱，BEM单类名靠哈希查找一次命中，避免逐级回溯卡顿 - 多个H5复用同一WebView实例时，
home-banner__item和promo-banner__item互不干扰
为什么单类名选择器在移动端更可靠
BEM强制用user-card__avatar--loading这类单类名，浏览器直接查class哈希表；而.user-card .avatar会让引擎先遍历所有.avatar元素，再逐层往上找父级，DOM越深越慢——尤其低端安卓机上，滚动卡顿常源于此。
- 构建后可用
grep -r "\.[a-z]\+ \.[a-z]" dist/快速揪出残留的空格选择器 - Sass中写
.user-card { &__avatar { } }安全；但.user-card { & .user-card__badge { } }就编译出带空格的选择器，破坏隔离性 - DevTools → Elements → Computed → Styles面板里，有空格就是性能隐患
为什么Computed面板搜属性比Styles面板快得多
Styles面板展示的是所有匹配项，不是最终胜出的规则；Computed面板里搜font-size，带小箭头的那条才是实际生效的BEM规则，点击就能跳转源码。
立即学习“前端免费学习笔记（深入）”；
- 搜修饰符必须输全名：
input--disabled比搜disabled准，避免命中第三方库的.disabled - 按住Ctrl/Cmd再点击Styles里的任意属性值，能直接跳到该属性最终来源（含
@import路径） - 改了
user-card__avatar--loading的opacity没生效？大概率是另一条更晚加载或带!important的规则覆盖了它；搜opacity比检查拼写快得多
最常被忽略的是：BEM类名必须原样存在于DOM中。uni-app开了scoped、Taro启用了cssModules、埋点SDK清洗了class属性——这些都会让BEM彻底失效。验证方式很简单：打开WebView控制台Elements面板，确认class是user-card user-card--active这样的原样字符串，而不是空值、驼峰或带data-v-xxx的包裹形式。
