兼容性分类：先搞清楚你要打哪些仗
聊兼容测试，我见过不少人一上来就列一大堆浏览器、设备清单，然后闷头开测。结果测到一半发现，花了大量时间验过的场景根本不出问题，真正痛的地方反而漏了。
为什么会这样？说白了，就是没先对“兼容性”本身做个分类。
你想想看，不同维度的兼容问题，它的根因、覆盖策略、排查手段其实差别很大。我个人习惯，先把兼容性拆成四个大类：浏览器兼容、操作系统兼容、设备兼容、分辨率兼容。这四类不是并列那么简单，它们之间还有交叉，但摸清了，你的测试策略就不会跑偏。
浏览器兼容：最绕不开的坎儿
浏览器兼容，估计是大家最早接触的一类。我刚入行时，总觉得浏览器兼容就是让页面在 Chrome 和 Firefox 上能打开就行。后来吃了几次亏才明白，它至少有三个层面。
1. 标准兼容
同一套 Web 标准，不同浏览器的实现进度和细节不一样。比如 CSS Grid 布局，Chrome 很早支持了，但老一点的 Edge 或某些移动端浏览器会渲染出奇怪的样子。
我建议做标准兼容测试时，别只看“支持/不支持”二元结论。 你可以用 Can I Use 查查特性覆盖度，但更实在的方法是把你的核心 UI 组件（比如表单、弹窗、表格）放到不同浏览器上截图对比。我用过类似 Percy 的视觉回归工具，效果不错。
2. 特性兼容
你以为你在用标准 API，但浏览器可能不认识。最常见的是 fetch 和 Promise，低版本 IE 完全不支持。
记住：Polyfill 能解决一部分问题，但不是万能的。我曾经有一个项目，使用 IntersectionObserver 实现图片懒加载，Polyfill 在 iOS Safari 上就是会爆内存。最后只能回退到 scroll 事件监听。
这类问题，用 Puppeteer 或 Playwright 写自动化脚本覆盖一下关键用户操作，比单纯加 Polyfill 靠谱得多。
3. 渲染差异
同一套 CSS，不同浏览器的计算方式有天壤之别。最典型的是 box-sizing，还有 flex 下的子元素溢出。我遇到过一次，Chrome 和 Safari 对 min-height: 100vh 的解析方式不同，导致页面滚动条差了一截。
| 浏览器 | 核心渲染引擎 | 常见差异化测试要点 |
|---|---|---|
| Chrome | Blink | Flex 布局、Grid、字体渲染、动画性能 |
| Firefox | Gecko | Canvas、渐变、CSS 变形、表单控件样式 |
| Safari | WebKit | 视口高度、滚动行为、p3 色彩空间 |
| Edge | Blink (新) | 同 Chrome，但需注意 IE 兼容模式 |
-webkit-overflow-scrolling，导致滚动容器内的 position: sticky 失效。后来加了个 Override 才解决。千万不能假设所有浏览器的滚动行为一致。
操作系统兼容：真正的战场在底层
浏览器兼容解决的是“上层 UI 的差异”，操作系统兼容解决的则是“底层 API 和运行环境的差异”。尤其当你开发的是桌面端应用、原生 SDK 或需要调用系统资源的 Web 应用时，操作系统兼容的影响比浏览器更大。
API 差异
不同操作系统提供的文件系统、网络栈、图形接口都不一样。例如 localStorage 的存储限额，Chrome 下一般有 5~10 MB，但在某些 Linux 发行版的 Electron 中，可能只有 2 MB 甚至更少。
我在 Windows 和 macOS 上跑同一个 Node.js 脚本，path.sep 一个返回 \\，一个返回 /，差点导致 CI 产物路径全部写错。
系统级特性差异
比如通知权限、后台任务、省电模式。如果你做的是一个实时通信或后台同步的应用，需要覆盖 macOS 的 Notifications 权限弹窗、Android 的 Doze Mode、iOS 的 Background App Refresh。这些不是简单的“过没过”，而是“超时多久后会被系统杀死”。
| 操作系统 | 关键测试维度 | 常见翻车点 |
|---|---|---|
| Windows | 文件路径、注册表、权限 UAC、字体渲染 | 路径分隔符、长路径限制、静默安装失败 |
| macOS | 沙盒机制、Gatekeeper、iCloud 同步 | 权限弹窗阻塞、应用签名不匹配 |
| Linux (Ubuntu/CentOS) | libc 版本、依赖库（glibc、openssl） | 动态链接库缺失、内核参数差异 |
| Android | Doze Mode、通知渠道、存储分区 | 后台服务被系统掐断、文件系统权限错误 |
| iOS | Background Fetch、推送 刷新 | 通知权限拒绝后不能再询问、后台任务超时 |
设备兼容：物理形态决定了体验
设备兼容不仅仅指“手机或平板”，它还包括屏幕形状、传感器、摄像头、触控方式……每一个硬件特性都可能成为软件表现的分水岭。
物理形态
刘海屏、挖孔屏、折叠屏、全面屏手势——这些不仅是 UI 适配问题，更是交互逻辑的断层。你在 iPhone 12 上很流畅的滑动操作，到了 Galaxy Z Fold 的折叠态，手势冲突几率大增。
嗯，这里要注意：设备表列得再多，也不如按“设备的物理特征”做分类。比如“是否有物理键盘”、“是否有实体 Home 键”、“是否支持压感触控”。一张分类表比几十个设备名有用得多。
硬件能力差异
GPU 渲染能力、内存大小、存储读写速度。WebGL 在高端手机上流畅跑 60fps，换到入门机上可能直接掉到个位数。摄像头分辨率不同，直接决定你图像处理的 Buffer 尺寸。这些必须在测试矩阵里体现出来。
设备碎片化
我之前统计过一个项目，2024年我们支持的 Android 设备型号超过 300 种，屏幕尺寸跨度从 4.7 寸到 7.6 寸。如果一一覆盖，团队半年都测不完。
后来我改成了按“屏幕物理分辨率 + DPI 组合”分类，比如“1080p + xxhdpi”、“2K + xxxhdpi”，配合云测平台的设备池做扫描。效率至少翻了一倍。
分辨率兼容：不是盯着像素数
分辨率兼容，很多人直接理解为“窗口多大就适配多大”。没那么简单。真正的分辨率兼容，包含三个东西：物理分辨率、逻辑分辨率、视口宽度。
物理 vs 逻辑
一个 1080p 的手机屏幕，物理分辨率是 1920x1080，但逻辑分辨率可能是 360x640。浏览器渲染用的是逻辑分辨率。测试时要看的是逻辑分辨率下的布局表现，而不是物理像素。
我见过最离谱的一个bug：设计师给了 375x812 的设计稿，开发直接用 px 写死尺寸，结果在 iPhone 8 Plus（逻辑分辨率 414x736）上布局全崩。这就是没搞清楚分辨率分层。
响应式断点
常用断点：320px / 480px / 768px / 1024px / 1440px 等。但别忘了“竖屏 vs 横屏”。平板上竖屏是 768px，横屏是 1024px，这两个视口下的组件布局策略完全不同。
| 场景 | 视口宽度 (逻辑) | DIP (设备无关像素) | 测试重点 |
|---|---|---|---|
| 手机竖屏 | 320 - 480 | 360 - 414 | 单列布局、字体大小、按钮间距 |
| 手机横屏 | 640 - 896 | 812 - 896 | 导航栏折叠、图片裁剪、键盘弹出行为 |
| 平板竖屏 | 768 - 1024 | 1024 - 1366 | 多列布局、侧边栏、模态框宽度 |
| 平板横屏 | 1024 - 1366 | 1366 - 1680 | 分屏模式、浮动按钮、表格列数自适应 |
四类兼容性的关系图谱
这四类兼容性不是孤立的。一个真实的兼容问题，往往是多个维度叠加的结果。比如：某个 Android 设备（设备维度）+ 系统版本 Android 11（操作系统维度）+ 使用 WebView 加载 H5 页面（浏览器维度）+ 屏幕分辨率 1080x1920（分辨率维度）。
测试的时候，需要有一个清晰的策略矩阵来对齐这些维度。下面这张图，你可以看到它们之间的交互关系。
你看，这四类兼容性不是孤立存在的。兼容测试矩阵的核心，就是把「用户真实使用场景」拆解为这四个维度的交集。测试策略的制定，就是不断问自己：这个场景，到底受哪几个维度影响？优先级如何排？
搞懂了分类，你才能针对性地去造测试数据、选测试工具、定通过标准。否则就是大炮打蚊子，看起来很热闹，实际效率很低。