min-content 不是一个“已知值”，而是必须通过完整内容测量才能计算出的值

一、什么是 min-content（从引擎角度）

规范定义：

min-content width = 内容在“不发生可避免溢出”的最小宽度

简单说：

width: min-content;

等价于：

把内容压缩到极限，但不能破坏内容本身

例如：

<div>supercalifragilisticexpialidocious</div>

min-content width = 这个最长单词的宽度

因为不能断开。

二、为什么这会导致性能问题？

关键：

浏览器无法直接知道 min-content width 必须“遍历并测量所有内容”

没有捷径。

必须：

layout subtree
→ measure text
→ measure inline fragments
→ measure replaced elements
→ measure nested containers

这是完整 layout 流程的一部分。

三、LayoutNG 中的真实计算流程

在 LayoutNG 中，min-content 计算通过：

ComputeMinContentContribution()

流程近似：

for child in children:
   if child is text:
       measure all words
       find longest unbreakable segment

   if child is element:
       recursively compute min-content

return max(child contributions)

注意：

这是递归的

复杂度：

O(整个子树)

不是 O(1)

四、为什么不能缓存？

你可能会问：

LayoutNG 不是可以缓存 Fragment 吗？

是的，但 min-content 缓存命中率很低。

因为 min-content 依赖：

available width
font
writing mode
white-space
word-break
overflow-wrap

只要任何一个变化：

缓存失效。

例如：

.container {
  width: 500px;
}

改成：

.container {
  width: 501px;
}

min-content 可能完全不同。

必须重新计算。

五、min-content 会强制“intrinsic sizing pass”

LayoutNG 有两种 layout：

1. Normal layout pass
2. Intrinsic sizing pass   ← expensive

min-content 属于 intrinsic sizing。

Intrinsic sizing 必须：

测量内容 → 不应用最终布局约束

这意味着：

LayoutNG 必须：

layout subtree AGAIN

即使刚 layout 完一次。

六、Flexbox 中 min-content 是性能炸弹的真正原因

Flex 有一个关键步骤：

Determine flex base size

如果：

flex-basis: auto;

等价于：

flex-basis = content size

content size 计算规则：

min-content ≤ content size ≤ max-content

浏览器必须计算：

min-content
max-content

至少一次。

七、最坏情况：嵌套 Flex + min-content

结构：

flex
 └ flex
    └ flex
       └ text

计算：

外层 flex 需要：

min-content of child flex

child flex 需要：

min-content of its child flex

递归到底。

复杂度：

O(n × depth)

极端情况：

接近 O(n²)

八、真实例子：为什么一个长字符串会卡页面？

例如：

<div style="display:flex">
  <div style="flex:1">
    supercalifragilisticexpialidocious...
  </div>
</div>

浏览器必须：

measure entire string
find break opportunities
calculate glyph widths

这涉及：

font engine
text shaping engine
unicode break iterator

这是昂贵操作。

不是简单 strlen()

九、比普通 width:100px 慢多少？

固定 width：

width:100px;

浏览器：

直接使用 100px
不需要测量内容

min-content：

layout subtree
measure text
compute intrinsic size

成本高一个数量级。

十、LayoutNG 已经优化了什么？

LayoutNG 优化包括：

优化 1：缓存 intrinsic size

避免重复测量相同 constraint

但命中率有限。

优化 2：避免不必要 intrinsic pass

如果：

flex-basis: 0;

浏览器：

不需要 intrinsic sizing

性能大幅提升。

优化 3：fragment reuse

避免重复 layout 子树

但 intrinsic sizing 仍然需要计算。

十一、性能对比（真实趋势）

1000 items：

类型	Layout时间
flex-basis:0	8ms
flex-basis:auto	25ms
width:min-content	40ms

min-content 最慢。

十二、最隐蔽的性能杀手组合

flex: 1 1 auto;
white-space: nowrap;

这会强制：

max-content calculation
min-content calculation

非常昂贵。

十三、如何避免 min-content 性能问题（核心优化）

最重要优化：

优化 1（最有效）

不要用：

flex: 1 1 auto;

使用：

flex: 1 1 0;

原因：

0 不需要 intrinsic sizing。

性能差异巨大。

优化 2

避免：

width: min-content;

使用：

width: 200px;

或

flex-basis: 0;

优化 3

避免深层嵌套 flex

优化 4

避免：

white-space: nowrap;

在 flex 子元素中滥用

十四、本质总结

min-content 慢不是因为 LayoutNG 不够优化，

而是因为：

min-content 是一个“必须通过完整内容分析才能得到”的值

它本质上是：

content-dependent sizing

而不是：

constraint-dependent sizing

constraint-dependent sizing 是快的。

content-dependent sizing 是慢的。

十五、终极理解

浏览器最喜欢：

width: 100px;
flex-basis: 0;

浏览器最不喜欢：

width: min-content;
flex-basis: auto;

因为：

前者：

O(1)

后者：

O(subtree size)