声明没有 var 关键字的变量

No, there's no RAM benefit or anything like that.

What w3schools is talking about is something I call The Horror of Implicit Globals. Consider this function:

function foo() {
var variable1, variable2;


variable1 = 5;
varaible2 = 6;
return variable1 + variable2;
}

Seems simple enough, but it returns NaN, not 11, because of the typo on the varaible2 = 6; line. And it creates a global variable with the typo'd name:

function foo() {
var variable1, variable2;


variable1 = 5;
varaible2 = 6;
return variable1 + variable2;
}
console.log(foo());     // NaN
console.log(varaible2); // 6?!?!?!

This is because the function assigns to varaible2 (note the typo), but varaible2 isn't declared anywhere. Through the mechanics of the scope chain in JavaScript, this ends up being an implicit assignment to a (new) property on the global object (which you can access as window on browsers, or globalThis in modern environments).

That's just a "feature" of loose-mode JavaScript, assigning to a completely undeclared identifier isn't an error; instead, it creates a property on the global object, and properties on the global object are global variables. (Up through ES5, all globals were properties of the global object. As of ES2015, though, a new kind of global was added that isn't a property of the global object. Global-scope let, const, and class create the new kind of global.)

My example is a typo, but of course, you could do it on purpose if you wanted. But I'd strongly advise not doing so. Instead, I recommend always using strict mode, either directly or by using ECMAScript modules (ESM, JavaScript's own module system added in ES2015), which are strict by default. Strict mode makes assigning to an undeclared identifier an error rather than silently creating a global. If we'd been using strict mode, the problem with the foo function above would have been much more obvious and easier to diagnose:

"use strict"; // Turns on strict mode for this compilation unit


function foo() {
var variable1, variable2;


variable1 = 5;
varaible2 = 6;                 // <=== ReferenceError
return variable1 + variable2;
}
console.log(foo());

Somewhat tangential, but in general I'd recommend avoiding globals wherever possible. The global namespace is already very, very cluttered on browsers, which makes it easy to accidentally create conflicts. The browser creates a global for every element in the DOM with an id, for most elements with a name, and has several predefined globals of its own (like name and title) which can easily conflict with your code.

Instead, use JavaScript modules (ESM). Top-level declarations in a module aren't globals, they're only global to the code in that module. Then you can use export to intentionally expose the parts of your code you want other modules to be able to use (via import).

Here in 2022, you can almost always use ESM; it's well-supported by modern browsers and by Node.js. If you have to target an obsolete environment that doesn't support it (like Internet Explorer), you can use a bundler to wrap up your ESM code into a bundle instead.

If for some reason you can't use ESM, you can do what we used to do before modules were standardized: Use a scoping function wrapped around your code:

(function() {
var your, symbols, here, if_they_need, to_be_shared, amongst_functions;


function doSomething() {
}


function doSomethingElse() {
}
})();

And if you do that, you might want to enable strict mode:

(function() {
"use strict";
var your, symbols, here, if_they_need, to_be_shared, amongst_functions;


function doSomething() {
}


function doSomethingElse() {
}
})();

...which, as mentioned, has the advantage of turning assignments to undeclared identifiers into errors (along with various other helpful things).

If you have to make something global, you can assign to a property on window. (In modern environments, I'd say you can assign to a property on globalThis, but if you can't use ESM, it's unlikely the environment you're targeting supports globalThis.)

The only use of global variables is if you need to access them globally. In that case you should declare them using the var keyword outside the functions, to make it clear that you really want to create global variables, and didn't just forget the var when trying to declare a local variable.

Generally you should try to scope your code so that you need as little as possible in the global scope. The more global variables you use in your script, the less is the chance that you can use it along side another script.

Normally variables in a function should be local, so that they go away when you exit the function.

Sometimes its useful to create new globally accessible properties inside functions which can later be easily accessed by referencing the window object (all globally declared properties are attached to the window object).

However as it usually is with declaring anything to be globally accessible it can lead to problems later because those properties can be easily overwritten etc. Its far better to simply pass values to functions as arguments and retrieve their results.

The main problem is someone else may already be using a global with the same name.

Then when you change the value of the global you'll overwrite their value.

Later on when the global is next used it will have mysteriously changed.

Side Effects When Forgetting var

There’s one slight difference between implied globals and explicitly defined ones. The difference is in the ability to undefine these variables using the delete operator:

• Globals created with var (those created in the program outside of any function) cannot be deleted.

• Implied globals created without var (regardless if created inside functions) can be deleted.

This shows that implied globals are technically not real variables, but they are properties of the global object. Properties can be deleted with the delete operator whereas variables cannot:

