直接写min-content即可让列宽严格按内容最窄处撑开，它是浏览器真实计算出的该列所有子项中“最小内容宽度”的最大值，不额外留空、不被挤压；常见错误是误用auto，它受min-width、white-space等干扰而变宽。
用 min-content 直接设列宽
想让某一列严格按内容最窄处撑开（比如一个短文字、一张小图），不额外留空、不被其他列挤压，直接写 min-content 就行。它不是估算值，而是浏览器真实计算出的该列所有子项中“最小内容宽度”的最大值。
常见错误是误用 auto：它会考虑 min-width、white-space、甚至 inline-size 约束，结果往往比预期宽；而 min-content 绕过这些干扰，只看纯内容流式换行前的自然宽度。
-
grid-template-columns: min-content 1fr—— 左列紧贴内容，右列吃掉剩余空间 - 若左列有
white-space: nowrap的长字符串，min-content会把它整个算进去，列宽就是那串字符的原始宽度 - 搭配
justify-items: start可防止内容在列内居中导致视觉“变宽”
minmax(min-content, max-content) 的实际效果
这个组合看似合理，但几乎没用：它把列宽锁死在“最小内容宽”到“最大内容宽”之间，而浏览器在分配空间时，只要没超容器，通常就直接取 min-content —— 和单写 min-content 行为一致；一旦内容拉伸，又可能突然跳到 max-content，破坏布局稳定性。
真正需要弹性约束时，应换用 minmax(100px, max-content) 或 minmax(min-content, 300px)，明确给出可接受的上限或下限。
立即学习“前端免费学习笔记（深入）”；
- 不要写
minmax(min-content, max-content)，它不解决任何实际问题，还增加解析负担 -
max-content在 Grid 中容易引发溢出，尤其当子项含未约束图片或表格时 - 如果目标是“尽量窄，但别窄过某个像素值”，写
minmax(120px, min-content)是错的——minmax()要求第一个参数 ≤ 第二个，否则降级为auto
为什么 fit-content() 不适合“最小内容宽度”场景
fit-content(50ch) 这类写法常被误认为能“自动收缩”，但它本质是 minmax(min-content, max(50ch, max-content)) 的语法糖，仍受上限参数主导。当内容本身比 50ch 短，它确实表现像 min-content；但只要有一处内容超了，整列就变成 50ch 或更宽，失去“最小化”的本意。
- 要的是“绝对最小”，就别加任何上限参数，老实用
min-content -
fit-content()更适合按钮、标签这类需“内容自适应 + 有安全上限”的控件，不是布局轨道的通用解 - 旧版 Safari 对
fit-content()支持不稳定，min-content兼容性更好（Chrome 57+、Firefox 52+、Safari 10.1+）
内容撑不开列？检查这三处
写了 min-content 却发现列还是空着或太宽，大概率是内容没真正“参与计算”。Grid 的 min-content 基于子项的**固有尺寸**，而非渲染后尺寸。
- 子项用了
width: 100%或flex: 1，它已放弃自身内容宽度，min-content就无从谈起 - 子项是空
<div> 或只有空格/换行符，<code>min-content计算结果为 0，列会塌缩（可加min-width: 1px防止） - 父 Grid 容器设了
overflow: hidden，可能截断内容测量过程，导致min-content误判
真正难处理的是那些带 text-overflow: ellipsis 或 container-type: inline-size 的子项——它们的“内容宽度”在 CSS Containment 下会被隔离，min-content 拿不到真实值。
