企业官网建设流程全解析

做Web开发这些年，几乎每个项目都会在同一个地方被绊倒——浏览器兼容性测试。页面布局错乱、点击没反应、文件下载失败，这些破事排查起来比写代码还耗时间。这篇文章把我自己测试方案的完整思路整理出来，从测试矩阵怎么搭、工具链怎么选，到常见的兼容性问题怎么定位和解决，既有面向新手的实操步骤，也有适合开发团队直接落地的流程框架。不管你是刚入行的前端新手，还是需要牵头搞兼容性治理的技术负责人，照着这个方案都能少踩不少坑。

1. 先想清楚：兼容性测试到底要覆盖哪些方面

1.1 问题本质：不是"能不能打开"这么简单

很多新手理解兼容性测试，就是拿几个浏览器打开网站看两眼。实际上兼容性问题通常分三层。

第一层是渲染层。现在的浏览器虽然都遵循W3C标准，但背后的渲染引擎并不一样：Chrome和Edge用的是Blink，Firefox用Gecko，Safari用WebKit，老一点的IE用Trident。同一个CSS属性，在不同引擎里的解析结果可能差一大截。比如flex弹性布局在IE11里有一堆坑，grid布局在老Edge里支持不全，position: sticky在部分旧版浏览器里直接失效。这就好比同一句话用普通话、上海话、广东话说出来，意思一样但味道完全不同。CSS前缀-webkit-、-moz-很多时候就是为了让不同引擎"听懂"你的代码。

第二层是API层。JavaScript引擎对各种Web API的支持进度不一样。localStorage、sessionStorage现在大家都支持了，但Service Worker、WebRTC、WebGL 2.0、IntersectionObserver这些相对新的API，在不同浏览器里的支持情况差别很大。最典型的是WebRTC，做Web端实时视频的时候，Chrome和Firefox对H.264/VP8编码的支持策略就不一样，同一个视频流在有的浏览器里能播，在有的浏览器里画面直接黑屏。

第三层是浏览器策略层。这个最容易被忽略。比如浏览器的安全策略——老旧的TLS 1.0协议现在会被浏览器标记为"非安全协议"，Chrome和Edge打开这类站点时会给出"不安全"警告，点开之后提示"协商的TLS 1.0是非安全协议，只有在为了实现向后兼容性时才受支持"。再比如Cookie的SameSite属性，新策略默认限制了跨站携带Cookie，导致有些旧网站登录态直接失效。还有自动播放策略：为了让用户不被突如其来的音频打扰，Chrome和Safari都限制了带声音的视频自动播放，你依赖自动播放播视频的页面，在移动端Safari里就会直接不播。

我在实际项目里遇到最坑的一次，是后台管理系统在Chrome里一切正常，换到客户内网的一个基于老版本Chromium内核的浏览器里，表格渲染错位、导出Excel按钮点了没反应。排查到最后发现是用了Array.prototype.flatMap这个较新的API，老内核不支持导致整个模块抛异常。所以兼容性测试的核心工作，不是看页面"能不能打开"，而是验证每个功能模块在目标浏览器环境里能不能正常交互、正常输出。

1.2 测试边界怎么划定

很多人一上来就想把市面上所有浏览器版本都测一遍，这既不现实也没必要。正确做法是先划定"测试边界"，也就是你的项目需要在哪些浏览器环境里可用。

我一般建议分三个等级来定边界。第一优先级是主流现代浏览器：Chrome最新版、Edge最新版、Firefox最新版、Safari最新版，加上移动端的iOS Safari和Android Chrome。这几个环境作为日常开发和自测的最低标准。第二优先级是企业环境中的旧浏览器：比如客户还在用的Chrome 80+、旧版Edge、甚至IE兼容模式。企业内网项目经常要面对这类环境，因为业务流程绑定在老旧浏览器上，不是你想升级就能升级的。第三优先级是特殊场景浏览器：嵌入式设备里自带的浏览器、电视盒子内置的WebView、车载系统浏览器等，这些环境网络能力弱、内核版本老、没有调试工具，需要单独拿真机测。

判断优先级的方法很简单：看统计数据，但不要只看全球份额，要看自己产品的用户群。做公网产品，就看站点统计里的浏览器占比；做企业内网系统，就去问运维同事客户实际用的浏览器版本。把占比前5到8名的环境列出来，再结合业务场景，这才是你真正要测的矩阵。用猜测的方式去定矩阵，测试成本会花在没意义的组合上。

