你是否真的了解console

微信公众号：  [大前端驿站]
关注大前端驿站。问题或建议，欢迎公众号留言。 这是我参与8月更文挑战的第22天，活动详情查看：8月更文挑战

我们在开发中经常会用到console.log来打印一些信息帮助到我们调试程序或者定位bug。但是有时候我们在打印一些信息的时候也出现过一些奇怪的现象让我们琢磨不透，结果与我们预期不符的情况，这时候我们该如何定位问题呢？

并没有什么规范或一组需求指定 console.* 方法族如何工作——它们并不是 JavaScript 正式的一部分，而是由宿主环境添加到 JavaScript 中的。因此，不同的浏览器和 JavaScript 环境可以按照自己的意愿来实现，有时候这会引起混淆。

尤其要提出的是，在某些条件下，某些浏览器的 console.log(..) 并不会把传入的内容立即输出。出现这种情况的主要原因是，在许多程序（不只是 JavaScript）中，I/O 是非常低速的阻塞部分。所以，（从页面 /UI 的角度来说）浏览器在后台异步处理控制台 I/O 能够提高性能，这时用户甚至可能根本意识不到其发生。

比如下面一段简单的代码：

var a = {
 index: 1
};
// 然后
console.log( a ); // ??
// 再然后
a.index++;

我们通常认为恰好在执行到 console.log(..) 语句的时候会看到 a 对象的快照，打印出类似于 { index: 1 } 这样的内容，然后在下一条语句 a.index++ 执行时将其修改，这句的执行会严格在 a 的输出之后。

多数情况下，前述代码在开发者工具的控制台中输出的对象表示与期望是一致的。但是，这段代码运行的时候，浏览器可能会认为需要把控制台 I/O 延迟到后台，在这种情况下，等到浏览器控制台输出对象内容时，a.index++ 可能已经执行，因此会显示 { index: 2 }。到底什么时候控制台 I/O 会延迟，甚至是否能够被观察到，这都是游移不定的。如果在调试的过程中遇到对象在 console.log(..) 语句之后被修改，可你却看到了意料之外的结果，要意识到这可能是这种 I/O 的异步化造成的。

如果遇到这种少见的情况，最好的选择是在 JavaScript 调试器中使用断点，而不要依赖控制台输出。次优的方案是把对象序列化到一个字符串中，以强制执行一次“快照”，比如通过 JSON.stringify(..)。

【分享、点赞、在看】三连吧，让更多的人加入我们