JavaScript中沙箱理解
转自：http://www.infoq.com/cn/articles/sandboxOnB

javascript中的沙箱并非传统意义上的沙箱，只是一种语法上的hack写法而已，javascript中处理模块依赖关系的闭包被称之为沙箱，和 ajax一样，这种sandbox coding风格是一种现象，而不是本质，本身并无对错之分，要看你怎么用，因此，理解并合理运用才是我们对“js沙箱”的一个正确的基本态度，“沙箱无用论”是很业余的观点。
——沙箱是一个工具。就和键盘和鼠标一样，我们需要他，但更要看我们怎么用他。

目前来看，js沙箱的优势在于代码的组织并向“应用”提供架构支持，js沙箱解决不了全局变量污染，多版本库的融合等基本问题，很多人对js沙箱抱有太高奢望，也是不对的。
—— 沙箱是一把利器。就像AK是巷战之王，可还是有人硬要拿它打飞机。

js沙箱已经开始影响B端开发，而且在前后端融合方面具有更多前瞻性的优势。
——沙箱是一把钥匙。ajax的流行改变了B端开发模式，我们有理由期待js沙箱在企业级开发中的表现。

当JavaScript第一次发布的时候，有一个可以理解的忧虑，那就是打开一个页面可能会直接在机器上执行一段代码。如果JavaScript中含有一些有害的代码，比如删除所有Word文档，或者更糟的是，向脚本的编写者复制这些Word文档，那该怎么办呢？

为了防止这种情况发生，同时也为了让浏览器的用户放心，JavaScript构建为只在沙箱中运行。沙箱是一个受保护的环境，在这个环境中，脚本不能访问浏览器所在的计算机资源。

另外，浏览器所实现的安全条件高出并超过了JavaScript语言所建立的最低条件。这些都定义在一个与浏览器相关的安全策略中，它决定了脚本能做什么不能做什么。例如，一个这样的安全策略规定脚本不能与脚本所来源的域以外的页面通信。大多数浏览器还提供了定制这一策略的方式，这可以使脚本所运行的环境限制变得更严或更松。

不幸的是，即便是有了JavaScript沙箱和浏览器安全策略，JavaScript还是经过了一段难熬的时光，黑客已经发现并充分利用了JavaScript的一些错误，有些错误与浏览器无关，有些错误与浏览器有关。较严重的一个是跨站脚本（cross-site scripting，XSS）。这实际上是一类安全破坏（其中一些通过JavaScript，另一些通过浏览器的漏洞，还有一些通过服务器），它能够导致 cookie dao qie、暴露客户端或网站的数据，或导致许多其他的严重问题。

从语言学的角度上来说，允许代码无节制地使用全局变量，是最错误的选择之一。而更可怕的，就是一个变量"可能"成为全局的（在未知的时间与地点）。但是这两项，却伴随JavaScript这门语言成功地走到了现在。
相关厂商内容

Flex 4 in Action书摘：格式化数据

开发人员访谈：David Lenaerts

使用 HTML5 Pack for Dreamweaver CS5

IBM 360°讲师团招募：每个爱技术乐分享的人都有机会

创建移动富互联网应用(RIA)的设计技巧

也许是限于浏览器应用的规模，所以这一切还迟迟没有酿成灾难。在此之前，出现了两种解决方案。一种是ECMA在新的规范（Edition 5）中对此做出了限制，其中最重要的一条便是eval()的使用变得不再随意和无度。而另一种方案，则是相对没有那么官僚与学术的，尽管也拥有一个同样学术的名字：沙箱。

沙箱（Sandbox）并不是一个新东西，即使对于JavaScript来说，也已经存在了相当长的时间。在SpiderMonkey JS的源代码中，就明确地将一个闭包描述为一个沙箱。这包含着许多潜在的信息：它有一个初始环境，可以被重置，可以被复制，以及最重要的，在它内部的所有操作，不会影响到外部