1.3 兼容性不单指"能打开"

这里必须多说一句：兼容性测试不是"页面能打开就通过"。我见过太多测试报告，结论写"兼容性正常"，实际上只测了首页加载和登录。真正的兼容性测试要覆盖功能性、视觉一致性、可用性和性能四个方面。

功能性验证表单能不能提交、按钮能不能触发、接口返回的数据能不能正确渲染。视觉一致性验证布局是否错乱、字体是否一致、间距是否符合设计稿。可用性验证交互流程是否顺畅，比如弹窗位置、下拉菜单展开后的走位。性能验证在低配机器或者慢网速下页面是否卡顿、内存占用是否异常——很多浏览器在开着开发者工具或者挂了一堆插件的情况下，性能和功能表现完全不同，这个后面细讲。这四个维度缺一个，都不能说这个浏览器环境是"兼容"的。

2. 工具链这样搭：免费方案与自动化选型

2.1 手工测试为主、自动化辅助：大多数团队的现实选择

聊到测试方案，很多团队上来就问"我们要不要上自动化"。我的观点非常明确：浏览器兼容性测试，手工测试永远是地基，自动化是加分项，但绝不能被自动化反噬。

原因很简单。兼容性问题往往是"意外"的，自动化用例覆盖的是你预料中的功能点，而兼容性Bug往往出现在你预料之外的角落。比如某个CSS属性在国产浏览器内核优化上表现不同，或者某个字体在Windows和macOS下的渲染高度不同，自动化脚本很难发现，人眼扫一遍反而能看出来。我见过一个团队花了两周搭自动化框架，自动跑了几百条用例，最后真正的兼容性问题还是靠手工点出来的。

那自动化什么时候值得上？我总结下来就两类：一是项目有明确的多浏览器回归需求，每次发版都要在5个以上浏览器环境跑核心流程，手工跑一遍要半天，自动化能在20分钟内跑完核心用例；二是做视觉回归，用截图对比工具在不同浏览器里做像素级差异检查，对手工测试是很好的补充。如果你只是做个中小型站点，或者团队就三五个人，先把手动方案跑通，等业务稳定了、发版频率高了，再逐步上自动化。

2.2 本地手工测试工具：DevTools、离线安装包、Edge IE模式

本地手工测试要准备的基础工具，门槛很低，效果也很直接。我日常用的搭配是这样的。

首先是Chrome和Edge的DevTools。两者都是Chromium内核，F12打开后功能几乎一致，重点用Device Toolbar设备模拟、Network面板、Performance面板。设备模拟可以快速切换主流手机和平板的分辨率，虽然只是模拟视口尺寸，不是真实渲染内核，但用来快速排查响应式问题非常高效。

然后是浏览器的版本隔离。Chrome和Edge本身不支持多版本共存，但可以用离线安装包把不同版本装到不同目录，或者用Selenium管理多版本驱动。更省事的方式是用不同的user-data-dir参数启动多个Chrome实例，这样能在同一个机器上同时开不同配置的浏览器环境，排查插件或扩展冲突时特别好用。我在处理"装了插件就崩、卸载插件就好"的问题时，就是靠多实例对比定位的。

还有一个被很多人忽略的工具：Edge浏览器的IE模式。虽然IE已经停止维护，但很多企业内网系统还在用，Edge的IE模式可以在不安装老IE的情况下模拟Trident内核的渲染行为。开启方法：Edge设置→默认浏览器→允许在Internet Explorer模式下重新加载网站。这个功能我在给制造、金融行业客户做老旧系统兼容性验证时经常用，实测对评估历史页面非常有参考价值。

2.3 自动化与云真机：什么时候引入、怎么配合

自动化方案里，现在用得最多的是Playwright、Selenium、Puppeteer这三类。我的建议是：新项目优先Playwright，老项目Selenium顺手就接着用，Puppeteer适合做爬虫和截图，不太适合直接做全功能的兼容性测试框架。

Playwright好用的点在于原生支持Chromium、Firefox、WebKit三种引擎，一条命令能在不同引擎里跑同一套用例，自动等待机制和元素定位能力都很强。Selenium虽然老，但生态庞大，国内很多测试平台基于它封装，如果团队已经积累了一堆Selenium脚本，没必要硬切。选型核心不是比谁先进，而是看谁的维护成本低、团队上手快。

