上一篇發出來后得到了很多回復，在此首先感謝大家的熱情捧場！有的推薦第三方框架，比如 In.js、requrieJS、sea.js、lab.js等。這個開闊了眼界，以前只知道sea.js，省去了自己搜索的麻煩。也用了點時間簡單看了一下，因為每一個都是大塊頭，都有自己的理念，如果只是簡單使用的話，那么誰便找一個就可以了，但是我習慣把原理弄清楚。因為我覺得雖然不知道原理也可以使用，但是知道了原理后，可以用的更好。
主要看的是sea.js，目前簡單的理解是：一個加載js的機制 + 模塊化編程(CMD規范)的理念。這個是淘寶用的，肯定很強大、很結實了。那么我是不是拿來用呢？這就要看看我到底想要什么，以及改動量大小。
那么我想要啥呢？第一步只想要一個可以動態加載js的代碼，越簡單越好。為啥呢？越簡單就越不需要修改。為啥要求不需要修改呢？因為我想達到的效果是，每個頁面只需要 <script type="text/javascript" src="/boot.js"></script> 這么一行，就可以把所有的共用的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都是啥，自己寫的代碼也應該規范一點。