content-visibility: hidden 跳过渲染但保留布局，因其跳过子树的布局、绘制和合成，仅依赖 contain-intrinsic-size 或盒模型预留占位空间；未设置 contain-intrinsic-size 会导致布局塌陷。
content-visibility: hidden 为什么能跳过渲染但保留布局
它不是“隐藏后还渲染”，而是让浏览器直接跳过该元素内部的布局（Layout）、绘制（Paint）和合成（Composite）阶段，只保留其 contain-intrinsic-size 或盒模型计算出的占位空间。这和 display: none 的彻底移除不同，也和 visibility: hidden 的“渲染但不可见”有本质区别——后者仍会执行完整渲染流水线，只是最终像素不输出。
必须显式设置 contain-intrinsic-size 才能稳定占位
当使用 content-visibility: hidden 时，浏览器不再计算子内容尺寸，因此若未提前告知“这个容器应该占多大位置”，布局就会塌陷或抖动。你必须手动提供尺寸预期：
- 推荐写法：
content-visibility: hidden; contain-intrinsic-size: 200px 300px;（宽高固定） - 响应式场景可用
contain-intrinsic-block-size+contain-intrinsic-inline-size分离控制 - 若内容高度动态（如富文本），可估算最大可能高度并设为
contain-intrinsic-size: auto 800px;，避免滚动时重排 - 漏掉
contain-intrinsic-size是最常见翻车点：元素视觉消失，但下方内容上移、布局错乱，且getBoundingClientRect()返回的高度可能为 0
与 visibility: hidden 和 display: none 的关键行为差异
三者表面都“看不见”，但底层机制和副作用完全不同：
-
content-visibility: hidden：不触发子树渲染，不响应事件（click等不会冒泡进来），不执行 JS（IntersectionObserver仍能监听，但requestAnimationFrame内部逻辑不执行） -
visibility: hidden：子树照常渲染，仅视觉不可见；仍响应鼠标事件（需加pointer-events: none禁用）；屏幕阅读器默认可读取 -
display: none：DOM 节点从渲染树中完全剔除；offsetParent为null；getClientRects()返回空集合；无障碍技术直接跳过
选错会导致性能没提升、交互异常或无障碍失效——比如用 content-visibility: hidden 去隐藏一个需要键盘聚焦的表单字段，焦点会直接跳过它，而这不是 bug，是设计使然。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
实际使用中容易被忽略的限制
content-visibility: hidden 不是万能开关，以下情况它会自动降级或失效：
- 父元素设置了
overflow: hidden且自身无明确尺寸时，浏览器可能拒绝应用content-visibility - 元素有
transform、opacity < 1或filter时，会强制创建新层叠上下文，导致content-visibility被忽略 - 在
iframe内或 Shadow DOM 边界处，支持度受限（Chrome 95+ 稳定，Firefox 100+ 仅部分支持） - 无法通过 JS 动态“唤醒”：切换回
content-visibility: visible才能恢复渲染，hidden状态下对子元素设visibility: visible无效
真正要靠它省资源，就得接受“内容不可交互、不可聚焦、不可动画”的前提——它适合广告位占位、离线面板预留、长列表折叠区，不适合按钮、输入框或过渡动画容器。
