作为一名合格的前端，我们不可避免的需要接触到浏览器的开发者工具，也必须掌握这个工具。介于我自身的掌握水平，我将在本文对chrome devtool的选项卡进行讲解，同时也对比不同浏览器之间的devtool的功能差异。

如果你对于Performance标签并不太熟悉又想优化一些网站的性能，那么我非常建议你使用Lighthouse。运行Lighthouse你可以获得页面的一些审核指标（自由选择）、得到页面加载时各个时刻的截图，同时Lighthouse还会提供如何提高特定页面加载性能的提示。

下图是Lighthouse的启动界面，目前在启动Lighthouse时，需要选择四个选项。分别是模式、网站会在哪个设备运行、需要测试的类别、是否包含广告插件。

Lighthouse的不同模式略有差异。我们需要了解一下一些使用场景、使用方式的差异。

• Navigation 导航模式

导航模式作为默认模式，其使用场景是首次进入页面的分析，即其指标与评分是在测试首屏渲染，无法分析页面加载后需要手动触发使用的内容。同时根据官方文档，其对于表单提交或者SPA页面转换也没有分析的能力。受益于Navigation，我们可以得到页面加载各个时刻的页面加载截图。

注意，仅该模式可以分析所有的类别和插件。点击“分析网页加载情况”，此时页面会重载，无需手动操作，等待片刻Lighthouse即会输出一份报告。

• Timespan 时间跨度模式

时间跨度模式是我最喜欢的模式，其可以测量布局变化和交互，它允许我们在一个时间范围内自由操作页面，Lighthouse会在我们结束后分析整个过程的各个指标。对于网页性能优化来讲，Timespan绝对是最佳选择（实际上，Timespan目前也确实只支持性能分析）。

使用时间跨度模式，需要在Lighthouse准备就绪后操作页面，在所有操作完毕后，点击结束时间跨度模式Lighthouse将开始审查整个操作过程，输出一份性能报告。

• Snapshot 快照

快照模式，顾名思义，快照模式下Lighthouse不会重新加载页面，它会直接分析当前页面当前状态得出各项指标。注意，快照模式下，不能分析广告和PWA。

使用快照模式的方式和导航模式类似，点击后Lighthouse会自动审查分析，不需要额外操作。

一个有趣的事情是，lighthouse可以通过nodejs的方式启动。此时虽然仍有Navigation等模式的区分，但是我们可以在启动后做一些点击、表单一系列操作。

我们将以Navigation模式中生成的指标作为基础讲解各个指标，其他两个模式的指标与Navigation模式中生成的指标并无太大区别，其基本逻辑都是：lighthouse提供诊断分数——提供优化建议——提供诊断结果。

在Performance报告中，其由性能分数、性能指标、优化建议、诊断结果组成。

关于性能分数的计算，也就是下图这一部分，Lighthouse官方给了一份完整的计算方式讲解，同时包含了一个在线计算器。

根据这份计算方式讲解，我们可以了解到，Lighthouse 10对下边的五个指标进行加权计算得到性能分数。这五个指标，即目前主流性能检测中常见的First Contentful Paint、Speed Index、Largest Contentful Paint、Total Blocking Time、Cumulative Layout Shift。

我想大部分前端同学或多或少都听过这些指标的大名，但是或许大部分人并不了解其中的含义，所以我们有必要进行更详细的讲解。报告中的指标部分就是具体展示了这些指标，并同时提供了原始追踪记录和资源加载树状图。其中的原始追踪记录，会导向Performance标签，我们暂不做演示。我们首先讲解五个指标的意义，再看一下树状图。

• First Contentful Paint

  FCP测量的是，用户进入到页面后浏览器呈现第一段DOM内容所需的时间，这个时间一般是秒。页面上的图像、非白色  元素和SVG都被认为是DOM内容，而iframe里面的任何东西都不包括在内。

  在上边的图中，我们会发现对我这份报告来说，FCP为1s，颜色显示为黄色，这是因为Lighthouse的评分标准中，对于0-49呈现红色，50-89呈现黄色，90-100呈现绿色。而对于FCP来说，根据官方文档（2021-06-04更新），这一块的分数以1.8和3分为界限。1.8s以下为绿色，3s以上为红色。但是实测下来，1s的表现仍是黄色，对于这里存在的差异，官方文档中有提到FCP的得分计算方式是与真实网站做比较，基于HTTP Archive的数据。例如，99%中执行的站点在大约0.5秒内呈现FCP。如果我们的网站的FCP是0.5秒，则FCP得分99。

  那么我们可以根据截至2023年6月1日的数据，计算得出目前的评分表（对于PC网页）：

  FCP time(in seconds)Color-coding0–1.1Green (fast)1.1–2.1Orange (moderate)Over 2.1Red (slow)

