[!info] related notes

• 所属 MOC: 浏览器开发者工具 MOC
• 执行路径: Sources 面板
• DOM: Elements 面板
• 网络: Network 面板

DevTools Console 面板

一句话定义

Console 同时是运行时日志查看器与 JavaScript REPL。

它适合快速回答两类问题：

• 运行时发生了什么；
• 这个表达式在当前环境里是什么结果。

Console 中的信息来源

常见来源：

• 页面代码主动输出的 log / warn / error；
• uncaught exception；
• unhandled Promise rejection；
• 浏览器生成的 warning / error；
• DevTools 中手工执行表达式的结果。

所以一条 Console error 可能是：

• 真正根因；
• 上游错误的级联结果；
• 第三方脚本噪声。

要结合 source、时间和调用链判断。

REPL 的执行上下文

Console 表达式会在当前选中的 JavaScript context 中执行。

多 iframe、extension、worker、isolated world 场景下，要先确认当前 context，否则“变量不存在”可能只是执行到了错误环境。

与 Elements 联动

在 Elements 选中节点后，Console 可以通过 $0 快速引用当前节点。

适合验证：

• DOM 属性；
• event target；
• 临时调用浏览器 API；
• 当前节点相关表达式。

这只是现场实验，不等于正式源码修改。

Preserve log

页面 reload / navigation 时普通日志可能被清空。

Preserve log 适合追：

• redirect；
• 登录跳转；
• reload loop；
• 跨页面错误。

但保留太久会把多次运行混在一起，所以仍要按时间和 navigation 边界区分。

Console 与断点

Console 更适合：

• 快速验证假设；
• 临时查看对象；
• 观察错误。

断点更适合：

• 捕获某一时刻的真实输入；
• 沿 Call Stack 找来源；
• 单步定位值在哪一步变错。

如果开始大量 console.log 猜执行顺序，通常应该切到 Sources。

常用技巧

console.table

适合快速看数组或对象集合结构，不改变数据本身。

日志级别与过滤

用于减少第三方和高频日志噪声，但不要因为过滤掉 warning 就认为问题不存在。

临时修改对象

可以验证 UI 或逻辑假设，但刷新后通常消失，也可能改变问题现场。

常见误区

• Console 没报错 = 页面正确；
• 看到最后一条 error 就认定它是根因；
• 在错误 frame/context 里执行表达式；
• 用大量日志代替稳定 trace 或断点；
• 展开对象后忘记它显示的可能是后来变化后的当前值。

学习检查

1. Console 的两种核心角色是什么？
2. 为什么 Console error 不一定就是第一根因？
3. 多 iframe 页面中执行表达式前为什么要确认 JavaScript context？
4. Preserve log 最适合哪类跨导航问题？
5. 什么时候应该从 Console 切换到 Sources？
6. $0 与 Elements 面板怎样形成联动？
7. 给一个“点击无反应但没有 error”的问题，说明 Console 能做什么、接下来为什么还需要 Network/Sources。