clearfix不该作为BEM中的block，因其无视觉/功能语义、不渲染内容，本质是工具类；正确做法是作为全局u-clearfix工具类或SCSS mixin混入，或改用display: flow-root。
clearfix该不该作为BEM中的一个block
不该。BEM规范里block必须代表一个独立、可复用的视觉/功能单元（比如header、button），而clearfix不渲染任何内容，也不承载业务语义，它只是解决布局副作用的底层机制——本质上是工具类（utility class），不是组件。
强行定义为block会导致两个问题：
一是命名污染，比如clearfix__item毫无意义；
二是破坏BEM“块隔离”原则，因为clearfix必须作用于父容器，却和子元素的BEM结构无关。
- 正确做法：把
clearfix当作全局工具类，不参与BEM命名体系 - 在SCSS中可封装为
@mixin clearfix，按需混入，避免重复写伪元素 - 若团队强制所有工具类走BEM，至少降级为
u-clearfix前缀（u-表示utility），而非clearfix本身当block
为什么不能写成.block__element_clearfix
这种写法违反BEM核心规则：修饰符（_modifier）只能描述block或element自身的状态变化（如button_is-active），不能用来“修复外部布局问题”。clear: both不是element的状态，而是父容器需要承担的布局责任。
更实际的问题是：这个类加在子元素上完全无效。清除浮动必须作用于**浮动子元素的直接父容器**，而不是子元素自己。
-
.article__content_clearfix→ 错误：即使.article__content是父容器，加修饰符也掩盖了它作为“浮动容器”的真实角色 -
.article__content+.clearfix→ 正确：职责分离，BEM结构清晰，CSS可预测 - 若用预处理器，推荐
@include clearfix直接注入到.article__content规则内，不暴露额外类名
如何在BEM项目中安全引入clearfix而不破坏模块化
关键是控制作用域和触发时机。BEM组件应默认“自包含”，但浮动是跨组件的布局干扰，必须显式声明依赖。
- 只在明确需要包裹浮动子项的
block顶层容器上添加.clearfix，例如<div class="sidebar clearfix">，而不是<code><div class="sidebar__wrapper clearfix"> <li>避免在<code>block内部的element上使用——比如.card__body里塞浮动图片，应由.card自身加.clearfix兜底，而非让.card__body承担 - 现代项目优先用
display: flow-root替代，它无伪元素、不干扰line-height，且本身就是CSS属性，可直接写进BEM的block样式里：.sidebar { display: flow-root; } - 如果必须兼容IE11，保留
.clearfix类，但通过构建工具（如PostCSS）自动注入到已知浮动容器的选择器后，减少人工漏加 - 检查点：用浏览器开发者工具的Computed面板看目标容器是否已触发BFC（
display含flow-root/flex/grid，或overflow非visible） - 若已触发，删掉
.clearfix——叠加反而可能因伪元素引入意外高度或margin - 若未触发，且子项含
float，立即加.clearfix或改用display: flow-root - 特别注意CMS输出内容：富文本编辑器插入的
<img style="max-width:90%">无法预知，此时.article__content这类容器必须无条件加清除逻辑
嵌套BEM结构中clearfix加在哪一层最稳
加在每一级“可能产生浮动子项”的容器上，不能省略中间层。BEM嵌套常见于list → list__item → media-object → media-object__figure这类结构，一旦media-object__figure设了float: left，而media-object没创建BFC，塌陷就会从media-object向上穿透到list__item，最终让整个list高度失真。
这不是过度设计，而是BEM组件复用时的必然要求：每个block必须对自己渲染出的DOM负责。
真正容易被忽略的是：BEM命名解决的是“怎么叫”，而clearfix解决的是“怎么活”。前者再规范，后者一漏，整个块就塌了——它不挑BEM，只认DOM树里的父子关系。