云真机平台方面，BrowserStack、Sauce Labs这类服务可以在一堆真实设备上跑测试，但收费不便宜。我的建议是：预算有限的情况下，优先保证真实设备覆盖关键系统——一台iPhone、一台Android、一台Windows PC、一台Mac，这四类设备在关键功能上的手工验证，比在云平台跑上百个模拟器都有价值。可以用一个表简单对比：

3. 从测试矩阵到执行：一步步跑通全流程

3.1 测试矩阵怎么设计

测试矩阵就是一张表格，横轴列浏览器环境，纵轴列功能模块或测试用例，交叉点填测试结果。这张表是兼容性测试的核心资产，矩阵设计得好不好直接决定测试的覆盖度。

我推荐按这个过程来设计。第一步确定环境列表：把统计里占比靠前的浏览器版本、操作系统、设备类型列出来。第二步确定版本策略：桌面浏览器覆盖最新版加上一个主版本，移动端覆盖iOS Safari和Android Chrome的最新两个大版本。第三步按场景分优先级：P0场景（登录、注册、核心业务流程、支付）、P1场景（主要页面渲染、表单操作）、P2场景（边缘功能、样式细节、打印导出）。优先级决定测试投入的资源。

举个例子，我之前做过一个企业级Web管理后台，矩阵是这样设计的：

这个矩阵覆盖了主力用户、企业内网老环境、移动端三大类场景，9个环境组合看起来不多，但每个组合跑完核心用例要半天，加起来是三天工作量，所以必须靠优先级来排计划。矩阵设计里最容易犯的错是只写浏览器名，不写版本和设备组合。"Chrome"到底是Windows还是Mac？版本是120还是130？不写清楚，测试结果就没有参考价值。

3.2 核心场景清单：别漏掉这些角落

兼容性测试不能只围着"正常流程"转，我整理了一份高频问题清单，分享出来供你直接参考。

布局渲染：多分辨率响应式布局（375px手机、768px平板、1366px笔记本、1920px大屏）、长文本换行、图片加载失败时的占位状态、字体在不同操作系统下的显示效果。

表单交互：输入框焦点态、下拉框展开/收起、日期选择器、文件上传（尤其是大文件）、表单校验提示。容易被忽略的是input[type="file"]在不同浏览器里的样式和触发行为差异。

媒体与文档：视频播放（自动播放策略、编解码支持）、音频、PDF打印。打印这块单独强调一下，@media print样式在不同浏览器里表现天差地别，页眉页脚设置、分页位置、背景色打印不出来，都是高频问题。

存储与缓存：localStorage、sessionStorage的容量和行为差异，Cookie的SameSite属性，Service Worker缓存清理。我遇到过Edge浏览器因为Service Worker缓存没更新，新版页面发布后用户还看到旧页面，排查了很久。还有服务端缓存配置不当的情况，比如Nginx没设置好Vary头，同一个URL在不同浏览器下返回了错误的缓存版本，这类问题在Linux服务器上特别常见。

安全与登录：HTTPS证书策略、TLS版本警告、OAuth登录跳转、短信验证码自动填充。特别提一下iOS浏览器唤起安装App的场景：如果用Universal Link或Scheme跳转，Safari和微信内置浏览器对Scheme的拦截策略不一样，经常出现"iOS浏览器打不开App"的反馈，必须实测。

3.3 四个执行阶段：冒烟、功能、专项、回归

整个兼容性测试流程，我习惯拆成四个阶段，每个阶段的投入和门槛不一样。

冒烟测试阶段：在目标矩阵的每个浏览器环境里，跑一遍"打开首页→登录→进入核心模块→退出"这条最简路径，确认基本环境可用性。冒烟不过说明这个环境有致命问题，优先排查，而不是继续跑后面的大用例。

功能测试阶段：按功能模块逐块完整走一遍，记录布局、交互、样式、性能各方面问题。这个阶段最花时间，建议每个环境安排一个人，或者一个人按环境串行跑，关键是每个问题都要截图、录屏留证，标明复现的环境组合和操作步骤。

