Recently I helped a colleague debug backend when console.log()he said that the result is not correct, because the situation is synchronous or asynchronous output will appear. Access to information, after finishing his own, discovered the existence of this problem.
Symptom
Analysis abnormal
Prior to the analysis, we have to know a little, JS objects are reference types, each time you use the object, just use the objects in the heap references.
console.logThe print was of snapshot object, expand the object when it is actually read objects in memory to re-attribute values.
Browser or you can say why the developer tools will have such a performance?
"You do not know javascript in volume," the second part of asynchronous and asynchronous performance section 1.1 console section has mentioned:
There is no specification or set of requirements around how the console.* methods work – they are not officially part of JavaScript, but are instead added to JS by the hosting environment (see the Types & Grammar title of this book series).
So, different browsers and JS environments do as they please, which can sometimes lead to confusing behavior.
In particular, there are some browsers and some conditions that console.log(…) does not actually immediately output what it’s given. The main reason this may happen is because I/O is a very slow and blocking part of many programs (not just JS). So, it may perform better (from the page/UI perspective) for a browser to handle console I/O asynchronously in the background, without you perhaps even knowing that occurred.
translation:
And there is no norm or a set of requirements specified console * family of methods how to work - they are not formally part of JavaScript, but added by the host environment (please refer to the book "type and syntax" section) to JavaScript. Therefore, different browsers and JavaScript environments can be implemented in accordance with their wishes, which sometimes cause confusion.
In particular to make it is, under certain conditions, some browsers console.log (...) does not put the incoming content output immediately. Main reason for this is that many programs (not just the JavaScript) in, I / O is very low blocking portion. So, (from the perspective of the page UI / speaking) browser asynchronously in the background processing console I / O performance can be improved, then the user may not even aware of its occurrence.
The book also gave an example:
var a = {
index: 1
};
// 然后
console.log( a ); // ??
// 再然后
a.index++;
We usually think just to execute console.log(..)when the snapshot is a statement of the object, similar to print out { index: 1 }such content, then the next statement a.index++is executed to modify the sentence will be executed strictly after the output of a.
In most cases the object code output in the console developer tools, said the expectation is the same. However, when running this code, the browser might think need to console I / O latency into the background, in this case, until the console output target content browser, a.index++may have been performed, and therefore will show {index : 2 }.
In the end when the console I / O will be delayed, even if that can be observed, this is wandering.
So if you encounter an object in the debugging process is modified after console.log (...) statement, but you can see the results unexpected, be aware of this which may be asynchronous I / O caused.
If you encounter these rare cases, the best option is to use breakpoints in the JavaScript debugger, instead of relying on the console output. Suboptimal solution is to serialize the object into a string, to enforce a "snapshot", such as by JSON.stringify (...).
in conclusion
Conclusion: console.log to print out the contents do not necessarily correct. For general common type number、string、boolean、null、undefinedof output it is authentic. But for Objectsuch as reference types, then the abnormal printout will appear.
So for the average basic types of debugging, use console.log to output the content, there will be no pit when debugging. But when debugging an object, it is best to use break points ( debugger) in such a way to debug better.