contain: size必须配合显式width/height等尺寸声明才能生效，否则浏览器无法确定“固有尺寸”而直接忽略该属性；它不赋予尺寸，仅承诺内容变化不改变已声明的布局盒大小。
contain: size 为什么必须配合显式尺寸使用
contain: size 的作用不是“让元素自动获得尺寸”，而是告诉浏览器：“这个元素的尺寸已由 CSS 显式定义，后续子内容变化（比如文本增减、图片加载）不会影响它的布局盒大小”。如果没写 width 或 height，浏览器根本不知道“固有尺寸”是多少，contain: size 就直接被忽略——查 computed style 会发现它甚至不生效。
常见错误现象：div { contain: size; } 写了但毫无效果，元素仍随子内容撑开；或者加了之后布局错乱，其实是尺寸塌陷了。
- 必须搭配至少一个明确的尺寸声明：
width、height、min-width、min-height（推荐用min-避免截断） - 百分比值有效，但依赖父容器——父容器也得有确定尺寸，否则还是计算不出
-
contain: size对display: inline元素无效，只对生成盒子的 display 类型起作用（如block、flex、grid）
contain: size 在 flex/grid 容器里的典型误用
在 display: flex 或 display: grid 的子项上单独写 contain: size 很容易失效，因为 flex/grid 的尺寸分配逻辑会覆盖或绕过它。浏览器优先执行布局算法，再考虑 contain 优化，如果尺寸本身是“由内容决定”的（比如 flex: 1 或 grid-template-columns: auto），contain: size 就没机会起作用。
正确做法是：先切断内容驱动尺寸的路径。
- flex 子项：改用
flex: 0 0 <fixed-size></fixed-size>，例如flex: 0 0 200px，再加contain: size - grid 子项：确保它所在轨道是定长的，如
grid-template-columns: 200px 1fr，且自身不设width: auto - 避免和
align-content: stretch或justify-content: stretch同时用，它们可能强制拉伸，破坏 size containment
contain: size + content-visibility: auto 的协同陷阱
很多人想用 contain: size 配合 content-visibility: auto 实现高性能列表渲染，但漏掉关键前提：后者要求元素有**可预测的高度**，而 contain: size 只承诺“不因内容变”，不承诺“高度固定”。如果子内容字体、行高、margin 不一致，实际渲染高度仍会浮动。
典型错误：给列表项加 contain: size 和 content-visibility: auto，滚动时仍触发重排，控制台看到 layout thrashing。
- 必须为元素设置明确的
height或min-height（建议用min-height防止内容溢出） - 子元素需避免使用
em、rem等相对单位导致高度不可控；优先用px或vh -
contain: size不阻止子元素的transform或opacity动画，但若动画引发will-change或频繁重绘，仍可能削弱优化效果
怎么验证 contain: size 是否真正生效
不能只看样式面板里有没有 contain: size，要确认浏览器是否实际启用该优化。最直接的方式是观察布局行为是否脱离内容依赖。
- 在 DevTools 中选中元素 → Elements → Styles，检查
contain是否显示为size（而非被 override 或 invalid） - 手动修改子元素内容（比如删掉一段文字、替换一张大图），观察父元素的
getBoundingClientRect()返回值是否不变 - 打开 Chrome 的 Rendering 面板 → 勾选 “Layout Shift Regions”，如果该区域不再随子内容变化闪烁，说明 size containment 生效
- 注意：Firefox 目前不支持
contain: size（仅支持layout和paint），Safari 支持但需开启实验性功能，兼容性必须兜底
真正难的不是写这行 CSS，而是把“尺寸来源”从内容侧彻底剥离——一旦某个 margin、line-height、font-size 没锁死，contain: size 就形同虚设。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
