3、主流平台概览：市场份额与特性差异
做跨平台兼容测试，第一件事就是搞清楚——你的用户到底在用什么设备、什么系统、什么浏览器？我入行那会儿，光盯着 Windows + Chrome 测，结果一到上线，iOS 用户反馈按钮点不了、Linux 用户字体裂了……从那以后，我养成了一个习惯：每次启动新项目，先拉一份平台分布数据，贴在工位上。
这一章，咱们就把几个主流平台的“家底”翻一翻。不指望你记住所有数字，但核心差异、哪些坑容易踩，必须心里有数。
3.1 桌面三巨头：Windows、macOS、Linux
Windows：绕不开的主力
市场份额常年占桌面端的 70% 以上。别管你喜不喜欢，用户大多数都在 Windows 上。我个人习惯把 Windows 测试分成三个层次：
- Win 10/11（最新内核）：当前主力，覆盖超 80% 的 Windows 用户。
- Win 7/8.1：还在零星存活，尤其工业、医院、政府系统里。
- Win Server 版本：有些内部管理系统跑在 Server 版上，测试时别忘了。
特性差异方面，Windows 的字体渲染依赖 DirectWrite，所以同样的网页在 Windows 和 macOS 上，文字精细度完全不同。我遇到过客户投诉“字模糊”，结果只是默认字体不同而已。
device-pixel-ratio 逐级修。
macOS：设计团队的最爱
占比约 15%–20%，但集中在创意、教育、开发群体。如果你做面向设计师或程序员的工具，macOS 的优先级反而更高。
- macOS Ventura / Sonoma 及以上：当前主流。
- Intel vs Apple Silicon（M1/M2/M3）：架构差异会导致某些原生应用表现不同。
macOS 用 Core Text 渲染字体，比 Windows 更圆润、更接近印刷效果。嗯，这里要注意：在 macOS 上，-webkit-font-smoothing: antialiased; 可能会让细字体变得更细，反而不清晰。我之前帮一个团队排查“字体发虚”的 bug，最后发现是他们全局加了这条 CSS，但在 Chrome for Mac 上过度抗锯齿了。
Linux：小众但硬核
桌面份额不到 3%，但服务器、嵌入式、DevOps 环境里它是王者。做兼容测试时，我建议至少覆盖 Ubuntu 20.04 LTS 和 Fedora 最新版。
- 发行版差异：不同发行版用的库版本、默认 shell、桌面环境都不同。
- 字体缺失：很多 Linux 默认没装中文字体，网页上的中文字符会回退成“豆腐块”。
font-family 回退栈：-apple-system, 'PingFang SC', 'Microsoft YaHei', 'WenQuanYi Micro Hei'，这样在 Linux 下也能优先匹配开源中文字体。
3.2 移动双雄：Android & iOS
| 对比项 | Android | iOS |
|---|---|---|
| 全球份额 | ~70%（不同地区浮动大） | ~28%（高收入地区更高） |
| 最新版本 | Android 14（碎片化严重） | iOS 17（升级率极高） |
| 浏览器引擎 | Chromium 内核（WebView 自定义空间大） | 只允许 WebKit（Safari / 所有 iOS 浏览器） |
| 屏幕尺寸/密度 | 百花齐放：360×640 到 1440×3120 | 相对统一：主要 6.1" / 6.7"，Plus / Pro 系列 |
| 硬件特性 | RAM 2GB–16GB，CPU 架构各异 | RAM 4GB–8GB，统一 ARM 架构 |
Android 的碎片化是测试噩梦。我统计过，一个普通 App 需要覆盖至少 15 种主流分辨率、5 个 API 级别（26–34）。iOS 则好很多：只测 iPhone 12～15 系列，加上 iPad 几个主要尺寸，基本能覆盖 90% 的设备。
还有一个坑：通知权限、后台运行策略、电量管理。Android 各家 ROM（MIUI、ColorOS、One UI）对省电策略的差异极大，闹钟、推送、定位功能很容易被 kill。我曾经一次上线后，小米用户反馈“闹钟不响”，原因是系统把后台进程冻结了。嗯，之后我在兼容计划里专门加了一条：“至少覆盖华为、小米、OPPO、三星四家的旗舰机型。”
3.3 Web 浏览器：Chrome、Safari、Firefox、Edge
Web 兼容测试的核心是浏览器引擎。为什么？因为它决定了 CSS、JavaScript、DOM 行为的差异。下面是四个主流浏览器的市场占比和引擎信息：
| 浏览器 | 全球份额（桌面+移动） | 渲染引擎 | JS 引擎 |
|---|---|---|---|
| Chrome | ~65% | Blink | V8 |
| Safari | ~18% | WebKit | JavaScriptCore |
| Firefox | ~3% | Gecko | SpiderMonkey |
| Edge | ~5% | Blink（Chromium 化后） | V8 |
核心结论： Chrome 和 Edge 现在的行为基本一致（同 Blink + V8），所以兼容测试可以合并为“Chromium 系”。但 Safari 永远是最大变数——它的 WebKit 实现常常滞后、或有意不按标准来。我每次发版前，都会把 Safari 作为第一个测试目标，因为它最容易爆雷。
具体来说，你在不同浏览器里要重点测这些方面：
- CSS 网格和弹性布局：Safari 对
gap属性的支持历史、subgrid的支持度都慢半拍。 - JavaScript 新特性：比如
Array.flat()、Optional Chaining，Edge 和 Chrome 基本同步，Firefox 稍慢，Safari 最慢。 - 媒体查询与设备像素比：不同浏览器对
@media (-webkit-min-device-pixel-ratio: 2)等前缀支持不一致。 - Web 字体格式：woff2 现在都支持了，但遇到大量 emoji 或特殊字形时，Firefox 和 Safari 可能有渲染差异。
clip-path: inset(50% round 16px)，Chrome 和 Edge 显示完美，Safari 直接不生效。最后查了 CanIUse，发现 Safari 14 才支持 round 关键字，而我们的用户里还有大量 iOS 13 设备。解决方案是加 clip-path: inset(50%); border-radius: 16px; 降级处理。
3.4 平台特性差异速览图
下面这张图把六个平台的主要“性格”概括了一下，方便你对照。记住：测试不是要测遍所有设备，而是根据你的用户画像，找到最高风险的组合。
3.5 如何制定自己的平台优先级
光知道这些数字不够，你得学会“翻译”成测试计划的权重。我个人习惯用这样一个三步法：
- 拉数据：Google Analytics / Firebase / 自家埋点，看真实用户分布。
- 定核心：找出份额前三的平台作为“必全覆盖”清单。
- 加长尾：挑 2–3 个低份额但高风险（比如 Safari + iOS）的作为“验证清单”。
举个具体的例子： 假设你的产品是一个 B 端 SaaS 后台。
- 核心清单：Windows 10 + Chrome 最新版（主）；Windows + Edge（辅）
- 验证清单：macOS Ventura + Safari（看看设计稿）、Ubuntu 22.04 + Firefox（看看字体和布局）
- 移动端：如果用户会通过手机看报表，那再加一个 iOS Safari + Android Chrome（1080p 主流机）
这样做，你 80% 的精力花在覆盖 90% 的用户上，剩下 20% 去堵主要雷区。我在很多项目里用这个分组法，上线后兼容质量问题减少了一半以上。