The article has been updated with new content and a more in-depth analysis of the wave

As a front-end development, JS debugging is a necessary skill. Whether you’re looking for bugs, or want to understand the logic of someone else’s code, JS debugging is a great way to save time.

Download Through Train

The purpose of this article is not to share the use of a series of debugging tools such as formatting code, setting breakpoints, viewing the call stack, viewing variables, etc. There are many good articles on the web. This article mainly analyses the work encountered in the debugger, as shown in the following figure:

Sometimes when we are on someone else’s website, we can use JavaScript debugging tools to set breakpoints to prevent the code from executing in order to understand the function of the code. Then analyze the execution environment of breakpoints, objects, variables and a series of useful information to complete the interpretation of code logic.

In JavaScript, we can use the debugger instruction directly to break the code in the specified location, for example 🌰

console.log('you can see me')
debugger
console.log('can you see me? ')
Copy the code

The result is actually quite obvious, you can see the output of the first line, but when you run to the second line, the code is broken, and you can only see the output of the third line if you continue manually. This is the principle that many commercial production code will define a wireless loop debugger instruction, which is intended to

  • Constantly interrupting you, wasting your time
  • Keep creating non-recyclable objects that take up your memory, causing memory leaks, and before long the browser will stall, or even fill up your CPU

Here is a simple and easy to understand 🌰

setTimeout(function() {while (true) {
		debugger
	}
},100)
Copy the code

How do we deal with a situation like this? After a Google search, the common solution is:

Deactivate Breakpoint, does it solve the problem?

Just look at the picture below. By ignoring all breakpoints, even those you set yourself (your breakpoint is meaningless), you continue to execute the debugger, create objects, and your CPU will run full, which I have found unreliable in practice. Move it! Next!

Another trick is to disable breakpoints, see the following figure

We’ll get to the point. How do we solve that? 

_0x51c762();
setInterval(function() {
    _0x51c762()
}, 0xfa0);
Copy the code

Use Charles (I used this, you can use other capture tools) to redirect to the JS file you made the changes to

var timelimit = 50;
var open = false;
var starttime = new Date();
debugger;
if (new Date() - starttime > timelimit) {
    open = true; // Perform your undebugging logic here, such as delete operation open =false;
}
Copy the code

Like how do we solve it? It’s as simple as breaking a point and increasing timelimit (e.g. Timelimit = 1000000). There might actually be other criteria, but we just have to set the breakpoint to false once to make sure that it doesn’t go into the conditional statement in the debugger and hopefully that’s helpful

Without my permission, shall not be reproduced, the article omissions superficial place, please be corrected