双伪元素清除在页脚场景更危险，因::before在Safari 15.6前、IE及部分WebView中不参与清除计算且无报错，仅::after有效但需满足display:table、clear:both、content:""三条件；::before反而可能干扰flex顺序或触发换行。
为什么双伪元素清除在页脚场景下反而更危险
双伪元素（::before + ::after）常被误传为“更强力的清除方案”，但实际在页脚定位中，::before不仅无用，还可能破坏布局。浏览器对::before触发clear的支持极不稳定——尤其在 Safari 15.6 之前、IE 系列及部分安卓 WebView 中，::before生成的内容无法参与清除计算，导致清除失效却无报错。
真正起作用的只有::after：它必须出现在浮动容器的末尾流位置，且需满足三个条件：display: table（或block）、clear: both、content: ""。加::before只是多了一段不可见却占位的空内容，可能干扰 flex 子项顺序或触发意外换行。
页脚父容器上该用 display: flow-root 还是 overflow: hidden
优先选 display: flow-root，前提是项目最低支持 Chrome 58 / Firefox 53 / Safari 10.1+（2017 年后主流版本均覆盖）。它能安全触发 BFC，不裁剪阴影、不截断绝对定位子元素、不触发滚动条，比 overflow: hidden 更干净。
仅当需兼容 IE11 或旧版 Android Browser 时，才退回到 overflow: hidden。但要注意：
- 如果页脚内有
position: absolute的提示气泡或下拉菜单，overflow: hidden会直接把它切掉 -
overflow: auto虽能避免裁剪，但在 iOS Safari 中可能引发非预期滚动惯性 -
zoom: 1对 IE6/7 仍有效，但现代项目已无需考虑
给 footer 元素本身加 clear: both 为什么经常没用
因为 clear: both 只对「前面相邻的浮动兄弟元素」生效，而页脚往往不是浮动元素的直接后续兄弟——中间可能隔着一个 div.wrapper、main 或被 position: relative 干扰的容器。此时清除动作找不到参照物，等同于没写。
真正有效的做法是定位到「浮动结束后的第一个块级流内元素」，比如：
- 浮动都在
.content内？那就给.content加clearfix类 - 浮动分布在
header和aside？那得分别在它们各自末尾清除，或统一收口到body的直接子容器上 - 用了
display: grid布局却还在某个article里 float 图文？清除范围必须严格限制在该article内部，不能外溢
移动端页脚突然上浮，和浮动有关吗
大概率无关。2026 年主流项目中，浮动本身已极少用于整体布局，页脚上浮更常源于两个隐藏原因：
一是 vh 单位在 Safari 移动端受地址栏显示/隐藏影响，视口高度动态变化，导致 min-height: 100vh 计算失准；此时应改用 100dvh（Chrome 105+/Safari 16.4+ 支持），或回退到 JS 动态设置 style.minHeight。
二是父容器设置了 transform（如 scale(0.9)）或 will-change，间接创建了新的层叠上下文和格式化上下文，使浮动清除逻辑失效——这种问题不会报错，但清除元素会“看不见”前面的浮动。
浮动只是表象，真正要盯住的是：清除动作是否发生在正确的 BFC 边界内，以及高度是否被可靠继承。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