专项测试阶段：针对上面发现的问题做定向深挖。比如某个模块在Firefox里下拉框点不开，就在Firefox里反复验证，配合DevTools的Console和Network面板看报错。这个阶段重点是定位根因：是CSS兼容、JS API不支持，还是接口数据格式问题。

回归测试阶段：开发修完Bug后，针对修复模块和受影响的相关模块做回归。这里要特别强调：回归不能只在你之前发现Bug的那个浏览器里测，要在整个矩阵里跑一遍——修Bug过程中，开发经常把另一个浏览器的行为改坏。我踩过太多次这个坑。

3.4 真实环境模拟：移动端与嵌入式设备

多数团队的DevTools模拟器只能模拟视口尺寸，模拟不了真实移动浏览器环境的渲染行为和硬件能力。移动端兼容性测试最少要在真实设备上过一遍核心流程。重点场景包括：iOS Safari底部工具栏遮挡问题、Android各厂商浏览器和WebView的差异、微信内置浏览器的页面跳转策略，以及上面提到的Scheme唤起App场景。

还有一个很多人不重视的场景是嵌入式设备里的浏览器。比如ESP32内嵌的Web页面，通过设备自带的Wi-Fi热点访问；或者门禁控制器、交换机的Web管理界面，用Chrome访问时提示需要安装插件，装好后浏览器后台没反应。这些设备的Web服务往往是为特定浏览器优化的，系统浏览器升级后功能就失灵。测试这类环境，一定要用真机实测，注意设备端Web服务器的HTTP响应头是否设置正确——缓存策略不对会导致页面一直是旧版本。

我建议做嵌入式设备测试时，至少准备一台Windows机器（装Chrome、Edge、Firefox）和一台Android手机，直接访问设备管理页面，验证登录、配置保存、固件升级这些核心功能。设备自带的Web管理页面通常没有自适应布局，用手机访问会变形，这类问题要在测试报告里明确标注"支持范围仅限定于桌面浏览器"。

4. 高频兼容性问题实录：排查思路与解决步骤

4.1 浏览器崩溃：status_access_violation类错误

STATUS_ACCESS_VIOLATION是Windows平台上一个出现频率很高的崩溃错误，常见于Chromium系浏览器。页面侧通常表现为：点击某个按钮后浏览器标签页闪退，或者整个浏览器直接崩掉，过一会弹出一个报错框。

我处理过的一个案例：客户反馈Chrome一打开系统的报表页面就崩溃，报错status_access_violation。排查第一步是确认是页面代码问题还是浏览器环境问题。用无痕模式打开相同页面，无痕模式下不崩溃，基本确定是某个扩展或插件引起；无痕模式同样崩溃，再进一步用清空站点数据或禁用硬件加速测试。

第二步看页面里是否用了太重的东西。WebGL渲染、超大Canvas绘图、WebAssembly计算这类高负载场景，在某些显卡驱动不完善的机器上容易触发崩溃。去chrome://gpu看硬件加速状态，或者用--disable-gpu参数启动浏览器测试，禁用GPU后正常，基本判定是渲染栈问题。

第三步检查浏览器版本和系统组件是否兼容。Windows更新补丁有时会破坏浏览器依赖的系统组件，这类问题最隐蔽，往往只能通过升级浏览器或回滚补丁解决。遇到崩溃问题，先让用户提供浏览器版本号和系统版本号，不要盲目猜页面代码。

4.2 安全策略引发的"兼容"问题

这一类问题特别容易和普通兼容性Bug混淆，因为表现形式都是"在我浏览器里显示不正常"。最典型的就是TLS版本警告。现在访问一些老旧站点，Chrome和Edge会提示"不安全"，点开之后会提示TLS 1.0是非安全协议。这不是前端代码问题，是服务端还开着TLS 1.0/1.1，浏览器出于安全策略给出的警告。处理方式是在服务器Nginx、IIS或Apache配置里禁用TLS 1.0/1.1，只启用TLS 1.2/1.3。

另一个高频场景是Mixed Content混合内容。页面本身是HTTPS，但里面引用了HTTP的图片、脚本或接口，浏览器默认拦截。新版Firefox从80版本开始直接阻止混合内容加载，Chrome也会在控制台报"Mixed Content"。这种问题不需要改代码，把资源地址换成HTTPS就能解决，排查时用Network面板过滤看有没有被Blocked的请求。

