我从来没有使用过，没有理由，也不推荐它。

with的问题是它阻止了ECMAScript实现可以执行的大量词汇优化。随着基于jit的快速引擎的兴起，这个问题在不久的将来可能会变得更加重要。

它可能看起来像允许更清晰的结构(例如，引入一个新的作用域而不是公共的匿名函数包装器或替换冗长的别名)，但实际上不值得这样做。除了性能下降之外，还存在给错误对象的属性赋值的危险(当在注入作用域中的对象上找不到属性时)，以及可能错误地引入全局变量。IIRC，后一个问题是促使Crockford建议避免的问题。

似乎不值得，因为你可以做到以下几点:

var o = incrediblyLongObjectNameThatNoOneWouldUse;
o.name = "Bob";
o.age = "50";

CoffeeScript的Coco fork有一个with关键字，但它只是简单地将this(在CoffeeScript/Coco中也可以写成@)设置为块中的目标对象。这消除了歧义，实现了ES5严格模式兼容:

with long.object.reference
  @a = 'foo'
  bar = @b

我认为最明显的用途是作为捷径。例如，如果你初始化一个对象，你只需节省大量输入“ObjectName”。有点像lisp的“带槽”，让你可以写

(with-slots (foo bar) objectname
   "some code that accesses foo and bar"

这和写作是一样的吗

"some code that accesses (slot-value objectname 'foo) and (slot-value objectname 'bar)""

当你的语言允许“Objectname”时，这是一个更明显的快捷方式。但是还是。

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

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，你可以确切地看到它将在代码中添加的上下文中。

是的，是的，是的。有一个非常合理的用法。看:

with (document.getElementById("blah").style) {
    background = "black";
    color = "blue";
    border = "1px solid green";
}

基本上任何其他DOM或CSS钩子都是with的奇妙用途。这并不是说“CloneNode”将是未定义的，并返回到全局作用域，除非你走出你的方式，决定让它成为可能。

Crockford对速度的抱怨是with创建了一个新的上下文。上下文通常是昂贵的。我同意。但如果你只是创建了一个div，没有一些框架来设置你的css，需要手动设置15个左右的css属性，那么创建一个上下文可能会比创建变量和15个解引用更便宜:

var element = document.createElement("div"),
    elementStyle = element.style;

elementStyle.fontWeight = "bold";
elementStyle.fontSize = "1.5em";
elementStyle.color = "#55d";
elementStyle.marginLeft = "2px";

等等……