• Largest Contentful Paint

  LCP测量视口中最大的内容元素何时呈现到屏幕上。这个指标的意义是，最大内容元素的呈现近似于用户看到页面主要内容的时间。LCP的测量方式相比FCP更复杂，根据W3C对于LCP的测量范围定义，最大内容绘制考量的元素类型为：

  • img元素。
  • image内的元素svg。
  • 元素的海报图像video。
  • 具有背景图像的元素。
  • 文本节点组，按照§ 3.2 CSS 规范的修改中的描述进行聚合。

  W3C还提供了具体的API使用案例，Devtool中对于LCP的测量即依赖于。

• Total Blocking Time

  TBT代表当任务用时超过 50 毫秒时计算首次内容绘制 (FCP) 和可交互时间之间的所有时间段的总和，以毫秒表示。通过将第一次内容绘制和交互时间之间的所有长任务的阻塞部分相加来计算总和。任何执行时间超过50毫秒的任务都是长任务。50ms之后的时间量是阻塞部分。例如，如果Lighthouse检测到70ms长的任务，则阻塞部分将是20ms。

• Cumulative Layout Shift

  CLS对布局进行审查，是测量视觉稳定性的一个以用户为中心重要指标，因为该项指标有助于量化用户经历意外布局偏移的频率。所谓布局偏移，就是在交互时，页面布局的跳动。导致页面布局跳动的因素一般是图像加载未定义宽高、滚动条显隐挤压内容变化，更多可能导致布局跳动的因素，可以参考下边这份文档layout-instability。

• Speed Index

  Speed Index 表明了网页内容的可见填充速度。该速度指数的分数计算方式和FCP类似，参考了HTTP Archive。其测量方式是在页面加载过程中内容以视觉方式显示的速度。Lighthouse首先捕获浏览器中页面加载的视频，并计算帧之间的视觉进展。然后Lighthouse使用Speedline Node.js模块生成速度指数得分。

简述了这些指标，我们说说资源加载树状图。该树状图根据单个文件的大小排列与展示，方便看到是哪些资源拖累了页面加载。同时，其计算了哪些文件中的哪些部分是未使用的，帮助开发者寻找到需要精简的文件。

要注意的是，浏览器插件的代码也会影响评分。

剩下的部分中，lighthouse给出了优化建议和诊断结果，这一部分内容通过红橙绿三色表示严重程度，每一项都可以展开查看详细结果。这些优化建议根据上方的指标可以进行筛选，相当于手把手教导我们如何优化工程优化网页来提高相关指标的得分。

对于中小型网站，可能对于无障碍功能考虑得会比较少。但是，随着互联网的发展，人们愈发考虑无障碍人群的体验了。浏览器作为一个非常核心的互联网窗口，自然不能停下脚步，lighthouse提供的无障碍功能检测一方面可以让我们具体感知到自己网页的无障碍程度，一方面也通过它提供的多条指标与指引了解浏览器的无障碍标准。

Devtool工具会检查网页的ARIA、对比度、名称和标签，帮助改善辅助技术用户的体验。从测试结果来看，lighthouse提供的检测报告总共包含44项自动检测，10项手动检查，所以我说lighthouse提供了一个很好的学习途径，54项检查我整理在下边的表格中，需要自取。

lighthouse中有比较简单的网页最佳做法诊断功能，包含了16项诊断内容。这一块比较好理解，

我们知道，搜索引擎能过通过爬虫爬取网页信息形成，而不同网页爬取到的信息可能是不同的，这就是SEO存在的来源。lighthouse提供了15项SEO优化建议。

渐进式Web应用是Chrome推进的离线网页应用，lighthouse会检测网页是否可以安装为PWA应用以及提供安装为PWA应用后的优化项。

我们将优化项整理出来一个表格，但是其他的部分我是建议直接看官网内容：了解如何构建优秀的渐进式 Web 应用。

lighthouse提供了多报告、清除报告、导出打印报告等能力，方便开发者使用。