Cookie的SameSite策略是近两年最让人头疼的。旧策略下跨站Cookie默认允许携带，新策略默认Lax，跨站第三方请求不带Cookie。很多老项目做单点登录或跨域接口调用时登录态莫名丢失，就是这个原因。排查时在DevTools的Application面板看Cookie的SameSite字段，如果显示Lax或Strict，而业务确实需要跨站带Cookie，需要显式设置SameSite=None; Secure。这里要特别小心，设置不当会引入安全风险，生产环境改Cookie策略前一定要让安全同事评审。

还有一类和User-Agent相关的问题。很多后端逻辑用UA判断浏览器类型，比如"如果是微信浏览器就跳转H5页面"、"如果是iOS就弹窗提示下载App"。这种判断本身很脆弱，因为UA可以伪造——我见过有人直接用插件伪造微信浏览器的UA绕过手机号限制，导致业务逻辑被绕穿。排查UA相关问题，优先改成能力检测而不是硬编码UA字符串。

4.3 依赖浏览器能力的功能怎么排查

Web端实时视频、PDF在线预览、Excel在线编辑这类功能，因为依赖的浏览器能力比较深，出兼容性问题的概率很大。

WebRTC实时视频：不同浏览器的编解码支持有差异，Safari对VP8的支持到较新版本才比较好，Chrome和Firefox对H.264的支持策略也不一样。实现WebRTC时，建议在信令协商阶段把编解码能力检查加上，优先选择双方都支持的编码。用户报告"对方能看到我，我看不到对方"这类问题时，先别改服务器，从getUserMedia权限、RTCPeerConnection建连日志、ICE候选这三个维度排查。

PDF打印：页面打印功能在不同浏览器差异很大。Safari打印默认不带页眉页脚，Chrome打印默认带URL和日期，Edge又不相同。@media print样式在Chrome写好，拿到Firefox里分页位置就变了。做打印兼容性测试时，我建议准备一份包含表格、图片、长文本、超链接的测试文档，分别在Chrome、Edge、Firefox、Safari里打印成PDF，检查四个维度：内容是否完整、分页是否合理、背景色是否正确保留、网页URL是否出现在页面上。

在线文档处理：浏览器环境没有Node.js的完整能力，很多依赖polyfill的库在不同浏览器里行为有问题。用这类库时，测试要覆盖生成、预览、下载、解析四个环节，重点看中文乱码和样式丢失——这个我在好几个项目里踩过，生成的文件用Word打开正常，用WPS打开就乱版。

4.4 插件与本地服务：最让人头大的场景

浏览器插件、ActiveX控件、本地服务程序之间的兼容问题，是企业Web项目里最让人头疼的一类。

典型场景是门禁系统的Web端，需要安装本地服务插件，装好后浏览器后台却没反应。这个问题分两部分：一是插件架构，新版Chrome已经不支持NPAPI，只支持PPAPI或者通过本地Web服务中转，所以很多厂商改成了"浏览器访问管理页面，页面向本地服务发请求，本地服务连接硬件设备"这种架构。这种架构下的兼容性问题，90%出在本地服务的端口监听状态、防火墙拦截和浏览器的混合内容策略上。

排查流程我一般这么走：第一步，用netstat -ano | findstr 端口号确认本地服务进程是否在监听；第二步，直接在浏览器地址栏访问本地服务地址（通常是http://127.0.0.1:端口号），看能不能返回JSON或页面；第三步，打开DevTools的Console，看是否有跨域报错——本地服务默认不允许跨域，页面一般需要在服务端加CORS头或者通过代理转发；第四步，检查浏览器的"不安全内容"设置是否允许加载，本地HTTP请求在HTTPS页面下会被当作Mixed Content拦截。

另一个常见场景是"浏览器打开本地程序"。网页通过自定义协议（如myapp://open?id=123）唤起本地App，Windows依赖注册表协议处理器，Android/iOS依赖Intent或URL Scheme。测试时要在不同浏览器里验证：Chrome会先弹确认框"此站点要打开xxx应用程序"，Edge类似，Firefox可能直接拦截。弹窗样式不同，用户容易误点，产品设计上最好有明显引导。遇到"网页提示打开应用但没反应"的问题，先检查系统是否注册了协议处理器，再看浏览器策略有没有拦截外部协议。