当然事实上远非如此。JavaScript里的闭包只是一个"貌似沙箱"的东西--仍然是出于JavaScript早期的语言规范的问题，闭包不得不允许那些"合法泄漏"给外部的东西。而对于这一切无法忍受的前端工程师们，开始寻求另外的解决之道，这其中相对较早的尝试，是基于IFRAME的实践。例如dean.edwards在2006年提出过的方案（注1）：

a_frames.document.write(
  "<script>"+
  "var MSIE/*@cc_on =1@*/;"+ // sniff
  "parent.sandbox=MSIE?this:{eval:function(s){return eval(s)}}"+
  "<\/script>"
);

显然，由于在不同的IFRAME中运行着各自的JavaScript引擎实例，所以上述的方案也意味着沙箱是"引擎"这个级别的：在任何一个沙箱中的崩溃，将导致该引擎以及对应IFRAME崩溃。但--理论上说--不会影响整个浏览器。

问题是，这并不那么理想。往往的，引擎会导致整个浏览器锁在那里，例如用alert()弹出一个对话框而又因为某种意外失去了焦点。又或者单个的 IFRAME会导致全局的CPU被耗光，例如一个死循环。于是更加复杂的方案--在JavaScritp中包含一个完整的执行器--出现了。最有名的则是 Narrative JavaScript，它内建了一个执行器，用于逐行地解释执行JavaScript代码，这使得它可以控制所有的代码执行序列，或者随时重置整个执行引擎--如同一个沙箱所要做的那样。

这一切或者太过依赖于环境，又或者太过复杂，但都不乏追随者。例如jsFiddle这个项目（注2）在"嵌入或装载"这样的路子上就已经有了不俗的成绩。但是，YUI在新版本中却给出了它自己的选择：以更加明确的编程约定，来实现应用级别的沙箱。这包括一个非常简单的、新的YUI语法：

YUI().use('dom-base', function(Y) {
  // Y是一个新的沙箱
});

在'dom-base'位置上，可以是1到N个字符串，表明一个需要在沙箱中装载的模块列表。这可以是沙箱的初始列表，或者后续的callback 函数(亦即是用户代码)所需依赖的模块列表。在这种实现方案中，YUI为每个沙箱维护各自的装载模块列表和上下文环境中的变量、成员。但是出于 JavaScript语言自己的局限，这个沙箱依然是相当脆弱的。例如下一示例中沙箱内的代码就会污染到全局：

YUI().use('', function(Y) {
  abc = 1234;  //<--这里可能导致一个全局变量'abc'被隐式地声明
});

同样，在上述的沙箱里也可以使用类似window、document等全局变量、修改它们的成员或无限制地调用方法（例如使用 setTimeout()来创建时钟）。所以YUI的沙箱事实上是靠"规约"来约束的，而不是真正意义上的沙箱。当然，这也意味着，如果用户能按照规约来处理沙箱内的代码，那么也就能自由地享用它带来的便利：安全、移植和有效的隔离副作用。

而我们再穷究其根底，YUI沙箱的实质不过是一行:

// code from yui.js
//  - mod.fn(this, name)
mod.entryFunc(sandbox, modName);

其实际含义是：

    * mod ：沙箱当前装载的模块；
    * entryFunc : 上述模块的入口函数；
    * sandbox ：当前的沙箱的实例，即YUI()返回值；
    * modName：模块名

除了依赖关系（以及可能需要的异步加载）之外，YUI沙箱环境仅是用下面的代码来简单地调用callback函数：

callback(Y, response);

然而这些需求的实现并不那么复杂。首先，我们设定数据结构mod为一个对象：

{ name:modName, fn: entryFunc, req: [], use: [] }

则一个环境对象env，将包括多个mod(将它们处理成对象而非数组，主要是便于使用名字来索引模块)和以及对它们进行管理操作的方法：

{ mods:{}, used:{}, add:..., use