同时你会发现，我们忽略了移动设备的选择，这是因为经过测试，移动设备的选型不影响我们了解lighthouse的使用。值得关注的是，选择移动设备会有额外的优化项，请开发者们自行探索。

来到激动人心的Souces调试工具，作为一名前端开发，一定且必须对前端代码调试工具中的王者有一个深刻的了解。

看到左侧选项卡，目前Devtools提供了五个选项卡。

其中的网页选项卡提供了对当前网页已加载的所有资源进行索引的功能，可以比较方便地浏览页面资源。内容脚本选项卡也提供了类似的功能，区别在于Content Script是网页的上下文运行的JS文件，可以通过该JS文件获取DOM和捕获DOM事件。如果你了解过浏览器插件的开发，会更明白两者的区别。

网页选项卡

内容脚本选项卡

文件系统选项卡类似vscode，我们可以拖拽本地的文件夹到其中，就会形成工作区。这一点和后边的替换选项卡是非常相似的，它提供一种在Devtool上修改代码同步到本地文件的能力。官方给出的场景是这样的：

• 你的桌面上有你网站的源代码。
• 你正在从源代码目录运行本地Web服务器，因此可以在访问站点  。
•  已经在Google Chrome中打开了，你正在使用DevTools来更改网站的CSS。

在这种情况下，可以方便地同步代码。

Overrides替换面板可以用本地的文件覆盖到网页上的文件。具体的操作流程是 ：

1. 在Overrides面板中选择保存到本地哪个文件夹中。此时弹出权限申请，点击允许即可。
2. 在网页或内容脚本亦或者从Elements选项卡选中需要覆盖的文件，右键保存到上一步选择的文件夹中。这一步也可以通过在文件编辑区右键—保存并覆盖。
3. 等待片刻，此时已经可以看到Overrides中出现被替换的文件，并且其右下角存在一个小点点代表链接成功。此时修改文件即便刷新页面也不会丢失。

最后还有一个小功能是Code Snippets，代码片段功能可以让我们更方便地编写一些小demo在浏览器上运行。再也不用在console艰难地编写代码了。

页面中间的编辑区域的使用需要结合右方选项卡使用。主要核心区域是最左侧的行数与断点调整区，在这里单击某行可以添加一个普通断点，左侧的卡标变成蓝色证明断点打成功了。

而这只是最基本的使用，Devtool中的打断点方式并不只是以行为断点去打，而是可以细分到某行某列。我们知道，现在大部分网页会把源代码压缩成一行，如果不能如此细分，那对于线上调试非常不友好。

除此之外，通过右键的方式还可以选择添加”条件断点“，”日志点“，”不暂停点“。图中的粉色为日志点，其余两个橙色的剩下两个点。

除却最重要的左侧断点区域之外，最上方的选项卡右键后可以看到菜单，提供了一些便捷的导航、复制、标签管理等功能。

同理，在文件编辑区域右键同样可以打开菜单。值得注意的是，如果右键的文件是JS或CSS文件，可以看到来源映射选项，该选项支持我们为文件添加sourcemap文件还原源代码。

右侧的面版是Souces面板的核心部分，所以一一讲解。

监视功能是我认为最好用的功能之一。我们可以在监视中输入变量名或者进行函数调用。通过”+“添加新的监视，通过刷新按钮可以重新获取当前值。通过右键则可以删除单条或所有监视。注意，像我图中正在debug一个TSX文件，显然这是经过sourcemap映射出来的源文件，但是监视时，变量名是取编译后文件中的，所以如果存在变量名重复不同域，很可能监视中并不能成功监视，这种情况建议通过代码规范规避。

断点选项卡提供了本网页内所有断点的浏览与管理功能，并且额外提供了两个选项：遇到未捕获的异常时暂停以及遇到异常时暂停，这两个选项非常适合在bugfix时使用（心酸）。

再就是作用域选项卡，作用域的概念我就不过多阐述了，属于JavaScript基础知识。作用域中一般包含当前断点所在的作用域、模块作用域、脚本作用域、全局作用域这些作用域中存在的变量。

在这里可以比较方便看到当前作用域内各个变量及其值，甚至还可以通过双击修改。右键其中的变量还可以实现将其取出放置入console控制台等操作。

调用堆栈选项卡显示了当前断点在堆栈中的位置，一般来讲我们的日常开发中不用接触到这一层，但是如果是在进行bug问题定位以及源码阅读时，堆栈中显示的每一帧就可以成为极大的助力，帮助我们更好地看懂代码的运行流。

