纯截图对比会漏掉safari的flex塌陷，因playwright仅捕获最终渲染帧，而safari 14–15对未设min-width的flex项目存在隐式截断——dom完好但视觉塌陷，像素对比无法识别；必须结合cssom布局树断言width、flex-basis、min-width等值，并归一化处理跨引擎差异。
为什么纯截图对比在Safari上会漏掉Flex塌陷
Playwright的screenshot()只捕获最终渲染帧，但Safari 14–15对未设min-width的flex项目存在隐式截断行为：DOM结构完好，视觉却塌陷半行。这种“布局失效但元素仍存在”的问题，像素级对比无法识别——尤其当容差设为0.1或更高时，差异被自动抹平。
必须配合CSSOM数据验证，否则70%以上的Flex/Grid偏移问题会被跳过。
- 别依赖
getBoundingClientRect()：它返回的是已塌陷后的尺寸，不是原始计算值 - 优先用
getComputedStyle(el)抓取width、flex-basis、min-width三个关键属性 - 对
flex简写值要拆解比对：flex: 1在Safari可能解析为1 1 0%，Chrome则为1 1 0px，直接字符串比对必误报
如何用CSSOM做跨浏览器布局断言
不同引擎对同一CSS规则的解析结果可能不同，比如aspect-ratio: 16/9在旧版Chromium返回auto，Safari返回16 / 9。直接比字符串会失败，必须归一化处理。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 数值型属性（
width、height、aspect-ratio）统一转为浮点数并保留2位小数：parseFloat(value) || 0 - 对
flex、grid-area等复合属性，拆成原子字段单独断言 - 绝对定位元素要检查
getComputedStyle(el).position === 'absolute'是否生效，某些WebView会降级为static - 表格
rowspan/colspan需验证gridArea计算值，而非仅读DOM属性
data-test-id无法替代空间关系断言
data-test-id只能确认元素存在且可见，不能描述其相对位置。两个按钮在Chrome里左右排列，在Safari里上下堆叠，只要data-test-id="submit-btn"和data-test-id="cancel-btn"都存在，测试就通过——但实际UI已崩。
- 必须补充空间关系断言：
page.locator('button').first().boundingBox()与.last().boundingBox()比较x坐标差值，判断是否横向排列 - 用
page.emulateMedia({ reducedMotion: 'reduce' })切换媒体查询状态，验证响应式断点是否触发真实重排（不是仅改class） - 对浮动、sticky、transform等影响布局的属性，要结合
offsetParent和getComputedStyle交叉验证
CI中如何避免Docker容器内截图失真
Docker默认不启用字体抗锯齿和GPU加速，导致Playwright截图在容器中丢失细节，尤其影响文字边缘和阴影渲染，造成误判。
- 启动浏览器时显式启用
--disable-gpu反而会加剧失真，应改用--use-gl=swiftshader或--enable-unsafe-webgpu（视基础镜像而定） - 确保容器内安装了
fonts-liberation和ttf-dejavu，否则中文/图标字体回退到无衬线体，布局宽度突变 - 在
playwright.config.ts中固定viewport并禁用deviceScaleFactor，避免Docker环境因缩放因子不一致引发渲染偏移
真正难的不是拍图，而是理解浏览器怎么“想”——WebKit的布局树生成逻辑和Chromium并不等价，光靠locator可见性断言远远不够。你得同时看DOM、CSSOM、布局树三者是否在各引擎下达成一致，缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
