BEM 能显著缩短移动端 H5 的 CSS 调试时间，关键在于“查得快”：在 Chrome DevTools 的 Computed 标签页搜属性（如 font-size）可直接定位生效的 BEM 规则并跳转源码，避免手动翻 Styles 面板或 DOM 树。
直接用 BEM 能显著缩短移动端 H5 的 CSS 调试时间，关键不在“写得对”，而在“查得快”——Chrome DevTools 里搜 color 或 padding 就能定位生效规则，不用翻 DOM 树、不靠猜。
在 Chrome DevTools 里怎么一眼找到命中的 BEM 类
打开“Computed”标签页，搜某个具体属性（比如 font-size 或 display），带小箭头的那条就是实际生效的 BEM 规则，点击就能跳转源码。别在“Styles”面板里手动滚动找 —— 那里展示的是所有匹配选择器，不是最终胜出的。
- 常见错误：改了
user-card__avatar--loading的opacity，但没生效。大概率是另一条更晚加载或权重更高的规则（比如宿主注入的.avatar { opacity: 1 !important; }）覆盖了它；搜opacity比检查 class 名是否拼错快得多 - 按住
Ctrl（Windows）或Cmd（macOS）再点击“Styles”里的任意属性值，能直接跳到该属性最终来源（含@import路径） - 搜修饰符要输全名：
input--disabled比搜disabled准，避免命中第三方库的.disabled
为什么 BEM 类名能让调试不依赖 DOM 结构
BEM 把归属、角色、状态全锁进类名，比如 nav__item--active 明确表示“属于 nav 块的 item 元素，当前处于 active 状态”。它不依赖父容器是否存在，也不靠嵌套选择器触发样式。
- 对比传统写法：
.nav li a.active调试时得确认li是否真在.nav下、a是否被其他:hover覆盖；而 BEM 下nav__link--active独立存在，DevTools 里一目了然 - 禁止写后代选择器，比如
.card__body p—— 这破坏原子性，让p的样式归属无法从类名推断；真要控制，就定义新类card__body-text - 移动端 WebView（尤其 Android X5 内核）常被宿主注入全局样式，
.text类会误命中你的card__title；但user-card__title天然不匹配，调试时不用纠结“为什么颜色变了”，而是直接看它有没有被划掉
BEM 类名动态生成时最容易漏掉的调试盲区
getComputedStyle() 返回的是计算值，不带原始类名信息。比如 button--large 设了 padding: 16px，你调用 getComputedStyle(btn).padding 只看到 "16px"，完全不知道它来自哪个 BEM 类 —— 这是移动端调试中最容易忽略的断点。
立即学习“前端免费学习笔记（深入）”；
- 所有 BEM 类必须显式写在模板中，不要用 JS 拼接后塞进
innerHTML—— WebView 下这类插入不触发 CSSOM 更新，样式不会生效，但 DevTools 里 class 属性看着还在，容易误判 - uni-app / Taro 项目若开了
cssModules或scoped，BEM 类名会被哈希化（如user-card__title_abc123），导致 JS 里用classList.toggle('user-card__title--loading')找不到原类名，直接失效 - 检查 Elements 面板里 class 属性是否真实存在：
class="user-card user-card--active"是原样输出，不是被埋点 SDK 清洗为空或转成驼峰格式
真正卡住调试的，往往不是命名写错了，而是类名没出现在 DOM 里，或者出现在了但被构建工具/宿主脚本悄悄改掉了 —— 这些地方没有报错，却让样式彻底失联。