通过右键堆栈，我们还可以复制具体的堆栈轨迹和重启堆栈帧。所谓堆栈轨迹好理解，但是重启堆栈帧并不好理解，根据谷歌出来的答案，"重启堆栈帧"（Restart Frame）是一个用于调试 JavaScript 代码的功能。当你在调试过程中遇到一个错误或者想要重新执行某个函数时，"重启堆栈帧"功能可以帮助你回溯到指定的函数调用，并重新执行该函数，以便重新跟踪代码执行流程。

具体来说，"重启堆栈帧"功能会将调试器回溯到指定函数的调用点，并重新执行该函数及其之后的代码。它的作用和使用场景如下：

1. 调试错误代码：当你在调试过程中遇到一个错误，并且想要重新执行引发错误的函数，你可以使用"重启堆栈帧"来回溯到该函数的调用点，并重新执行该函数，以便重新跟踪错误产生的原因。
2. 验证代码更改：当你对代码进行修改后，想要验证修改是否有效或者希望重新执行某个函数以检查修复后的行为时，"重启堆栈帧"功能可以帮助你快速回溯到修改点，并重新执行相关代码。
3. 测试函数调用：在某些情况下，你可能需要多次执行某个函数以验证其行为或观察其输出。通过使用"重启堆栈帧"，你可以在不重启整个调试会话的情况下多次执行特定函数，提高调试效率。

注意，"重启堆栈帧"功能仅影响当前调试会话的执行流程，并不会修改实际代码或影响应用程序的运行。它是一个有用的工具，用于在调试过程中探索和调整代码执行流程。

XHR断点，顾名思义可以在发送AJAX请求时暂停代码执行。通过加号按钮可以添加网址，在发送AJAX请求时，如果网址包含指定内容则触发断点暂停。

DOM断点的使用需要搭配Elements选项卡。这里演示一下如何使用：

1. 在Elements找到需要监控的元素，右键——发生中断的条件，选择自己需要的监控条件

2. 观察到DOM断点中出现该断点。

3. 尝试触发条件，会发现断点停在了我们修改DOM的代码处。

全局监听器指的是globalThis，即window上的监听器（不包含document哦）。提供了监听器移除，添加的监听器代码溯源这些功能。

同时，右键监听器，还可以将其设置为”被动式“，在全局监听器中，"被动式"（Passive）是一个指示选项，用于控制事件监听器的行为。当将事件监听器设置为被动式时，它表明监听器不会调用 来阻止事件的默认行为。这意味着即使监听器被触发，事件的默认行为仍会继续执行。

被动式监听器的主要目的是提高滚动性能。在过去，浏览器的滚动事件监听器通常会调用 来阻止滚动事件的默认行为，以实现自定义滚动行为。然而，这样做会导致浏览器在滚动期间被阻塞，从而导致滚动性能下降。

通过将滚动事件监听器设置为被动式，浏览器可以更好地优化滚动性能。当事件被触发时，浏览器可以在不受阻塞的情况下执行滚动操作，并且不会等待监听器完成。这可以显著提高滚动的平滑度和响应性。要将事件监听器设置为被动式，需要使用 方法，并在 参数中将 属性设置为 ，如下所示：

并非所有的事件都支持被动式监听器。只有那些不会改变元素布局或引起页面重绘的事件（如滚动、触摸滑动等）才能使用被动式监听器。对于那些需要 来阻止默认行为的事件（如点击链接、提交表单等），不应将其设置为被动式。

事件监听器断点提供了对某类事件的断点监控功能，可以细致到某类事件的具体事件。

最后一项是CSP违规断点。这应该是大部分初级开发不会接触到的选项。CSP（Content Security Policy）违规断点是 Chrome DevTools 中的一种调试工具，用于在网页中检测和调试 CSP 违规情况。CSP 是一种安全策略，用于限制网页中允许加载和执行的资源，以减少恶意代码的风险。

使用 CSP 违规断点，可以暂停网页的执行，并检查哪些资源加载违反了 CSP 策略。设置 CSP 违规断点后，当网页中发生 CSP 违规时，DevTools 会在断点位置暂停，此时可以查看违规的详细信息。

CSP 违规断点的主要作用如下：

