在写CSS的时候，height、max-height、min-height这三个属性同时出现并不罕见。比如一个卡片容器，我们希望它默认高度是300px，最大不超过500px，最小不低于200px，于是三个属性一股脑写上去。可当内容撑开容器超出预期时，你会发现最终的高度往往和你想象的不一样，甚至min-height会直接压过height成为最终值。这不是浏览器的bug，而是CSS规范里明确定义的一套约束求解算法。理解这套算法，才能真正做到对盒子高度心中有数。
一、先看现象：一个反直觉的例子
我们先来看一段最典型的代码：
.box {
height: 100px;
max-height: 80px;
min-height: 150px;
}
三个属性同时生效时，这个盒子的最终高度是多少？按照很多人直觉中的"优先级"排序，height是直接声明，应该最优先，max-height字面上是"最大值"，似乎只是上限。但实际渲染结果是150px。也就是说，min-height赢了，max-height被无视了，height也被覆盖了。
更有意思的是，如果把min-height改成50px，那么最终高度是80px，此时max-height又赢了。可以发现，最终的胜负关系并不是固定的，而是取决于三个值之间的数学大小关系。这背后其实是一条固定的计算流水线，任何组合丢进去，都会沿着这条流水线得出确定的结果。
二、规范定义的求解算法：三步走
这套算法写在CSS 2.1规范的10.7节，后来在CSS Sizing规范中进一步扩展。原文描述的规则可以概括为一个"约束求解"（constrained resolution）的过程，分三步执行：
第一步，先看height能否直接使用。如果height是auto，或者内容本身就能决定尺寸（比如普通文档流中不设高度的块级盒子），那么先用内容高度作为候选值。如果height是一个明确值，比如100px，候选值就是100px。
第二步，用max-height去钳制候选值。规则是：如果候选值大于max-height，则使用max-height。也就是先取候选值和max-height中的较小者。这一步结束之后，我们得到一个中间值。
第三步，用min-height去做兜底。规则是：如果中间值小于min-height，则最终使用min-height。也就是取中间值和min-height中的较大者。
整个过程用伪代码表达非常清晰：
tentative = height（auto 时由内容决定） afterMax = min(tentative, max-height) // 上限钳制 final = max(afterMax, min-height) // 下限兜底
正因为min-height在流水线的最后一步执行，它对最终结果拥有最高的话语权。当min-height大于max-height时，min-height必然胜出，这就是标题中那个问题的答案：不是min-height优先级更高，而是它最后出手，直接把前面两步的结果覆盖掉了。
三、动手验证：不同取值组合的结果
我们用一组组合来验证上面的算法。假设height为100px，观察max-height和min-height变化时的结果：
| height | max-height | min-height | 最终高度 | 胜出者 |
|---|---|---|---|---|
| 100px | 未设置 | 未设置 | 100px | height |
| 100px | 80px | 未设置 | 80px | max-height |
| 100px | 80px | 150px | 150px | min-height |
| 100px | 未设置 | 150px | 150px | min-height |
| 100px | 200px | 50px | 100px | height |
逐行分析这张表。第二行中，height的100px大于max-height的80px，被钳制到80px。第三行是典型的冲突场景：100px先被max-height压到80px，又因为80px小于min-height的150px，最终被抬升到150px。第五行是三者互不干扰的和平局面，100px既没超过200px的上限，也不低于50px的下限，所以height原样生效。
还有一个容易被忽略的场景：height为auto时。比如一个内容可变的容器：
.panel {
/* 未设置 height，候选高度由内容决定 */
max-height: 300px;
min-height: 120px;
overflow: auto;
}
当内容很少时，内容高度可能只有50px，但min-height的120px会把容器抬到120px；当内容很多时，内容高度可能达到800px，max-height的300px又把它压回300px，超出部分配合overflow: auto出现滚动条。这种写法在实际项目中非常常见，也正是这套流水线最合理的应用方式。
四、实际开发中的注意事项与建议
第一，避免出现min-height大于max-height的声明。虽然浏览器不会报错，渲染结果也是可预测的（min-height胜出），但这种写法会让后来维护代码的人困惑不已。如果确实存在这种需求，说明设计上可能存在矛盾，应该重新梳理尺寸约束逻辑，而不是依赖浏览器的兜底行为。
第二，注意width方向的规则完全一致。这套三步走的算法同样适用于width、max-width、min-width，原理和结论可以直接迁移，只是水平方向多了一个box-sizing的影响。当box-sizing取content-box和border-box时，width指代的区间不同，但max和min之间的求解顺序不变。
第三，弹性布局中要考虑flex子项的特殊性。flex子项的主轴尺寸还会受到flex-basis、flex-grow、flex-shrink的干预，min-height在flex子项上默认解析为auto，可能导致子项拒绝收缩到内容高度以下。这时候需要显式设置min-height: 0来打破这个默认行为，这是另一个高频踩坑点。
第四，合理利用这条流水线而不是对抗它。理解了"min-height最后出手"这个特性后，可以放心地用它做安全兜底：给可能内容为空的容器设置min-height，避免塌陷；给可能爆内容的容器设置max-height配合overflow，避免撑破布局。只要保证逻辑上min-height不大于max-height，三个属性就能各司其职、和平共处。
总结一下，height、max-height、min-height并不是简单的优先级竞争关系，而是一条"height先定候选值、max-height压上限、min-height托底"的约束求解流水线。min-height之所以总能笑到最后，是因为它站在了流水线的最后一环。掌握这个顺序，盒子高度的任何诡异表现都能被你一眼看穿。
CSS min-height盒子高度计算height优先级修改时间：2026-09-12 16:54:32