// define three globals
var global_var = 1;
global_novar = 2; // antipattern
(function () {
global_fromfunc = 3; // antipattern
}());
// attempt to delete
delete global_var; // false
delete global_novar; // true
delete global_fromfunc; // true
// test the deletion
typeof global_var; // "number"
typeof global_novar; // "undefined"
typeof global_fromfunc; // "undefined"

In ES5 strict mode, assignments to undeclared variables (such as the two antipatterns in the preceding snippet) will throw an error.

JavaScript Patterns, by Stoyan Stefanov (O’Reilly). Copyright 2010 Yahoo!, Inc., 9780596806750.

I would say that it might hurt your security and even stability of your code.

As was mentioned above, you might make a mistake by simply misspelling your variables and a solution is the keyword "use strict";
With this keyword declared it will throw you an error: Uncaught ReferenceError: foo is not defined.

It also refers to a secured code:
1. When writing a secured code, we do not want our variables to be accessed anywhere besides where they were actually declared. Do not declare global variables without the need.
2. Always read warnings carefully and resolve them. Use "use strict";, JSlint and other tools to see and resolve warning to make your code better.

Declaring a variable inside of a function without the use of var, let, or const is no more useful inside the function than is declaring that variable with var, let, or const. And, as noted in previous answers to this question, function-local, implicit global declarations can be confusing and problematic outside the scope of the function where they were declared.

I'd like to speak to some subtleties that are missing from the w3schools quote, and from previous answers to this question.

First of all, if you never call the function that generates implicit globals, you won't generate any implicit globals. This is a subtle difference from the w3schools quote because it defies the "always" section of their statement.

function generateImplicitGlobals(){
x = "x";
window.y = "y";
}


// before calling the generateImplicitGlobals function, we can safely see that the x and y properties of the window object are both undefined:
console.log("before calling the generateImplicitGlobals function, properties x and y of the window object are: " + window.x + " and " + window.y);


// before calling the generateImplicitGlobals function, we can test for the existence of global variables x and y; note that we get errors instead of undefined for both.
try{
console.log("before calling the generateImplicitGlobals function, x is: " + x);
}
catch(e){
console.log("before calling the generateImplicitGlobals function, an attempt to reference some global variable x produces " + e);
}


try{
console.log("before calling the generateImplicitGlobals function, y is: " + y);
}
catch(e){
console.log("before calling the generateImplicitGlobals function, an attempt to reference the global variable b also produces " + e);
}

Regarding subtleties of previous answers, once the generateImplicitGlobals function has been called, we can see that attempts to access either the window.x property or the global variable x return the same values (and that the window.y property and the global y variable return the same values). These statements are true when called from inside or outside the generateImplicitGlobals function.

function generateImplicitGlobals(){
x = "x";
window.y = "y";
console.log("inside the function, x and window.x are: " + x + " and " + window.x);
console.log("inside the function, y and window.y are: " + y + " and " + window.y);
}


// now, call the generator, and see what happens locally and globally.
generateImplicitGlobals();
console.log("after calling the generateImplicitGlobals function, x, window.x, y, and window.y are: " + x + ", " + window.x + ", " + y + ", and " + window.y);

For what it's, worth "variables" can be appended to the arguments list in a function.

If you assign a new value to an argument, it is doesn't affect the callers perpsective of that argument , (even with an object, the variable that points to the object itself is unique to the function. properties of that object can be modified, but replacing the object entirely has no impact on the original object).

Assigning a new value to a named argument replaces it temporarily for the current scope (and derived scopes).

There is no difference between an argument and a variable in that respect, from the interpreters point of view. even if the caller does not supply a value, an empty variable is implied for each unused argument

Also, you can create externally available "persistent" variables by simply assigning values to a named function - they are in fact objects themselves.this can even be done from inside the function.

function noVars(a1,/*vars=*/v1,v2,v3) {
if (noVars.lastA1===a1) return noVars.lastAnswer;


noVars.lastA1=a1;


v1=a1*a1;
v2=v1*v1;
v3=v2*v2*v2;


noVars.lastAnswer = a1+v1+v2+v3;


return noVars.lastAnswer;
}

the main difference is these "persistent" values survive between each call, whilst values in var,let, arguments are "empty vessels" at the start of each call. arguments can be preset by the caller, otherwise they are "undefined".

this might be seen as abusing the agument system, i see it as using it in non-standard way. any changes to the javascript spec that stops this working, would also break the fact that passing a value to an function is always "by value", even with object (the fact that an object is itself a reference is irrelevant).

this will also work:

var noVars = function (a1,/*vars=*/v1,v2,v3) {
if (noVars.lastA1===a1) return noVars.lastAnswer;


noVars.lastA1=a1;


v1=a1*a1;
v2=v1*v1;
v3=v2*v2*v2;


noVars.lastAnswer = a1+v1+v2+v3;


return noVars.lastAnswer;
};