Playwright默认截图对比会漏掉Safari的flex塌陷，因其仅捕获最终渲染帧，而Safari 14–15对未设min-width的flex项目存在隐式截断行为——DOM结构完好但视觉塌陷，纯像素对比难以识别，须结合CSSOM布局树断言（如flex-basis、width、min-width）进行跨浏览器归一化比对。
直接结论：排版一致性不能靠肉眼比对，必须用像素级快照 + 布局树断言双轨验证；仅跑一次 Playwright 截图对比，漏掉 70% 的 Flex/Grid 渲染偏移问题。
为什么 Playwright 默认截图对比会漏掉 Safari 的 flex 塌陷？
Playwright 的 screenshot() 拍的是最终渲染帧，但 Safari 14–15 对未设 min-width 的 flex 项目有隐式截断行为——DOM 结构完好，视觉却塌了半行。这种“结构存在但布局失效”的问题，纯像素对比很难捕捉（尤其容差设高时）。
- 必须额外抓取布局树：
await page.evaluate(() => JSON.stringify(getComputedStyle(document.querySelector('div.flex-item')))) - 重点比对
width、flex-basis、min-width三个值，Safari 下常出现flex-basis: auto但width: 0px - 别信
getBoundingClientRect()—— 它返回的是已塌陷后的尺寸，不是原始计算值
如何用 CSSOM 数据做跨浏览器布局断言？
不同引擎对同一 CSS 规则的解析结果可能不同，比如 aspect-ratio: 16/9 在旧版 Chromium 返回 auto，而 Safari 返回 16 / 9。直接比字符串会误报，得归一化处理。
- 对数值型属性（
width、height、aspect-ratio），统一转为浮点数并保留 2 位小数：parseFloat(value) || 0 - 对
flex简写，拆解成flex-grow/flex-shrink/flex-basis单独比，避免 Safari 把flex: 1解析成1 1 0%而 Chrome 解析成1 1 0px - 用
page.emulateMedia({ reducedMotion: 'reduce' })切换媒体查询状态，验证响应式断点是否触发真实重排（不是仅改 class）
data-test-id 为什么不能解决排版一致性问题？
data-test-id 只能定位元素，无法描述其位置关系。两个按钮在 Chrome 里左右排列，在 Safari 里上下堆叠，但 data-test-id="submit-btn" 和 data-test-id="cancel-btn" 都存在且可见——测试就过了，实际体验已崩。
立即学习“前端免费学习笔记（深入）”；
- 必须补充空间关系断言：用
page.locator('button').first().boundingBox()和.last().boundingBox()比较x坐标差值，判断是否横向排列 - 表格单元格合并（
rowspan/colspan）需验证gridArea计算值，而非只查 DOM 属性 - 绝对定位元素要检查
getComputedStyle(el).position === 'absolute'是否生效，某些 WebView 会降级为static
真正难的不是拍图，而是理解浏览器怎么“想”——WebKit 的 flex 计算器和 Blink 的不完全等价，哪怕 HTML/CSS 完全一样。每次新增一个 display: grid 容器，都得重新校验所有子项的 grid-column-start 解析逻辑。这没法全自动，得靠人盯住关键路径的布局树 diff。
