width/height设为auto无效是因为auto按盒模型规则计算而非自动撑开，其表现取决于父容器、定位、display类型等上下文；百分比尺寸需父容器有明确宽高才生效，vw/vh混用易因渲染时机或兼容性出错。
width/height 设为 auto 为什么没效果
因为 auto 在大多数布局上下文中不是“自动撑开”，而是“按盒模型规则计算”——它依赖于父容器、浮动、定位、display 类型等。比如块级元素在标准流中设 width: auto 是默认行为，你根本看不出变化；但设了 position: absolute 后，width: auto 就会收缩到内容宽度。
常见错误现象：div 里放了一张图，给它设 width: auto; height: auto;，结果高度塌陷、背景消失——其实是父容器没高度，子元素又脱离文档流或没触发 BFC。
- 行内元素（如
span）设width/height无效，除非先改display（比如inline-block） -
table元素的width: auto表现特殊：它会优先满足内容宽度，而非父容器约束 - Flex 项目中，
width: auto会被flex-basis覆盖，真正起效的是flex: 0 1 auto这类组合
百分比 width/height 为何经常不按预期缩放
百分比是相对于**包含块（containing block）** 计算的。width 百分比参照父容器宽度没问题，但 height 百分比要求父容器有**明确的高度值**（不能是 auto），否则直接失效，退化为 height: auto。
使用场景：做响应式卡片、全屏覆盖层、等宽高比容器时，容易在这里卡住。
立即学习“前端免费学习笔记（深入）”；
- 父容器用
height: 100vh，子元素才能用height: 50%得到 50vh - Flex 容器中，子项设
height: 50%仍可能无效——因为 flex item 的包含块高度由 flex 容器决定，而后者若没显式设高，就是auto - 绝对定位元素的百分比高度，参照的是最近的「已定位祖先」的高度，不是视口
max-width/min-height 这类限制值的实际生效条件
它们不是“样式开关”，而是“约束边界”。是否触发，取决于内容尺寸、布局上下文、以及其它尺寸声明的优先级。
性能影响很小，但滥用会导致意外交互：比如 max-width: 100% 配合 width: fit-content，在图片加载前后可能闪动；min-height: 100vh 在移动端 Safari 中可能因地址栏收放导致滚动异常。
-
max-width对文本段落有效，但对display: table元素几乎无效 -
min-height在 flex 容器中常被align-items: stretch覆盖，需配合flex-shrink: 0才能稳住最小高度 -
width: 200px; max-width: 100%是安全写法，确保不超父容器，但注意：若父容器只有padding没有width，100% 仍可能溢出
vw/vh 单位和 width/height 混用时的典型陷阱
vw/vh 看似简单，但和传统尺寸混用时，浏览器计算顺序和渲染时机容易引发错位。尤其在动态内容插入、字体加载、第三方组件嵌入场景下，height: 80vh 可能比内容早渲染，导致滚动条意外出现或遮挡。
兼容性上，IE9+ 支持 vh，但 iOS Safari 7.1–9.3 有视口缩放 bug，100vh 会把地址栏高度也算进去，实际显示超出屏幕。
- 移动端慎用
height: 100vh做全屏背景——用户滚动后地址栏收起，页面会突然多出空白 -
width: 50vw和margin-left: 25vw组合，在某些安卓 WebView 中因小数像素舍入，可能导致水平偏移 1px - 用
calc(100vh - 60px)减去固定 header 高度时，要确认 header 高度本身是确定值（非fit-content或含 border-box 不一致）
最麻烦的不是语法不会写，而是同一套 CSS 在不同设备、不同加载阶段、不同祖先 display 类型下，height 的表现逻辑完全不同。调试时别只看 DevTools 里写的值，得盯着“computed”面板里最终解析出的数字，再反推是哪一层包含块把它锁死了。
