点一次就变大一点？CSS 循环尺寸依赖的隐蔽陷阱

正常情况：尺寸单向流动#

一个健康的布局，尺寸计算是单向的：

1
Grid 列宽 → 元素宽度 → aspect-ratio 算出高度 → 确定 Grid 行高 → 结束

每一步的输出是下一步的输入，没有回路，一次 layout pass 就能稳定。

出问题的情况：闭环#

当子元素加了 height: 100%，尺寸流向出现了一条反向路径：

1
Grid 行高 → height:100% 拉伸子元素 → 子元素内部 aspect-ratio 重算高度 → 影响 Grid 行高
2
     ↑                                                                        |
3
     └────────────────────────────────────────────────────────────────────────┘

这是一个闭环。Grid 行高既是输入也是输出。

为什么桌面浏览器没事#

我没有读过 Blink/WebKit 源码，下面是基于 CSS 规范和实测现象的推断，不是定论。

CSS 规范在处理 aspect-ratio 与显式 height 共存时有优先级规则：当 height 是 “definite”（确定值）时，aspect-ratio 让位。问题在于 height: 100% 在父高未定的 Grid cell 里不一定算作 definite——这是一个边界 case，规范本身留了模糊空间。

桌面 Chrome 看起来在这个边界 case 上做了某种首次解算后就锚定的处理：第一次 layout 算出的高度被视为最终值，后续 re-layout 不再重新解算这个闭环。注意”看起来”——我没有验证源码，只是没观察到累积现象。

为什么移动端 webview 出问题#

观察到的事实是：

• iOS WKWebView 和 Android Chromium-based WebView 的内核版本通常落后于桌面 Chrome 数个大版本
• aspect-ratio 作为相对较新的属性，在老内核上的边界行为没有完全对齐最新规范
• 在受影响的 webview 上，每次点击触发的 re-layout 会重新解算闭环，而不是使用首次锚定的值

至于为什么”每次重算之后值会变大而不是变小或不变”，我的猜测是亚像素取整方向不对称：

1
计算值 123.45px → ceil 取整 → 124px
2
下一轮以 124px 为输入 → 算出 124.x px → 再 ceil → 125px

如果取整方向是 ceil（或者 round 在某个边界上偏向上），闭环就不收敛。

这是猜测。要证实需要在 webview 内核里 print 每轮的中间值，我没做这件事。文章给出的修复方法不依赖于这个解释正确——只要打断闭环，无论取整方向如何，问题都不会发生。

如果你恰好读过相关源码或做过精确测量，欢迎告诉我真实机制。

改动一：移除 height: 100%#

1
<div class="card" style="height: 100%; width: 100%;">
2
<div class="card" style="width: 100%;">

子元素不再拉伸到 Grid 行高，而是由内容自然撑高。Grid 行高仍然由最高的 cell 决定，但 cell 内部不再反向依赖行高。

那同行卡片的等高效果会丢吗？不会。 Grid item 默认的 align-self: stretch 会让 cell 自身被拉到行高，等高效果由 grid 的对齐机制保留，不需要在内部用 height: 100% 强行拉伸。这两者看起来在做同一件事，区别在于：前者是 grid 容器单向指派高度给 cell，不形成闭环；后者是 cell 内部反向索取行高，形成闭环。

改动二：移除冗余的 aspect-ratio#

1
<div class="image" style="width: 100%; height: 100%; aspect-ratio: 0.77;">
2
<div class="image" style="width: 100%; height: 100%;">

父级已经用 aspect-ratio 约束了比例，子级用 width: 100%; height: 100% 填充即可。重复声明 aspect-ratio 不是”双保险”，而是给布局引擎制造歧义——尤其是当 height: 100% 和 aspect-ratio 同时存在时，不同引擎的优先级处理可能不一致。

两行改动，闭环断开，尺寸变回单向流动，问题消失。

1. 画尺寸依赖图，确认没有环#

遇到布局异常时，把每一层元素的宽高来源画出来。如果发现某个值既是上游的输出又是下游的输入，就找到了嫌疑点。

1
✅ 单向：容器宽 → aspect-ratio → 高 → 结束
2
❌ 闭环：容器宽 → aspect-ratio → 高 → height:100% → 反推容器高 → 影响行高

2. 重复声明同一约束不是”双保险”，是引入歧义#

aspect-ratio、min-height、max-width 这类约束，在父子元素上只应出现在一个层级。很多人下意识觉得”父子都写一遍更保险”，其实恰恰相反：当 layout 引擎遇到两个本该相等的来源时，需要决定哪个优先，而不同引擎、不同版本的优先级处理可能不一致。双保险在 CSS 里通常是双歧义。

3. 警惕 height: 100% + aspect-ratio 的组合#

这两个属性同时出现在一个元素上时，语义是矛盾的：

• height: 100% 说”高度跟父级走”
• aspect-ratio 说”高度由宽度算”

规范有优先级规则，但取决于父高是否 definite，而 Grid/Flex 容器里的”父高 definite 性”本身就是个绕口的话题。能避免就不要同时出现。

4. 移动端 webview 是另一个世界#

桌面浏览器通过的布局，在移动端 webview 不一定稳定。特别是微信小程序、各厂商 Android WebView（版本碎片化严重）、嵌入式 WKWebView。涉及 Grid/Flex + 百分比高度 + aspect-ratio 的组合时，真机验证是唯一可靠的测试，模拟器过了不算数。