一起console.log()引发的血案

小小码 • 2023-08-12 14:30 • 未分类 • 阅读 117

大家好，我是考100分的小小码，祝大家学习进步，加薪顺利呀。今天说一说一起console.log()引发的血案,希望您对编程的造诣更进一步.

案发现场:

let timing = window.performance.timing,
    timingStr = JSON.stringify(timing),
    domContentLoadedEventStart = timing.domContentLoadedEventStart
    console.log("timing:", timing)
    console.log("timingStr:", timingStr)
    console.log("domContentLoadedEventStart:", domContentLoadedEventStart)

以上代码执行结果：

三种方式打印出来的值竟然不一样！

推断取证：

看上述结果：如果直接打印timing对象，可以拿到domContentLoadedEventStart的值，而经过JSON.stringify或者打印的是timing.domContentLoadedEventStart，值都不对。

难道是在这个三个console.log()执行的过程中，页面的performance.timing的值发生了改变，然后我将三个console.log()的执行顺序做了调整，发现结果还是一样：只有直接打印timing拿到了值。
使用debugger看实时数据：神奇的是，debugger状态下三种打印方式的值是相同的，timing.domContentLoadedEventStart都为0。
使用setTimeOut延时再使用三种打印方式，三个的值又全都有值，且值相同。

综合上述，不禁让我怀疑：console.log是不是异步执行？

真相：

果不其然，domContentLoadedEventStart前后值的不同果然和console.log()有关系。

原来， 控制台中console.log()是在打印对象的时候采用了懒加载的思路，在用户点击展开对象属性的时候，才会去获取该属性。所以就解释了为什么我们在控制台中看到的timing对象的domContentLoadedEventStart属性有值，而以字符串方式，或者直接打印该对象的value时为0。另外，在Chrome的控制台中，如果打印的对象，被改变过对象值，会在对象后面出现一个可点击的i号，点击这个i号，我们可以清楚的看见这个值，被改变了。