在 2019 年的最后一个季度，Chrome 开发者工具团队开始改善开发者在开发者工具中围绕 Cookie 的体验。这一点尤为重要，因为 Google Chrome 和其他浏览器已经开始更改其默认 Cookie 行为。
在研究开发者工具已经提供的工具时，我们经常会发现自己遇到以下情况：
😰? 控制台中充斥着警告和错误消息，其中包含技术性说明，有时还会链接到 chromestatus.com。所有消息看上去大致相当重要，因此很难确定应该首先处理哪一条。更重要的是，这些文本没有链接到开发者工具内的其他信息，导致难以理解发生的情况。最后，这些消息往往完全留给 Web 开发者自己去解决如何解决问题，甚至是了解技术背景。
如果您还使用控制台处理来自自己应用的消息，则有时很难在浏览器的所有消息之间找到这些消息。
与人类一样，自动化流程也很难与控制台消息交互。例如，在持续集成/持续部署场景中，开发者可能会使用 Chrome Headless 和 Puppeteer。由于控制台消息只是字符串，因此开发者需要编写正则表达式或其他一些解析器来提取可操作的信息。
解决方案：结构化且可操作的问题报告
为了针对所发现的问题寻找更好的解决方案，我们首先开始思考相关要求，并将其收集到设计文档中。
我们的目标是在展示问题时要能够清晰地说明问题以及解决方法。 通过设计流程，我们发现每个问题都应包含以下四个部分：
- 标题
- 说明
- 指向开发者工具中受影响资源的链接
- 以及指向进一步指导的链接
对于游戏，我们希望它简明扼要，以便开发者了解核心问题，并且通常已经给出了有关修复的提示。例如，Cookie 问题现在只会如下所示：
将跨网站 Cookie 标记为“安全”，以允许在跨网站环境中设置这些 Cookie
每个问题的说明中都会包含更多详细信息，说明所发生的情况，提供关于如何解决问题的切实可行的建议，并提供指向开发者工具内其他面板的链接，以便用户在相关背景下了解问题。此外，我们还提供 web.dev 上深入文章的链接，让 Web 开发者能够更详细地了解该主题。
每个问题的重要组成部分都是受影响的资源部分，该部分会链接到开发者工具的其他部分，方便您进一步调查。对于 Cookie 问题示例，应该会列出触发该问题的网络请求，点击请求即可直接转到“Network”面板。我们希望这不仅方便，还能让开发者工具中的哪些面板和工具可用于调试某种问题。
从开发者与“问题”标签页的长期互动方面，我们设想开发者互动的以下演变：
- Web 开发者在首次遇到特定问题时，可以阅读这篇文章来深入了解该问题。
- 第二次遇到问题时，我们希望问题说明足以提醒开发者问题所在，以便他们立即调查并采取行动来解决问题。
- 在多次遇到问题后，我们希望问题标题足以让开发者了解问题类型。
我们希望改进的另一个重要方面是汇总。例如，如果同一个 Cookie 多次导致同一问题，我们只想报告该 Cookie 一次。除了大幅减少邮件数量之外，这通常还有助于更快地确定问题的根本原因。
实现
考虑到这些要求，团队开始研究如何实现新功能。Chrome 开发者工具的项目通常跨越三个不同方面：
- Chromium，这是支持 Google Chrome 的开源项目，使用 C++ 编写
- DevTools 前端，Chrome DevTools 的 JavaScript 实现
- Chrome 开发者工具协议 (CDP)，将两者连接起来的层
实施工作包括三个任务：
- 在 Chromium 中，我们必须找出包含我们想要显示的信息的组件，并在不影响速度或安全性的情况下，通过开发者工具协议访问这些信息。
- 然后，我们需要设计 Chrome DevTools 协议 (CDP)，以定义用于向客户端公开信息的 API，例如开发者工具前端。
- 最后，我们需要在 DevTools 前端实现一个组件，该组件通过 CDP 从浏览器请求信息，并在适当的界面中显示这些信息，以便开发者能够轻松解读这些信息并与之互动。
在浏览器方面，我们首先关注的是控制台消息的处理方式，因为控制台消息的行为与我们对问题的看法非常相似。进行这类探索时，CodeSearch 通常是很好的起点。它可让您在线搜索和浏览 Chromium 项目的整个源代码。通过这种方式，我们了解了控制台消息的实现，并可以根据我们收集的相关问题要求构建一种并行但更有条理的方式。
由于我们始终需要时刻关注所有安全隐患，因此这里的工作尤为具有挑战性。Chromium 项目在将事物分为不同的进程并使它们仅通过受控的通信渠道进行通信，以防止信息泄露，取得了长足的进展。问题可能包含敏感信息，因此请务必注意，不要将这些信息发送到浏览器不应该知道的部分。
在开发者工具前端中
DevTools 本身就是一个使用 JavaScript 和 CSS 编写的 Web 应用。它与许多其他 Web 应用十分相似，只不过它已经问世了 10 多年了。当然，其后端基本上是与浏览器的直接通信渠道：Chrome DevTools 协议。
对于“问题”标签页，我们首先想到的是用户案例，以及开发者需要采取哪些措施来解决问题。我们的想法主要是将“问题”标签页作为调查的起点，将用户链接到显示更多详细信息的面板。我们决定将“问题”标签与其他标签放在开发者工具的底部，这样在开发者与另一个开发者工具组件（例如“网络”或“应用”面板）交互时，该标签可以保持打开状态。
有鉴于此，我们的用户体验设计师了解了我们的目标，并设计了以下初始方案的原型：
在围绕最佳解决方案进行大量讨论后，我们开始实施设计并重申决策，从而逐步找到“问题”标签页现在的外观。
另一个非常重要的因素是“问题”标签页的可检测性。过去，许多出色的 Devtools 功能在开发者不知道具体需要什么的情况下是无法发现的。对于“问题”标签页，我们决定在多个不同方面突出显示问题，以确保开发者不会错过重要问题。
我们决定在控制台面板中添加一条通知，因为部分控制台消息现已移除，取而代之的是问题。我们还在开发者工具窗口右上角的警告和错误计数器中添加了一个图标。
最后，“问题”标签页不仅会链接到其他开发者工具面板，还会链接到“问题”标签页。
在协议中
前端和后端之间的通信通过一种名为 Chromium 开发者工具协议 (CDP) 的协议进行工作。CDP 可以看作是 Web 应用的后端，即 Chrome 开发者工具。CDP 可细分为多个网域，每个网域都包含许多命令和事件。
对于“问题”标签页，我们决定向 Audits 网域添加一个在遇到新问题时触发的新事件。为了确保我们也能报告在开发者工具尚未打开时出现的问题，审核日志领域会存储最新问题，并在开发者工具连接时立即发送它们。然后，开发者工具会收集所有这些问题并对其进行汇总。
通过 CDP，其他协议客户端（例如 Puppeteer）还可以接收和处理问题。我们希望通过 CDP 发送的结构化问题信息有助于简化集成到现有持续集成基础架构中。这样一来，即使在部署网页之前，也能检测到并修正问题！
未来
首先，需要将更多消息从控制台移至“问题”标签页。这需要一些时间，特别是因为我们希望针对添加的每个新问题提供清晰明确、可作为行动依据的文档。我们希望开发者将来可以在“问题”标签页（而不是控制台）中查找问题！
此外，我们正在考虑如何将除 Chromium 后端以外的其他来源的问题集成到“问题”标签页中。
我们正在想办法让“问题”标签页整洁有序并提高易用性。今年的搜索、过滤和更好的汇总功能将纳入考虑范围。为确保所报告的问题越来越多，我们正在引入各种问题类别，例如，可以仅显示与即将弃用的问题有关的问题。我们还在考虑添加延后功能，开发者可以使用该功能暂时隐藏问题。
为确保问题的可操作性，我们希望能够更轻松地找出网页的哪个部分触发了问题。特别值得一提的是，我们正在想办法区分和过滤那些确实出自您的网页（即第一方）的问题，并滤除那些由您嵌入的资源触发，但并非由您直接控制（如广告网络）的问题。首先，您可以在 Chrome 86 中隐藏第三方 Cookie 问题。
如果您对改进“问题”标签页有任何建议，请提交 bug 告诉我们！
下载预览渠道
您可以考虑将 Chrome Canary 版、Dev 版或 Beta 版用作默认开发浏览器。通过这些预览渠道，您可以使用最新的开发者工具功能，测试先进的网络平台 API，并在用户采取行动之前发现网站上的问题！
与 Chrome 开发者工具团队联系
使用以下选项讨论博文中的新功能和变化，或讨论与开发者工具有关的任何其他内容。
- 通过 crbug.com 提交建议或反馈。
- 使用开发者工具中的更多选项
> Help > Report a DevTools issues来报告开发者工具问题。 - 发推文：@ChromeDevTools。
- 请在 YouTube 视频或“开发者工具提示”YouTube 视频中留言说明“开发者工具的新变化”。