Grid布局中minmax()怎么写才不塌陷
直接说结论：minmax(250px, 1fr)是常用写法，但“不塌陷”的关键不在函数本身，而在父容器必须有明确宽度，且子项不能强行撑宽（比如width: 100%或flex: 1这类干扰行为）。
常见错误现象：网格列数忽多忽少、最后一行只剩一列、高度参差不齐像被拉扯过。本质是minmax()里的最大值（1fr）在没有足够剩余空间时会收缩到最小值，而浏览器又没强制子项按内容高度对齐。
-
minmax()第一个参数是“最小宽度”，不是固定宽度——它只保底，不锁死 - 第二个参数用
1fr比auto更可控，但前提是所有子项的box-sizing为border-box，否则padding/margin会偷偷突破 - 别在子项上设
width或max-width，Grid靠轨道分配空间，手动干预反而让minmax()失效
为什么grid-auto-flow: dense有时候反而让布局更乱
它只解决“空洞填充”，不解决“高度差异”。Pinterest式瀑布流依赖的是子项高度不一致 + 列独立堆叠，而CSS Grid是行列同步对齐的——dense只是把小卡片往前塞，但列高仍由该列最高项决定，视觉上还是“阶梯状”，不是“错落感”。
使用场景有限：仅当你有一组已知尺寸、且允许打乱DOM顺序的卡片时才适用；真实业务中卡片含图片/文字，加载异步、高度动态，dense基本无效。
立即学习“前端免费学习笔记（深入）”；
-
grid-auto-flow: dense不会重排DOM节点，只是改变渲染顺序，SEO和可访问性不受影响，但逻辑顺序和视觉顺序分离 - 配合
grid-row-end: span 2等手动跨行时，dense可能把后续项塞进不该塞的位置，出现重叠或错位 - 真正需要“错落”效果，得靠JavaScript（如Masonry）或服务端预计算分列，纯CSS Grid做不到Pinterest原生效果
图片加载导致高度跳变，Grid列宽反复重算怎么办
根本原因：图片未加载时高度为0或默认值，Grid按初始尺寸布局；图片加载后撑开高度，触发整个网格重排，用户看到“抖动”。这不是Grid的错，是资源加载时机问题。
实操建议优先从HTML/CSS层压制抖动，而不是等JS劫持：
- 给图片容器设
aspect-ratio（如aspect-ratio: 4/3），现代浏览器直接预留空间，无需JS - 用
img的width和height属性（非CSS）提供固有宽高比，兼容性更好 - 避免在子项上用
height: 100%或min-height: 100vh，这些会让Grid无法准确估算初始高度 - 如果必须等图片加载完再渲染，用
loading="lazy"+IntersectionObserver控制，而非监听load事件——后者在慢网下延迟明显
兼容性底线：哪些老浏览器必须放弃Grid方案
IE11及以下完全不支持grid-template-columns里的minmax()，连fr单位都不认；Android 4.3 WebView、iOS 9 Safari虽支持Grid，但minmax()解析异常，常退化为单列。
性能影响比想象中小：Grid布局计算是CSS引擎一次性完成的，比JS计算每张卡片位置快得多；但旧设备上，大量grid-column内联样式或频繁grid-template-rows重设会触发重排。
- 查CanIUse数据：要稳定用
minmax()+fr，最低支持到Chrome 66 / Firefox 61 / Safari 11.1 - 别试图用
@supports (display: grid)兜底——它测不出minmax()是否可用，得单独测@supports (grid-template-columns: minmax(0, 1fr))) - 真要兼容IE，只能降级为
column-count+break-inside: avoid，但列间无法对齐，且无法控制单张卡片跨列
复杂点在于：Grid能声明式描述布局，但Pinterest的核心是“高度驱动列堆叠”，这个逻辑CSS天生表达不了。能用Grid模拟出近似效果，是因为我们接受了“列高一致”这个妥协。真要一模一样，还是得回到JS方案——不是技术倒退，是问题域决定的。