还有一类和"网页似乎有问题"相关的提示，比如Edge打开某些本地调试页面时显示"edge://iwa-dev/ 上的网页似乎有问题，或者可能已永久移动到新的WEB地址"。这个一般是页面JS抛了未捕获异常，或者页面根本不存在。开发时用内置浏览器Debug也会遇到类似问题——内置浏览器和真实浏览器环境有差异，某些API调不到或报错，这时候优先用系统默认浏览器做对比测试，别只依赖内置浏览器下结论。

5. 团队落地建议：用例库、检查清单与避坑指南

5.1 建立用例库与发布检查清单

兼容性测试最怕"这次测了，下次忘了"。我强烈建议把兼容性测试沉淀成用例库和发布检查清单。

用例库按模块拆分，每个模块的用例都要标记适用环境。比如登录模块在IE模式下要额外验证加密库的兼容性，报表模块在Firefox里要验证Canvas渲染，打印模块在Safari里要验证分页效果。用例库维护在Wiki、TestLink或文档工具里都可以，关键是每条用例都要有环境标注和预期结果。

发布检查清单是发版前必须执行的硬门槛。精简版长这样：确认测试矩阵里所有P0场景通过；确认没有未解决的视觉错乱问题；确认控制台没有报错，特别是Mixed Content和API not defined；确认打印与导出功能在所有目标浏览器可用；确认文件上传下载正常；确认安全策略相关警告已处理。这张清单在CI/CD流水线里可以做成手工确认项，也可以和自动化冒烟测试打通，发版时强制检查。

5.2 哪些坑我踩过，希望你别踩

第一坑：只用Chrome开发和自测，其他浏览器等用户反馈了才测。一个项目在Chrome里开发了两周，各种效果都用上了，最后拿到Firefox里布局全乱，返工成本极高。正确姿势是开发阶段就在三个主流内核里并行看效果，每天花十分钟切浏览器检查一遍。

第二坑：把浏览器版本升级当成唯一的解药。遇到兼容性问题就建议"让用户升级浏览器"，这在个人产品里可行，在企业项目里完全行不通——客户的内网环境受控，不能随便升级。更合理的做法是提前和客户确认固定的浏览器版本，针对性兼容，或者做代码层面的降级方案。

第三坑：忽略性能兼容性。有的页面Chrome里跑得很流畅，在低端Android WebView里卡成PPT。这不是功能Bug，但用户体感是"网站不好用"。性能兼容性测试至少覆盖：大列表滚动是否掉帧、图片懒加载是否生效、内存占用是否异常。Edge高内存占用的问题，很多场景也属于这一类——不是崩溃，但体验很差。

第四坑：不记录复现环境。测试发现Bug只写"页面打不开"或"样式不对"，开发拿到手一脸懵。规范的Bug描述一定要包含：浏览器名称加版本、操作系统、复现步骤、期望结果、实际结果、截图或录屏、控制台报错信息。有了这七项，开发排查时间能缩短一半。

5.3 适合不同团队规模的落地路径

小团队（1到3人开发、无专职测试）：不要一上来就搞自动化框架。先把手动矩阵跑通，把用例库搭好，用Chrome DevTools和Edge IE模式应对常规问题，移动端用自己的手机做真机测试。等发版频率高起来，再考虑引入Playwright做核心流程回归。

中型团队（3到10人开发、有1到2名测试）：可以引入自动化回归，用Playwright跑P0场景，手工测试专注P1、P2和视觉细节。有条件的话，准备2到3台实体真机（Windows笔记本、MacBook、Android手机）作为兼容性测试固定资产。云真机平台按需购买，不用长期订阅。

大型团队或ToB项目（有企业客户、有复杂浏览器环境）：必须建立分级兼容矩阵，把客户环境单独列为核心环境优先保证。自动化测试覆盖核心回归，视觉回归工具纳入流水线。同时建立问题流转机制，客户报的兼容性问题快速回到测试团队，补充进用例库。

我个人的经验是，兼容性测试方案不是越复杂越好，而是要跟项目的用户环境、团队资源、发布节奏匹配。很多时候，一套踏实的矩阵加手工流程加问题记录习惯，远比一个华丽的自动化框架有用。先跑通、再优化、再自动化，这个顺序不要反过来。另外，不管方案多完整，最终还是要靠人一遍遍去点、去看、去对比，浏览器兼容性这件事，真没有一劳永逸的银弹。