content-visibility: auto 不跳过布局计算但跳过渲染，导致浮动子元素引发父容器高度塌陷，且 overflow: hidden 无法修复，根本解决需替换 float 或禁用 content-visibility。
content-visibility: auto 会跳过渲染，但不跳过布局计算
不是所有“隐藏”都等于“不占空间”。content-visibility: auto 的核心机制是：当元素滚动出视口时，浏览器会跳过其子树的**绘制和合成**，但仍然保留其**盒模型计算**（包括 margin、padding、border），只是把内部内容当作“未渲染”处理。关键在于——它**不触发 BFC**，也不影响浮动子元素的脱离行为。
所以当父容器设了 content-visibility: auto，而它的子元素又用了 float，就会复现经典高度塌陷：浮动子元素脱离文档流 → 父容器在布局阶段无法感知其高度 → 即使内容被跳过渲染，父容器高度仍为 0。
为什么 overflow: hidden 不再能“修复” content-visibility 下的塌陷
传统方案中，overflow: hidden 能解决高度塌陷，是因为它触发 BFC，强制包含浮动子元素。但一旦父元素同时设置了 content-visibility: auto，BFC 触发逻辑会被覆盖或弱化——现代浏览器（Chrome 103+、Firefox 110+）对 content-visibility 的实现优先级更高，BFC 的包含行为可能被限制在“已渲染子树”范围内，而浮动子元素因未进入渲染流程，被忽略参与高度计算。
-
content-visibility: auto+overflow: hidden组合下，父容器仍可能高度为 0 - 即使手动添加
::after { clear: both }，伪元素也可能被content-visibility的渲染跳过策略排除在布局之外 - DevTools 中看到元素“存在”，但 computed height 仍是 0 —— 这不是 bug，是规范定义的行为
真正有效的绕过方式：换掉 float，或换掉 content-visibility
这不是兼容性问题，而是底层机制冲突。想共存，必须避开根本矛盾点：
立即学习“前端免费学习笔记（深入）”；
- 用
display: flex或display: grid替代float布局 —— 它们天然不脱离文档流，不受content-visibility渲染跳过影响 - 若必须用浮动，就不要给父容器设
content-visibility: auto；改用contain: layout style paint（更细粒度控制，且不影响高度计算） - 用
visibility: hidden或opacity: 0替代 —— 它们保留文档流，高度正常，只是视觉不可见 - 真要高性能懒加载？考虑 IntersectionObserver + 动态插入 DOM，而不是依赖
content-visibility的自动跳过
容易被忽略的调试信号
遇到 content-visibility 下高度异常，别急着加 clearfix —— 先确认 DevTools 中该元素的 Layout 面板是否显示 “Skipped rendering subtree”。如果显示了，说明浏览器根本没走完整布局流程，任何基于渲染后状态的 hack（如伪元素、clear）都会失效。
最可靠的判断方式是：临时移除 content-visibility，看塌陷是否消失。如果消失，问题根源就在它与浮动/绝对定位等脱离文档流行为的不兼容性上，而非 CSS 写法本身。
