实际上，我最近发现with语句非常有用。直到我开始了我目前的项目——一个用JavaScript编写的命令行控制台，我才真正意识到这个技术。我试图模拟Firebug/WebKit控制台api，其中特殊命令可以输入到控制台，但它们不会覆盖全局作用域中的任何变量。当我试图解决我在Shog9的精彩答案的评论中提到的一个问题时，我想到了这个。

为了达到这个效果，我使用了两个with语句将一个作用域“分层”到全局作用域后面:

with (consoleCommands) {
    with (window) {
        eval(expression); 
    }
}

这种技术的优点在于，除了性能方面的缺点外，它不会遭受with语句通常带来的恐惧，因为无论如何我们都是在全局作用域中求值——没有伪作用域之外的变量被修改的危险。

让我惊讶的是，当我设法找到在其他地方使用的相同技术时，我受到了启发，发布了这个答案——Chromium源代码!

InjectedScript._evaluateOn = function(evalFunction, object, expression) {
    InjectedScript._ensureCommandLineAPIInstalled();
    // Surround the expression in with statements to inject our command line API so that
    // the window object properties still take more precedent than our API functions.
    expression = "with (window._inspectorCommandLineAPI) { with (window) { " + expression + " } }";
    return evalFunction.call(object, expression);
}

编辑:刚刚检查了Firebug的源代码，它们将4条语句链接在一起，形成更多的层。疯了!

const evalScript = "with (__win__.__scope__.vars) { with (__win__.__scope__.api) { with (__win__.__scope__.userVars) { with (__win__) {" +
    "try {" +
        "__win__.__scope__.callback(eval(__win__.__scope__.expr));" +
    "} catch (exc) {" +
        "__win__.__scope__.callback(exc, true);" +
    "}" +
"}}}}";

正如我之前的评论所指出的，我不认为你可以安全地使用它，无论它在任何给定的情况下有多么诱人。由于这里没有直接涉及到这个问题，我将重复一遍。考虑以下代码

user = {};
someFunctionThatDoesStuffToUser(user);
someOtherFunction(user);

with(user){
    name = 'Bob';
    age  = 20;
}

如果不仔细研究这些函数调用，就无法知道这段代码运行后程序的状态是什么。如果user.name已经设置，它现在将是Bob。如果没有设置，全局名称将被初始化或更改为Bob，用户对象将保持没有name属性。

错误发生。如果你使用with，你最终会这样做，增加你的程序失败的机会。更糟糕的是，您可能会遇到在with块中设置全局变量的工作代码，或者是故意的，或者是作者不知道这个构造的怪处。这很像在开关上遇到了故障，你不知道作者是否有意这样做，也没有办法知道“修复”代码是否会引入回归。

现代编程语言充满了特性。一些特性，在使用多年后，被发现是不好的，应该避免使用。Javascript的with就是其中之一。

我正在开发一个项目，该项目允许用户上传代码以修改应用程序部分的行为。在这个场景中，我一直使用with子句来防止他们的代码修改超出范围的任何东西。我用来做这件事的(简化)代码部分是:

// this code is only executed once
var localScope = {
    build: undefined,

    // this is where all of the values I want to hide go; the list is rather long
    window: undefined,
    console: undefined,
    ...
};
with(localScope) {
    build = function(userCode) {
        eval('var builtFunction = function(options) {' + userCode + '}');
        return builtFunction;
    }
}
var build = localScope.build;
delete localScope.build;

// this is how I use the build method
var userCode = 'return "Hello, World!";';
var userFunction = build(userCode);

这段代码(一定程度上)确保用户定义的代码既不能访问任何全局作用域的对象，如window，也不能通过闭包访问任何局部变量。

简单地说，我仍然必须对用户提交的代码执行静态代码检查，以确保他们没有使用其他偷偷摸摸的方式访问全局作用域。例如，下面的用户定义代码获取对window的直接访问:

test = function() {
     return this.window
};
return test();

Visual Basic。NET有一个类似的With语句。我使用它的一个比较常见的方法是快速设置一些属性。而不是:

someObject.Foo = ''
someObject.Bar = ''
someObject.Baz = ''

，我可以这样写:

With someObject
    .Foo = ''
    .Bar = ''
    .Baz = ''
End With

这不仅仅是懒惰的问题。它还使代码可读性更强。与JavaScript不同的是，它不会出现歧义，因为您必须在受语句影响的所有内容前加上a。(点)。所以，下面两个是明显不同的:

With someObject
    .Foo = ''
End With

vs.

With someObject
    Foo = ''
End With

前者是someObject.Foo;后者是someObject作用域外的Foo。

我发现JavaScript缺乏区分使得它远不如Visual Basic的变体有用，因为歧义的风险太高了。除此之外，with仍然是一个强大的想法，可以提高可读性。

我认为对象文字的使用很有趣，就像使用闭包的一个插入式替换

for(var i = nodes.length; i--;)
{
       // info is namespaced in a closure the click handler can access!
       (function(info)
       {           
            nodes[i].onclick = function(){ showStuff(info) };
       })(data[i]);
}

或者与闭包等价的with语句

for(var i = nodes.length; i--;)
{
       // info is namespaced in a closure the click handler can access!
       with({info: data[i]})
       {           
            nodes[i].onclick = function(){ showStuff(info) };
       }        
}

我认为真正的风险是不小心操纵不属于with语句的变量，这就是为什么我喜欢将对象文字传递给with，你可以确切地看到它将在代码中添加的上下文中。

My

switch(e.type) {
    case gapi.drive.realtime.ErrorType.TOKEN_REFRESH_REQUIRED: blah
    case gapi.drive.realtime.ErrorType.CLIENT_ERROR: blah
    case gapi.drive.realtime.ErrorType.NOT_FOUND: blah
}

归结起来就是

with(gapi.drive.realtime.ErrorType) {switch(e.type) {
    case TOKEN_REFRESH_REQUIRED: blah
    case CLIENT_ERROR: blah
    case NOT_FOUND: blah
}}

你能相信这么低质量的代码吗?不，我们看到它是完全不可读的。这个例子无可否认地证明了没有必要使用with-statement，如果我的可读性是正确的;)