1. 检测 CSP 违规：CSP 违规断点可以帮助捕获网页中的 CSP 违规情况。当网页中的资源加载违反了 CSP 策略时，DevTools 会在断点位置暂停代码执行，能够检查违规的资源和相应的策略。
2. 调试 CSP 策略：通过设置 CSP 违规断点，可以分析和调试网页中的 CSP 策略。当某个资源被阻止加载或执行时，我们可以使用断点来查看导致 CSP 违规的具体策略和原因。

如要使用CSP断点，需要选择 "CSP Violations" 选项，使 DevTools 可以在网页中的 CSP 违规发生时暂停代码执行并显示相关信息。

顶部选项卡用于操控代码的运行，从左到右的各个选项其功能和快捷键分别是：暂停/继续（F8）、不深入函数内部并跳过下一个函数的继续下一步运行（F10），进入函数内部的继续下一步运行（F11），立即从当前函数快速跳出并运行到调用该函数位置的下一步运行（Shift+F11）以及单步调试（F9），以及最后一个选项用于暂时关闭所有断点。

我本来不想写Elements选项卡了的，毕竟元素选项卡作为最经典的选项卡，其功能必定应该被每一位前端熟知并使用。

但是我想并不是的，知识的诅咒决定了当我们一旦知道某种知识，就无法想象不知道这种知识时会发生什么，所以现在我只能假设在座的各位都是猴子。

那么可以从图中看到，元素标签页可以分成左右两栏，其中左侧展示了整个页面的所有DOM节点，而右侧则提供了对左侧选中DOM节点的属性查看、编辑等能力。

通过右键左侧面板中的DOM节点可以唤醒Element面板的高级功能。

自上而下，前五项都是对于当前网页内容的直接修改，并不值得一提。而中间的复制功能比较有意思。开发者工具除却提供复制DOM节点的完整代码外，还提供了复制outerHTML、复制selector、复制JS路径、复制样式、复制XPath、复制完整XPath等多个选项。

为方便诸位读者观看，我整理了一份表格，陈述这些复制的作用。下边以图中的DOM元素举例：

继续往下的几个选项中，强制修改DOM的执行状态是常用且特别好用的功能，可以让选中的DOM元素直接进入特定状态。

剩下的值得关注的选项就是最下边的“存储为全局变量”，选择该选项控制台中会自动生成一个临时变量选中该元素，方便测试。

Chrome的右侧面板包含了样式、计算样式、布局、事件监听器、DOM断点、DOM属性、无障碍功能这几个选项卡。

样式选项卡一方面是提供了查看作用在DOM节点的各个样式，一方面提供了对样式修改的能力。在这些能力之余，过滤功能可以过滤需要的文件，“:hov”选项则提供了和上边强制执行状态相同的功能，“.cls”选项可以让我们方便地增删当前DOM节点的class，加号按钮则提供了直接新建一个样式类的能力。

至于小刷子……我不清楚为什么放这里，因为它可以调整是否开启夜间模式，但是却是一个全局的开关。

计算样式相比样式选项卡，更多的是作为查看DOM具体样式的工具，计算样式选项卡下的样式可以分组显示，根据样式的类型（比如Layout—position）进行分类，同时，还通过图像表现了DOM元素的盒模型。

如果你在研究样式BUG，非常建议在计算样式寻找问题而不是在样式中查找。

devtool中的布局选项，可以在不同的DOM上显示其线框表达其布局信息，可以帮助排插一些样式问题。

至于剩下几个点就不讲了，DOM断点和事件监听器和Souces源代码是有些重复的。

Edge排除，原因是其内核就是Chromium，Devtool也和Chrome一样。

​ 世间的浏览器并不止Chrome一种，这里列举了目前的浏览器三巨头以及国内较流行的微信小程序开发者工具，我们将对比它们的Devtool之间的差异。

​ Chrome Devtool作为目前最全面和强大的开发者工具，其基本上被各个前端开发视为标准开发者工具。其相比另外两者，提供了更多关于DOM属性结合JS的内容，包括事件监听器、DOM断点、属性，通过Chrome Devtool可以更方便地了解到DOM节点的状态。由于这部分内容类似于源代码中的页面，不做讲解。

​ Firefox的元素页面被称作”Inspector“，其提供了”Changes“，”Fonts“，”Animations“的定制化功能。

​ Changes选项旨在标记出开发者对页面样式等改动，会以高亮的形式显示修改的内容。

