脚本合并时混淆隔离的三个级别

[b]直接合并－－传统方式[/b]
根据脚本依赖关系，组织好导入顺序，简单的合并成单个大文件。
这是最常见简单功能的一种合并方式。通常也不需要任何工具的支持。由程序员手动完成。
[b]优点[/b]：简单
[b]缺点[/b]：需要程序员自己管理脚本名称冲突。


[b]间接依赖全局变量的隔离－－JSI运行时等价的隔离策略[/b]
就是说，比如你在脚本包p1有一个脚本A 依赖脚本元素B，脚本元素B依赖仍外一个脚本包p2中的脚本元素A,如果你采用直接合并的话，两个包中都有一个名为A的元素，直接合并一定会产生冲突。
这时，就需要我们在最后导出发布脚本时，做好这种隔离操作。
如：我们正真直接使用的只是p1包中的A，那么这些元素导出前后变量名映射可能是：
[code]A(p1)->A
B(p1)->a_
A(p2)->b_[/code]

[b]优点[/b]：借助外力，很好的解决了冲突问题。
[b]缺点[/b]：支持工具实现比较复杂。


[b]内部变量隔离合并－－简化版本[/b]

脚本文件A.js中可能由多个全局变量：A、 _temp、 index 、status。
但是，除A外，其他都是都不希望被其他脚本访问，就是说，虽然从JS语法上，他们也算全局变量。但是，我更愿意把他看作一种内部变量，或者说脚本文件内可以访问的变量。这里，我们称他们为内部变量（JSI中，未在包定义文件中添加的脚本元素，即是这种类型）
实事上。如果你习惯了由工具管理这些内部变量，那么，你一定会经常的使用他们，因为他们才是真正简单的JS私有元素实践。
如果我们的合并混淆器能达到这个隔离级别，那么我们就可以大胆的大量使用这类设计了。


[b]优点[/b]：借助外力，解决了大部分冲突问题，支持工具实现相对简单。
[b]缺点[/b]：支持工具实现依然比较复杂。