上一篇发出来后得到了很多回复，在此首先感谢大家的热情捧场！有的推荐第三方框架，比如 In.js、requrieJS、sea.js、lab.js等。这个开阔了眼界，以前只知道sea.js，省去了自己搜索的麻烦。也用了点时间简单看了一下，因为每一个都是大块头，都有自己的理念，如果只是简单使用的话，那么谁便找一个就可以了，但是我习惯把原理弄清楚。因为我觉得虽然不知道原理也可以使用，但是知道了原理后，可以用的更好。
主要看的是sea.js，目前简单的理解是：一个加载js的机制 + 模块化编程(CMD规范)的理念。这个是淘宝用的，肯定很强大、很结实了。那么我是不是拿来用呢？这就要看看我到底想要什么，以及改动量大小。
那么我想要啥呢？第一步只想要一个可以动态加载js的代码，越简单越好。为啥呢？越简单就越不需要修改。为啥要求不需要修改呢？因为我想达到的效果是，每个页面只需要 这么一行，就可以把所有的共用的js文件都统统的加载进来，并且可以自动更新。
不知道大家有没有发现一个问题，boot.js 可以搞定其他js文件的更新，但是他自己的更新如何搞定呢？有两个方法，一个是在后面加个随机数作为参数；另一个就是一辈子都不需要修改。我不想用前者，因为每次都要去服务器加载，和初衷不符。我想用后者，当然我也知道，不可能一辈子不变，只能尽量延迟修改的时间。所以就需要——简单。越简单越不需要修改，也就可以保持更长的时间。所以我起名叫做 boot。就是一个简单的引导（加载）的功能。
第二步才开始真正的管理js文件。这时候可以考虑使用第三方框架，当然也可以自己写。因为我可以用boot.js来确保加载哪些文件，以及加载最新的文件。在第二步就需要确定一个解决方案。我的想法就是做一个js文件服务。由这个服务实现加载js、更新js、加载顺序（依赖），还有复用。
如果我们要做五个项目，每个项目都是一个独立的站点，那么对于共用的js文件是怎么处理的呢？1、每个项目站点都放一份，引用自己站点里的。2、做一个独立的站点存放共用的js，然后其他的项目都统一到这里引用。我用的是第二个方法，你们呢？
突然想到一个问题，我们写js到底要达到什么目的（效果）？基础功能（jQuery、my97、editor等）、UI（easyUI等）、处理业务逻辑（做点判断了啥的）。还有其他的啥。我们每写一个js文件，都需要考虑要引用哪些文件吗？目前我做的项目是，由js文件服务来搞定js文件的加载，然后写点处理业务逻辑的代码就ok了。
想说的还有很多，只是思路有点乱。后续要上具体的代码了，不知道大家是不是喜欢。
ps：
面对的问题。引用 https://github.com/seajs/seajs/issues/547
恼人的命名冲突
我们从一个简单的习惯出发。我做项目时，常常会将一些通用的、底层的功能抽象出来，独立成一个个函数，比如
function each(arr) {
// 实现代码
}
function log(str) {
// 实现代码
}
并像模像样地把这些函数统一放在 util.js 里。需要用到时，引入该文件就行。这一切工作得很好，同事也很感激我提供了这么便利的工具包。
直到团队越来越大，开始有人抱怨。
小杨：我想定义一个 each 方法遍历对象，但页头的 util.js 里已经定义了一个，我的只能叫 eachObject 了，好无奈。
小高：我自定义了一个 log 方法，为什么小明写的代码就出问题了呢？谁来帮帮我。
抱怨越来越多。团队经过一番激烈的讨论，决定参照 Java 的方式，引入命名空间来解决。于是 util.js 里的代码变成了
var org = {};
org.CoolSite = {};
org.CoolSite.Utils = {};
org.CoolSite.Utils.each = function (arr) {
// 实现代码
};
org.CoolSite.Utils.log = function (str) {
// 实现代码
};
引用结束。
现在我采用的也是命名空间的方式，当然是按照.net的习惯来的。
好的js文件艾
不知不觉居然写了这么多。用命名空间确实便于管理。尤其是管理源码。另外也应该学习一下CMD、AMD都是啥，自己写的代码也应该规范一点。