​ Fonts选项提供给开发者查看网页使用了哪些字体、当前选中元素字体相关属性的快捷调节与展示。

​ Animations选项则提供了对于当前元素及其子元素存在的CSS Animation进行追踪的功能，借助该功能，可以控制时间轴控制元素动画所处位置，观察动画状态。

​ 除此之外，Firxfox还额外提供了界面颜色选取的取色器。

​ 相比之下，Safari浏览器的开发者工具和前两者的差异更大，相比之下，Safari的Elements界面更具有个性，比如底部常驻console控制台，比如下图中的标尺、元素打印、将元素使用默认外观、显示页面元素合成的边框、启用绘图闪烁这些功能。

​ 除此之外，Safari浏览器在右侧也提供了字体选项卡，但是相比Firefox略单调，只有比较基础的展示功能。另外一个定制的则是”层“选项卡，层是Safari浏览的网页渲染组合机制，定位fixed、与其他符合元素重叠都会导致元素成为层。

​ 微信小程序开发者工具的开发者工具是由chrome devtool改造而来的，Elements选项卡在这里化作”WXML“选项卡。微信团队为其添加了Dataset、Component Data和Scope Data三个选项，并删除了其他选项卡，这几个选项卡和小程序的组件机制有关，会显示一些组件的属性。

​ 实际测试可知，这四个开发者工具的Console控制台功能基本一致。其中Chrome浏览器看起来更专业，配置项更多：

​ 而Firefox在保证基本功能的同时，新增了代码片段，类似于一个小型IDE，和Chrome中Souces选项卡中的代码片段类似。Firefox对人性化做得甚至比Safari更好，在Firefox的控制台中甚至可以查看完整的网络请求。

​ Safari的控制台功能略单薄，比如相比前两者就缺失了在控制台打印网络请求的能力。而微信小程序就不用说了，是从Chrome Devtool中照搬过来的。

​ 我们上边有详细讲过Chrome的Souces面板，所以Chrome的部分可以参考上边的段落。而Firefox浏览器的Souces面板实际称呼为”Debugger“，其功能基本和Chrome一致，只是相对来讲功能没有Chrome那么全面，除却额外提供了Outline选项卡用于得到当前文件中的函数之外，其他部分都与Chrome一致或缺失。

​ Safari的调试面板则更个性化，它提供的断点类型甚至比Chrome还要多，提供了微任务、requestAnimationFrame、setTimeout、setInterval等断点。至于其他功能，虽然UI相似度非常低，但是大多数功能并无差别。

微信开发者工具的表现与Chrome完全一致。

我们说过，Chrome是最全面最专业的浏览器。截至2023/7/6，只有Chrome提供了命令菜单的功能。在Chrome Devtool中，可以通过Ctrl+Shift+P唤起命令行工具，在其中有非常多更专业的功能。 比如，输入FPS可以找到帧数计量器，唤起后可以看到页面渲染帧率和GPU占用。

这之中还有更多宝藏功能，请诸位开发者自行探索。

Chrome具有最详细的功能，就选项卡而言，Chrome的选项卡最起码有二十个，而我们常用的不过手指之数。如果我们真要讲，本文怕不是不够。

Firefox具备常用开发需要的所有功能，对样式开发有更好的支持。

相比其他的主流浏览器，Safari一直是比较特立独行的，其开发者工具中提供的时间线、图形、层、审核一系列选项卡，这些功能即便是Chrome中都没有。但是由于苹果喜欢闭源的特性，Safari并没有插件能力，所以并不建议作为主力开发浏览器。

小程序是类似浏览器的存在，所以我也将其提了出来。相比前三位，微信开发者工具具备比较多的定制能力，比如AppData选项卡用于获取页面中的状态、Vulnerability用于接口安全扫描、Mock选项卡提供了Mock的能力、Storage选项卡是小程序版本缓存的操作菜单

综上所述，我认为Chrome Devtools不愧为一流的开发者工具，不管你是前端小白还是资深前端开发，选择它没有错。而Firefox devtools同为老牌的开发者工具，其专业性虽然对比Chrome devtools略有不足，但是用户体验是极好的，适合前端小白使用，且Firefox提供的Fonts、Animations以及Style Editor让它在前端样式与用户体验优化上更有优势。至于Safari，Safari的闭源机制并不支持插件，像React开发时常用的插件就无法安装，所以不建议使用Safart进行开发。