活着的意义是幸福，幸福是对美的体验。如何才能体验到更多美呢？

美如空气，无处不在。美又如露珠，在清冷的早晨闪着水晶般的光芒，短暂停留后无声地消逝。二千五百年前，佛陀修行六年，开悟成佛，悟得了人生的真谛与幸福的活法。下面就我个人的经历以及现阶段的需求，总结下写给我自己的追求幸福的三个活法：

1. 谦卑
2. 宁静
3. 关爱

谦卑是种心态。“谦”是知晓内心之微小与不足，“卑”是看到外界之大与神奇。刘备三顾茅庐，杨时程门立雪，抱着的都是一颗谦卑的心。谦卑让人保持求知，谦卑让人与人之间和谐相处。谦卑中带有尊敬与敬畏，谦卑是一种空杯者的心态。

回顾自己的过往，无论在网络论坛，还是现实中与他人相处，有不少时候，都比较“要强”，爱逞口舌之快。每当这种境况发生时，经过会导致对方和自己都不愉快，特别是当对方也是一个自我感觉良好、非常要强的人时。如果能持有一颗谦卑的心，那么很多愤怒和懊丧就都可以避免掉，并且能更好地把争议点讨论清楚，把合作的事情做得更好。

谦卑不是软弱，谦卑是放下自我。谦卑是思考，需要不断自我完善。学诚法师有一则见行堂语说：“看不起别人，看不惯别人，看不上别人，看别人不顺眼，这都是错误的，都是因为自己内心有毛病，是给自己和他人带来痛苦的原因，所以需要修行，需要改正。”谦卑是看到别人的好处。以谦卑的心态做人做事，这就是修行，能让自己看见更多美好，体味更多幸福。

宁静是种境界。“宁”是心神安定，不焦不躁。“静”是云淡风轻，万物空灵。“静”字非常有意思，拆开来，是“争”和“青”，即争得/赢取青春。很多成功学书籍里的大道理，都不及这一个静字。

当下社会很浮躁，特别是互联网界。比如微博，吸引了很多用户，为人与人之间建立了大量“链接”。但这些大都是人与外界的链接，缺少人与自己内心的链接。当向外的链接过多，向内的链接过少时，人就容易浮躁。克制浮躁的妙方就是寻求内心的宁静。

宁静是很切实的体验。学者的挑灯夜读，厨师的切菜剁丝，乔丹的灌篮，维修工人认真地拧一颗螺钉，所有工作，当从事的人以一种宁静的心态在做时，整个空气中都会充满着不可言的美。宁静是融合，是将人化于所做的事中，是天人合一的境界，洋溢着幸福。

宁静还是一把利刃，能化解世间的难题。我们经常会遇到一些问题，看似棘手，难以解决。这时很容易浅尝辄止，很轻易就逃避：这太难了，以后再解决。或者说：这问题非我所长，我解决不了。于是就去逛逛微博打发时间，或挑些简单的事情来做。然而实际上，我发现了一个耐人寻味的现象：对于大部分难题，如果能保持内心的宁静，沉下心去思考如何解决，就会感觉冥冥之中自有天助。当一步一步往前走时，往往会柳暗花明，甚至发现原本很简单。做完时，内心则充满着喜悦。这份喜悦，是微博等媒体永远不能给予的。

宁静本身就是一种美的体验，宁静不是为了致远，宁静就是宁静，宁静是幸福的心境。

关爱是发自内心的行动。“关”是关心，记惦某人某事。“爱”是爱护，爱是心之朋友。谦卑是将自己掏空，宁静是吸纳外界之美，关爱则是给予和付出。

不少互联网公司，比如亚马逊，比如阿里巴巴，企业的价值观中都有客户第一。客户第一，就是想客户之所想，急客户之所急，努力让自己的工作，能让客户更满意。如果员工缺少对客户发自内心的关爱，这往往就会成为一句空口号，很难落地。

关爱是情感。是否记得曾经为之心动的女孩，你会在乎下雨天她是否带了伞，你会在乎即将到来的夏天她是否有新衣裳穿，你会在她哭时觉得烦躁，在她笑时觉得开心。懂得关爱，能让你追求到心爱的女孩，能让家庭和睦，能让团队充满凝聚力，甚至能让企业基业长青。

谦卑做人，宁静做事，关爱他人，这就是我写给自己的活法。这是一场修行，现阶段我还有很多不足，但愿意为之修行一辈子。

写在最后：从标题到文章内容，很强调这是写给我自己的活法。除了谦卑、宁静和关爱，还有很多很多美好的活法，比如勤奋、诚实、耐心、激情等等，还可以直接遵循佛教里的八正道和修行戒律来做。我推荐每个人都应该去找到适合自己当下的活法。所有这些，都是为了体验更多美，让自己、让整个世界更幸福。

马斯洛总结的五个需求层次，是理性的分析与归纳。应用到个体时，需加上感性的浪漫与发散。对我来说，马斯洛的五层需求简化为三层：

1. 生存
2. 自我完善、财富自由
3. 体验并创造美

幸福是对美的体验，这是第三层次的需求。要获取幸福，就是要让第三层次的需求得到尽可能多的满足。这离不开第一层次的生存需求，以及第二层次的自我完善和财富自由。

这三个层次不是通关制，不是达到了第一个层次，才能进入第二个或第三个层次，而是三个层次同时存在，并且含义会随着时间发生变化。

对我来说，读大学时，生存需求是不为学费和生活费发愁，这个需求通过家庭支助和课余打工得到了满足。第二层需求里的自我完善，是完善自己的知识体系，是锻炼个人品德和社会生存能力。财富自由在大学时期很简单，对我来说就是能賺点闲钱，买自己喜欢的书。第三层次在大学时期有很多，比如与红友们品味红楼，与诗友们点评诗歌，以及同学之间对科学的畅想和讨论。大学时期，现在回想起来，是简单而幸福的。简单是因为欲求不多，需求简单。幸福是因为体验甚至创造了部分美好。

当然，大学时的我，也有不少不幸福。比如第二层次的财富自由，其实除了买书，我还很想能有闲钱出去旅游。但靠家教賺钱很有限，有时为了买书，我还得饿饿肚子一天只吃三个馒头。还有第三层次的需求里，我很想拥有一份爱情，但在大二时追求过一个女孩，尚未开始就已结束，倍受打击。直到大四开始的另一段恋情才让我在爱情方面拥有了美的体验。

生存需求是基本需求，对于大部分人来说，如果生存需求都得不到满足，是不可能长期拥有幸福的。第二层次的自我完善和财富自由，很大程度上是为了让自己能有资本去体验未曾体验过的美，从而在第三层次上得到更多满足。

生存、自我完善和获取财富自由，本身也可以充满美的体验。一个常见的例子是，追随我心，让兴趣与工作保持一致。但对于大部分人来说，兴趣和工作很难完全重合。重合度超过一半就已经不错，这是现实的生活。

幸福和需求密切相关，需求来自内心的欲求。想拥有幸福，就需要好好地去管理欲求。心如止水，无欲无求，那是佛陀的幸福境界，我们常人不可及。我们可做的是让需求真真切切地贴近自己的内心，要大胆地剔除掉一切虚妄的欲求，比如活得比他人好的攀比欲求，比如拯救人类的狂妄欲求，以及抢劫、淫邪等有悖普世道德的欲求等等。

除了来自个人内心的欲求，需求还不得不受外在环境的影响。比如中国社会中的有很多三明治，面对现实，不得不考虑：

• 房子。是的，我在谈论房子。虽然你可以租房，但中国当下这个大环境下，父母的唠叨、孩子的户口和教育、生活的心态等等，所有这一切都会迫使你或迟或早在这或在那去拥有一套房子。没办法，这里是中国，我们是三明治，活着的部分意义就是去适应当下。
• 车子。最近网上流行一个段子：
  

  梁朝伟有时闲着闷了，会临时中午去机场，随便赶上哪班就搭上哪班机，比如飞到伦敦，独自蹲在广场上喂一下午鸽子，不发一语，当晚再飞回香港，当没事发生过，突然觉得这 TM 才叫生活。

  这个段子可能是事实，也可能是夸张。但从其疯狂转发和衍生出的各种版本来看，大家内心都希望自己也能拥有这份“随时去喂外国鸽子的自由”。车子能让我们拥有一定程度上的“交通自由”。城市的车子会越来越多，这是对自由的追求。

• 孩子。这个肯定会有争议，现实生活中的确有不少人选择了不要孩子。但对大多数人来说，活在中国，孩子是给自己以及父母辈最好的礼物。不孝有三，无后为大，看似我们早就不受这种传统观念的束缚了，但实际情况远非如此，很多传统观念依旧无处不在地影响着我们。

房子、车子、孩子，这些可能并非你的初始需求，但在社会环境下，拥有这些往往能让你活得更舒适、更恬然。特别是孩子，会让父母在自我完善和美的体验中收获很多。大隐隐于市，“隐”可以理解为生活的智者，“隐于市”可理解为与大众的生活保持一样。淘宝的一位高管曾说，可以保有自己的特色，但没必要去搞特别。总之，面对外在环境，保持顺流而活的心态，可以让幸福来得更容易。

每个人的生存需求、自我完善、财富自由以及对美的定义都不尽相同。需求定义和欲求管理是“知”的层面，在“行”的层面，我们如何才能做到呢？这和“活法”密切相关。有很多“活法”值得思考和实践，比如诚实、谦虚、正直等等。这些“活法”，会影响做人做事，并最终决定我们能否活得幸福。

下一篇博客将从我自身出发，总结下我的“活法”。

我们从哪里来？柏拉图认为现实世界是理想概念的投影，我们是洞穴人，就如黑客帝国一样，我们身处的物质世界，只是大脑中的思维活动。基督教认为上帝创造了世界，创造了你我。身为人类，我们有原罪，我们一生都需要救赎。在科学领域，大爆炸理论、第十二颗天体等等，一切看似很“科学”，但究其源头，依旧是未知的，依旧无法让人心安。总之，我们“莫名其妙”地来到了人间。这并非是一个非要找到答案的问题，或许，问题本身就是答案。

要到哪里去？这个问题没人能回答。柏拉图想引导我们走出洞穴，但洞穴之外未尝不是一个更大的洞穴。科学则更不能回答这个问题，甚至因为原子武器、外星文明等等因素，科学给出的答案会是整个人类的毁灭。佛教里有轮回的概念，但对于未能皈依三宝的大众来说，轮回只是一个美妙的善意的谎言。相信轮回，那是信仰的幸福；不相信，也不会带来什么悲哀。要到哪里去，更多的取决于社会中的每个个体今生如何活。

以上两个问题，无论是基督教、伊斯兰教还是佛教，都是通过上帝的存在或生命的轮回等假设来解答，我们选择相信即可。信仰通过简单给人快乐。

我是谁？今生应该如何活着？与前面两个问题不同，这个问题是我们每个人都可以尝试去寻找到答案的。

活着是为了追求真理吗？像我这种人，和愚公类似，属于《第三种“没信仰”》。愚公其实还相信“真”的，相信世间万“相”的背后，依旧有真的存在，至于真是什么，未必需要去探求，但愚公相信“真”的存在。我却连“真”的存在都质疑。真理是什么？拿科学来说，无论是原子、分子，还是万有引力、电磁场，抑或光速不可超越、测不准原理等等，所有这些，都是我们人类在自己的大脑中，对这个世界的理解分析和概念总结，这些其实都是主观的。看似理性、客观的科学，其根基是人类的感性和主观。就如欧氏几何，其依赖的假设之一是：过直线外一点，有且只有一条直线与该直线平行。这个假设是不可证的，是我们对现实世界的主观性总结。如果修改这一假设为：过直线外一点，有且只有两条直线与该直线平行。我们将得到一个全新的几何体系，和欧氏几何一样，也非常严谨完备，只是这一套体系对我们现实世界没什么用。但这未必就能说明欧氏几何更“真”。实际上，就如牛顿力学和广义相对论的关系一样，比欧氏几何更能描述宇宙物理世界的是黎曼几何。科学是为了“方便”。无论是牛顿力学还是黎曼几何，都是我们大脑中的概念。并非存在“曲线”，“曲线”不是东西，“力”也是纯概念，是我们用来理解这个世界的思维符号。E=mc^2 很漂亮，但其本质和“爱给人力量”一样，都是我们对世界的理解，并不是“真理”。

各种宗教，最打动我的，是它们都在宣扬一种活法。比如佛教里，有四圣谛和八正道，比丘有很多戒律。所有这些，包括轮回的观念，都是为了让人在今世活得更好，活得心如大海，能坦然面对世间的一切哭笑沉浮、生老病死。宗教带给人的是善与美。我们该做什么，怎么做，如何幸福，我们拥有什么，应该追求什么，可以放弃什么，所有这些问题，在各个宗教里都有解答。即便不信教，比如愚公，比如我，也可以从中汲取到很多有意义的“活法”。比如佛教里的五戒，不杀生是教我们要慈悲，不偷盗是教我们要自立，不妄语是教我们要与人和谐相处，不邪淫和不纵酒是让我们能分辨快感和幸福。活着就是当下，今天是明天的“从哪里来”，明天是今天的“到哪里去”。活好今天，于我，上面三个问题就都有了答案。

这样，活着的意义变得非常清晰简单：

活着的意义就是幸福 —— 自己、他人以及整个社会的幸福。

什么是幸福？每个人都有自己的定义。我的定义是：

幸福是对美的体验。你爱的人也爱你，这是多么美妙的事情呀。挑灯夜读书、攀岩、扶老奶奶过马路、产品上线等等，这里面都有美在流动。美可以在“真”的追求中，美可以在“善”的行动中，美无所不在，像水像空气一样，轻轻一捏，美中就可以掉出一滴幸福来。

可是世间很多人活得很苦，活得不幸福。不是因为没有幸福，而是因为幸福如空气，风起来时，我们能感受到凉爽，云淡风清时，我们却经常忽略了自己的呼吸。

美的体验究竟是什么？如何才能活得幸福？请看后续博文。

JS 和 CSS 在页面中的位置，会影响其他资源（指 img 等非 js 和 css 资源）的加载顺序，究其原因，有三个值得注意的点：

1. JS 有可能会修改 DOM. 典型的，可能会有 document.write. 这意味着，在当前 JS 加载和执行完成前，后续所有资源的下载有可能是没必要的。这是 JS 阻塞后续资源下载的根本原因。
2. JS 的执行有可能依赖最新样式。比如，可能会有 var width = $('#id').width(). 这意味着，JS 代码在执行前，浏览器必须保证在此 JS 之前的所有 css（无论外链还是内嵌）都已下载和解析完成。这是 CSS 阻塞后续 JS 执行的根本原因。
3. 现代浏览器很聪明，会进行 prefetch 优化。性能是如此重要，现代浏览器在竞争中，在 UI update 线程之外，还会开启另一个线程，对后续 JS 和 CSS 提前下载（注意，仅提前下载，并不执行）。有了 prefetch 优化，这意味着，在不存在任何阻塞的情况下，理论上 JS 和 CSS 的下载时机都非常优先，和位置无关。

以上三点可简述为三条基本定律：

• 定律一：资源是否下载依赖 JS 执行结果。
• 定律二：JS 执行依赖 CSS 最新渲染。
• 定律三：现代浏览器存在 prefetch 优化。

有了这三条定律，再来看克军的测试，就很清晰了：

a,b – head里出现外联js，无论如何放，css文件都不能和body里的请求并行

根据定律一和定律三，可以知道上面的结论不够正确。比如：

<head>
<link rel="stylesheet" href="mock.php?css1&sleep=2">
<script src="mock.php?js&sleep=3"></script>
<link rel="stylesheet" href="mock.php?css2&sleep=4">
</head>
<body>
<link rel="stylesheet" href="mock.php?css3&sleep=5">
<img src="test.gif">
</body>

在 Chrome 下的瀑布图是：

黄色条是 js 的，可以看出 img 的延时下载是由定律一决定的。

定律三则决定了所有 js/css 都是并行开始下载的。在 Firefox 10 下，prefetch 非常强悍，对 img 也会预加载，瀑布图如下：

调整一下 sleep 时间，还可以观察到定律二的威力：

<head>
<link rel="stylesheet" href="mock.php?css1&sleep=3"> <!-- 修改 sleep 值，使其大于 js 的 -->
<script src="mock.php?js&sleep=2"></script>
<link rel="stylesheet" href="mock.php?css2&sleep=4">
</head>
<body>
<link rel="stylesheet" href="mock.php?css3&sleep=5">
<img src="test.gif">
</body>

瀑布图立刻发生了变化：

因为定律一，决定 img 的下载在 js 执行后。又因为定律二，决定 js 的执行在第一个 css 后。于是最后在瀑布图上体现出来，就是 img 的下载在第一个 css 后。

再来看克军的第二个结论：

c – head里的内联js只要在所有外联css前面，css文件可以和body里的请求并行（图2）
d – head里的内联js只要在任一外联css后面，css文件就不能和body里的请求并行（图1）

这个是定律二的威力。结论 c 是正确的，因为没有 css 会影响 js 的执行。结论 d 则不够正确。img 等其他资源，会在 js 前面的 css 下载完成后，以及 js 执行后，立刻开始下载。与头部中，js 位置之后的 css 没关系。

克军的其他结论都是对的，不多说。

注意1：Firefox 10 的 prefetch 有点奇怪，有时会对 img 进行 prefetch，有时则不会。有兴趣的可以进一步寻找规律。
注意2：上面的三个定律，是黑盒猜测，有兴趣的可以去阅读浏览器的源码，应该能找到更深层次的原因。
注意3：本文没有考虑 defer, async 属性的影响，这是另一个故事。

浏览器在迅速发展，很多总结，特别是书籍上的，很难与时俱进。大家应该像克军学习，多测试，多发现，这样得来的知识，才不会过时。这篇博客的总结，也肯定在未来甚至就在现在，已经存在错误。这些都无所谓，关键是要懂得测试的方法和分析的思路，有了“渔”，才能更好地探求和拥有“鱼”。

这是一本三百来页的小书，昨天中午看了个开头，一直惦记着。今天一大早起来，花了一上午，如野人品美味一般狼吞虎咽看完，实在是一本好书。

九大觉悟

这本书以预言的形式，揭示了人类在第三个千年，也就是从我们当下所在的二十一世纪开始，人类精神演化过程中，可能会遇到的九大觉悟。

第一个觉悟指出，我们生活中的很多事情，很多机缘，都不是偶然的巧合，而是有一股神秘的力量在指引。对这些机缘，我们需要去在意，去觉察。当越来越多的人开始察觉时，当数量达到决定性的多数时，就会影响整个人文社会，带来人类整体的变革与进化。

第二个觉悟，能帮助我们想明白“我们从哪里来”。漫长的历史，不单是科技的演进，也是思想的演进。在第二个千年刚开始时，人类存活的目的，是救赎，一切对与错，由神职人员来界定。这是中古世纪的世界观，一直到 14 和 15 世纪才开始瓦解。人们开始质疑神职人员自身的不正当行为，在马丁·路德等人的领导下，开始亲自接触《圣经》，以自己的方式来解读经文。第二个千年的最后四百年，地心说的破灭，牛顿力学的建立，各种科技的飞速发展，极大地提高了人类的经济生活水平。这是执迷的四百年，执迷于以科技的方式，来改善经济生活。然而，无论科技多发达，都无法帮我们发现上帝的新面貌和人类存活的目的。以这种千年的眼光来看待漫长的历史，就能通古今，并预测未来的可能性。

第三个觉悟非常有意思。美好的东西，会让人心情愉悦。我们在鉴赏美时，美究竟是什么？第三个觉悟指出我们看待物质世界可以有一个新视角：“能”的世界。“能”是某种共同的、构成所有物质基础的东西。万事万物都会散发出自己的“能场”。当某种东西，能让我们的能场增大时，我们就会感觉精力充沛、心情愉悦。

当两个人交谈时，在交谈后，经常会有一方感觉强壮有力，而另一方则虚弱。每个人都会有支配和控制欲，第四个觉悟指出，这种“权力争夺”实际上是“能”之争。大到国际纷争，小到两人相处，都存在着这种能场的流动。自愿付出“能”，可以让对方的能场增强而心情愉悦，但这通常不能长久。大多数人的身心并不够强健，一般男女关系最后都会变成权力斗争，婚姻是爱情的坟墓是现实的悲剧。如何破解这一冲突呢？这是下一个觉悟。

第五个觉悟和我的座右铭有关联：“以开放的心态，打造专业的人生”。上个觉悟指出人类之间存在能的争夺。要避免这种争夺，我们得去寻找能的另一种来源。这个来源无处不在，就是我们身处的大自然。大自然充满生机，这些生机蕴含着大量能，我们需要学会欣赏大自然，学会鉴赏美，学会去爱。爱不是一种抽象的道德责任，爱是一种实实在在的感觉。当我们敞开胸怀，去爱大自然时，大自然就会赠予我们能。维持爱的境界，是我们身为人的最大享受。爱使万物聚合，恨则分散。

要爱大自然，要与宇宙建立能的长期“连结”前，我们还得清理过去的一生。对于大部分人来说，人生就是一场戏，我们每一个人都在扮演着一些角色。第六个觉悟指出，人间上演的控制戏大致可以分成四类：胁迫、审问、冷漠、乞怜。作为个人，我们的性情，我们的处世方式，我们与人相处时扮演的控制戏，都与我们的父母有关，与我们的童年经历有关。回顾自己过去的一生，理清父母辈的人生观，思考在自己生命过程中的所有“机缘”，能帮助我们知晓自己的真正身份，能帮助我们看清楚人生的真相和生命的意义。知道了“我是谁”后，我们就能与宇宙的能建立长久的连结，达到一个更高层次的自我。

人生最大的问题不在于求取答案，而在于认清面临的问题。一旦意识到目前面临的问题，我们的直觉甚至梦境，就会指引我们，该怎么做，下一步怎么走。这就是第七个觉悟，提醒我们要重视直觉，要理清预感。机缘无处不在，包括白日梦。我们要客观、积极地去看待这些意念，并且对遭遇的任何事件，无论表面上看起来多么糟糕，都有好的一面，我们需要自己去把它找出来。

第七个觉悟让我们知晓如何与自己相处，第八个觉悟更诱人，谈及爱情，谈及如何与人相处，以及如何在团队中进行有意识的互动。一个男孩迷恋上一个女孩，经常是因为对方有自己欣赏和称赞的“气韵”，这些“气韵”是自己尚不具备的。或者说，很多爱情，是因为互补而彼此吸引。但互补下的迷恋，会像第四个觉悟指出的那样，容易变成权力斗争，彼此会陷入控制戏中，导致最后互相防守、互相厌倦，迈入爱情的坟墓。长久的爱情，永久的结合，不应该是互相依赖，不应该是迷恋，而需要不断自我完善，让彼此都是完整的圆，完整的个体。两个完整个体相爱，是彼此提携、互相促进，形式的是两个完整圆外的美丽大圆。这种爱，彼此都在给予能，同时能感受到对方的爱，让彼此的能场都更加强健。这就像两个虚拟的苹果，都是完整的，彼此爱慕，交换后，拥有的才是两个苹果。多人组成的团队，也应该是这种互惠互利的形态，这样才能越来越强健。

第九个觉悟是理想国，和第一个觉悟遥相呼应。如果越来越多的人达到第八层觉悟，成为决定性的大多数，最终将给整个社会带来巨大变革。甚至像玛雅文明一样，能通入天堂了。

对现实的启迪

这九大觉悟，可以分成三类：第一个和第二个觉悟解答了“我们从哪里来”的问题。第三个到地六个觉悟则能让我们看清楚“我是谁”。最后三个觉悟，尝试告诉人类“我们要到哪里去”。

对现实的启迪很多，比如如何走出自己的控制戏、如何与人相处、如何让爱情完满、如何带领团队等等。还能用来指导如何与小孩相处，能让自己对“爱”有更深层次的领悟。

看完这本书，宁静安详。

2011.12.02, Version 1.1.0 (stable)

• 完善 API 文档：Sea.js 手册与文档
• 优化模块 id 的设计，提高打包后的可靠性：#112, #127
• 增加开发状态判断：seajs.debug #117
• 开放插件方法：seajs.pluginSDK
• 让 seajs 的模块可直接运行在 node 环境：#105
• 其他优化，详见：issues

SPM

2011.12.02, Version 0.4.0 (stable)

大量优化和 bug fix，详见：issues
使用方法：README.md

安装使用

强烈推荐升级到 node 0.6.4, 安装非常简单：

Windows 安装包：node-v0.6.4.msi
Mac 安装包：node-v0.6.4.pkg

安装好后，使用以下命名安装 spm：

$ npm install spm -g

反馈

请发送邮件到：seajs+subscribe(at)googlegroups.com

So, 请移步这里讨论：https://github.com/seajs/seajs/issues/130

使用场景

为了便于讨论，先做一些约定：

模块原始代码为 S(ource)
压缩打包后的模块代码为 C(ompressed)
独立文件为 F(ile)
内嵌到页面中为 P(page)
独立文件中是原始代码时，记为 SF；独立文件中是压缩打包后的代码时，记为 CF
内嵌的原始代码记为 SP；内嵌的压缩打包后的代码记为 CP

压缩打包是指代码压缩、模块信息补全、编译、合并等操作。

使用场景可概况为一句话：

SF, CF, SP 和 CP 可直接在浏览器中运行，并可同时存在。

几点说明：

1. 可直接在浏览器中运行，这点很重要。对前端开发来说，浏览器即编译器。增加一层服务端来做编译、转换等工作，是很大的诱惑，但这会增加使用者的复杂度。好想法要变成好产品，在给用户带去新功能、去除用户坏习惯的同时，还得尽可能避免剥夺用户现有的便利。
2. 允许内嵌，这是脚本代码的现有特性：模块代码与存储位置无关。可存储为文件，也可内嵌到页面。保持该特性，除了能延续旧有的便利，还可使得通过内嵌来减少 HTTP 链接数的性能优化方案继续可用。
3. 源码和压缩打包后的代码可并存。这一点的背后，是模块代码与存储形式无关。做到这一点，可以让代码调试和新功能的开发等工作更简单。

第一点决定模块加载器的战场在浏览器端，要尽量避免增加对服务端的依赖。第二点决定不能采用 XHR + eval 等方式来实现，而需要采用包裹形式来定义模块。第三点决定模块转换格式要尽可能和模块定义格式兼容，最好的一种兼容方式是：模块转换格式就是模块定义格式。这种一致性还可以给优化打包等工具带来方便和简洁性。

模块定义格式

模块的定义格式为：

define(id?, dependencies?, factory)

 

id 是模块标识，经过解析后是唯一的。可以是：绝对路径（http://x.com/path/to/a）、系统路径（xxx/z）、相对路径（../a/c）和根路径（/root/path/to/a）。这种分法是从 id 字串的形式来分的，代表的真正路径，还需要根据所在的上下文环境来确定。比如：对于相对路径，有一种策略是，如果 define 代码在文件中，则相对的是所在文件的绝对路径；如果在页面中，则相对的是页面地址。SeaJS 1.0 目前就是这个策略，这个策略违背了“模块代码与存储位置无关”的假设，在 SeaJS 1.1 中将调整回来。

为了做到“模块代码与存储位置无关”，模块可分为两种：

1. 匿名模块：定义格式为 define(dependencies?, factory)
2. 具名模块：定义格式为 define(id, dependencies?, factory)

匿名模块无论放在文件里，还是内嵌在页面中，其功能都只是定义了一个匿名模块。定义在文件中的匿名模块，可以通过文件路径来引用（这是文件的特性，不是匿名模块的特性）。内嵌在页面中的匿名模块，则因为其匿名而无法调用（就如我们在 JavaScript 中定义了一个匿名函数一样，在匿名函数外面，无法调用该匿名函数）。

具名模块是定义格式里有 id 的模块。从“模块代码与存储位置无关”出发，id 可分为：

1. 页面路径：包括绝对路径、根路径、相对路径。这些路径，除了可以省略 .js 后缀，其解析规则与页面中 <script src=”…”> 中 src 的解析规则一致。
2. 系统路径：这是相对 base 的路径，解析规则是在前面加上 base. 比如 base 如果是 http://a.tbcdn.cn/libs, 则 “jquery” 会被解析成 “http://a.tbcdn.cn/libs/jquery.js”

模块定义格式中的 id 就这两种，无论代码在何处，含义都不会变化。

与上下文环境相关的 id，只有 require 和 require.async 的 id 参数。require 的 id 参数是相对路径时，相对的是当前所在模块。比如：

// http://a.tbcdn.cn/app/x.js
define(function(require) {
  var a = require('./biz/a'); // 等价 require('http://a.tbcdn.cn/app/biz/a.js');
});

 
自然，dependencies 中的相对 id, 也是相对当前所在模块的。

理想与现实

模块书写格式和 id 解析规则确定后，对模块加载器来说，设计方案就大局已定了。由于浏览器本身有很多限制，是带着镣铐的舞蹈，在完全确定 API 前，还必须得考虑技术上是否可以实现。

期望中的最佳实践是：

1. 开发时，文件和模块是一对一的，且模块最好是匿名模块，这样能遵守 DRY 原则，可以让名称冲突的概率理论上降为 0.
2. 压缩打包后，模块加载器能够按照预期 100% 正确的工作。在打包前，出错的概率也要尽可能小，以便在各种浏览器下调试。
3. 压缩打包规则尽可能简单，这样可以方便各种衍生工具的开发。

要容纳的现实情况有：

1. 多个匿名模块存在于同一个文件中。对于这种情况，只能有所取舍，目前是最后一个匿名模块生效。
2. 具名模块可以多个并存在文件或页面中。这种情况要完全容纳，能正常运行。
3. 匿名模块存在于页面中。这种情况，除了该匿名模块无法引用，不能破坏其他模块的加载和运行。

以上几点，对开发者的习惯有着合理的容忍，同时也能让压缩打包很简单：只需将匿名模块转化为具名模块，然后合并在一个文件就行。

技术难点

异步回调的可靠性

对于异步操作来说，异步回调的可靠性至关重要。假设加载 t.js 时，代码执行时间是 T, onload 回调时间是 t. 理想情况下，T 应该永远先于 t. 很不幸的是，在 army 的测试 中，发现 IE 下有万分之一的概率 T 会大于 t. 如果 IE 下（包括 IE9）真有这个问题，对于线上应用来说，这概率是不可接受的。如果真有这个问题，一个可能的解决方案是，在 onload 发生时，使用 setTimeout 将 callback 再排列到队列尾，然后再测试出错概率，或者用 army 说的二次幂延等算法来降低错误概率，如果概率依旧比较高，则需要通过打包部署工具来做一些去 onload 依赖的处理。进一步的测试验证还在进行中，明后天可见分晓，敬请期待。

注意：目前市面上所有加载器都依赖 T < t 这一特性。希望明天的测试结果，能证明 T < t 的绝对可靠性。

匿名模块的URL获取方案

在这篇博客 模块加载器获取 URL 的原理 里已详述，再次就不赘述了。希望明天的测试结果能证明 Army 方案的可靠性，这样，就可以去掉 getInteractiveScript 等针对 IE 的 hack 代码。

除掉以上两个技术关键点，其他的特性，比如异步并行加载、上下文环境管理、alias 与 map 等等功能，实现上不依赖 DOM，非常可靠。

小结

好的业务产品，需要有好的愿景、理念，需要有切实可行的技术方案，要有梦想，也有要面对现实的取舍。技术产品也一样，想清楚并定位好使用场景至关重要。需求分析 – 可行性分析 – 代码实现与优化 – 推广应用，是一个螺旋式的周期，转过好几轮后，才能站得更高，做得更好。

2011-11-17:

后续测试与结果，请跟进：模块加载器的可靠性测试与思考

JavaScript 构建的应用越来越复杂，为了提高代码的可维护性，第一步是拆分为多个文件：

a.js
b.js
c.js
...

 
文件拆开是第一步，为了彼此能互相调用，但又不污染全局造成潜在冲突，于是聪明的程序员们想出了用对象来模拟命名空间：

// a.js:
X = {};
X.a = {...};

// b.js:
X.b = {...};

// c.js:
X.c = {...};
...

 
这种命名空间得自己维护，当层级达到三层及其以上时，维护起来并不轻松，比如 YAHOO.widget.TreeView。于是出现了类似 YUI3 的扁平方式：

// 定义模块
YUI.add('a', factory);

// 加载模块
YUI().use('a', function(Y) {
  // 调用模块
  Y.a.doSomething();
});

 
这种方式解决了不少问题，比如依赖加载、模块沙箱、命名空间。但使用时，用户的记忆负担还是比较重，比如：

YUI().use('dd-drop', function(Y) {
  Y.DD...
});

 
得记住 dd-drop 和 Y.DD 的对应关系。当模块很多时，经常要查文档。

服务器端的模块管理

上面是浏览器端的发展。同一时期，服务端 JavaScript 也悄然兴起。开始有了 CommonJS/Modules 1.0 规范：

// math.js:
export.add = function(){...}

// program.js:
var math = require('./math');
math.add(1, 2);

 
通过 exports 和 require, 就可以向外提供模块和向内引入模块。在服务端，可即时读取文件，因此 require 是同步的，很方便。

CommonJS/Modules 1.0 用非常简单的规则，征服了 NodeJS 等社区。简单意味着记忆负担少，简单意味着清晰，简单意味着受众广，等等。

CommonJS 在服务端取得了很高的认可，当迁移到浏览器端时，由于浏览器的两大限制：

1. Context: 不通过包裹，很难做到上下文环境的限制。
2. Distance: 文件不能像服务端一样即时读取，需要远程链接。

加上浏览器的同源策略等限制，导致 CommonJS/Modules 1.0 规范在浏览器端只是看起来很美。

于是 CommonJS 社区展开了大讨论，基本上形成了两大派系，其中一派是 AMD 规范：

// a.js:
define(['./b'], function(B) {...});

// main.js:
require(['a.js'], function(A) {...});

RequireJS 与 YUI3 有类似的地方，YUI3 是将加载的依赖模块放在 Y 上，AMD 是直接作为参数传入。很显然，AMD 的记忆负担变轻了些。

除了 AMD 规范，CommonJS 的另一大派系，有 Wrappings 和 Modules/2.0 等规范。（注意：CommonJS 的模块规范里，只有 1.x 是正式版，其他都还在讨论中，未成定论。AMD 则脱离了 CommonJS 社区，成为独立的社区发展。）

Wrappings 等规范与 AMD 最大的不同点在于：

1. Wrappings 尽量保持与 Modules 1.x 的兼容。
2. Wrappings 的哲学是尽量保持简单，用最小的代价、最少的 API 来实现浏览器端的模块规范。
3. Wrappings 尽量保持“懒”。能不执行的先不执行，需要时才初始化。

举个例子：

// a.js:
define(function(require, exports, module) {
  var b = require('./b');
  //...
});

 
在 Wrappings 规范里，除了外层包裹，里层代码绝大部分和服务端是一样的。

RequireJS 也支持一种 CommonJS Simple Wrapper 规范，只是长得一样，内蕴上是差异比较大的，比如：

// a.js:
define(function(require, exports, module) {
  alert(2);
});

// b.js:
define(function(require, exports, module) {
  alert(1);
  var a = require('./a');
});

在 AMD 和 Wrappings 等规范里，a 模块都会提前加载好，但对于什么时候执行 a 模块的 factory 代码，两派存在很大的差异。AMD 里，运行上面的代码，会先弹出 2, 然后才是 1. 在 Wrappings 等规范里，a 模块只是提取加载好，factory 的运行，会延迟到第一次 require 时，因此会先弹出 1, 然后才是 2, 和服务端的逻辑是一样的。

有点扯远了，萝卜白菜，各有所爱。我个人更喜欢 NodeJS 遵守的 CommonJS/Modules 1.x 规范，以及简单 Wrappings 模式。

回到本篇博客的正题。无论是 AMD 还是 Wrappings 规范，从 DRY 的原则上讲，都支持匿名 define 模块（这和 YUI3 要显式指明模块名是不同的），都是匿名模块了，那如何引用呢？肯定得有 id 的，这 id 就是 URI. 对于浏览器端来说，就是 URL. 模块的 URL 就是模块的唯一标识，很简单的道理，但能将此固化为标准并加以实现就不容易了。

串行获取方案

这是最简单的方式，一次只下载一个：

// 在执行 define 时：
var mod = {...};

// 在加载 script 时：
getScript(url, function() {
  // 保存模块
  save(url, mod);

  // 加载下一个模块
  next();
});

 
这样，每次只加载一个模块，url 的获取非常轻松，YUI3 早期也是这种模式。

现代浏览器下的获取方案

现代浏览器（排除IE6-8）下，有一个很强的规律：

脚本 a 执行完后，会立刻触发 a 的 onload 事件，中间不会被打断（除非被 alert 等操作强行打断）。

由于采用包裹的方式，alert 这种中断我们就不用考虑了。利用这个规律，很容易实现URL的获取：

// 在执行 define 时：
var mod = {...};

// 在加载 script 时：
getScript(url, function() {
  // 保存模块
  save(url, mod);
});

 
看起来和串行方案的唯一区别是没有 next(), 其实上复杂很多，a.js 和 b.js 的下载都是并发的，要通过递归回调等方式来处理依赖加载。

IE6-8 下的获取方案

如果这个世界上没有 IE，那么，会很糟糕的（必须承认 IE 对 Web 的伟大贡献），但现在 IE 的确成为了前端巨大的负担。在 IE6-8 下，脚本执行和脚本onload事件之间没有紧相邻的规律，比如：

// 记 a.js 的执行为 A, onload 为 a
// 记 b.js 的执行为 B, onload 为 b

// 同时加载 a.js 和 b.js 时，有可能是 ABab, 而不总是 AaBb

这个看起来很小的麻烦，要解决却是大麻烦。CommonJS 社区讨论了好久，后来出现了一种解决方案：

// 在执行 define 时：
var mod = {...};
var url = getInteractiveScript();
save(url, mod);

 
通过 getInteractiveScript, 在 define 执行时，就可获取到当前正在执行的脚本文件路径：

funcition getInteractiveScript() {
  var scripts = head.getElementsByTagName('script');

  for (var i = 0; i < scripts.length; i++) {
    var script = scripts[i];
    if (script.readyState === 'interactive') {
      return script;
    }
  }
  return null;

 
正在执行的脚本，其 readyState 属性是 interactive. 这真是天才的发现，一切看起来很完美。

然而，当加载的文件是浏览器缓存好的文件时，IE的读取是“瞬间的”，这个瞬间绝对会秒杀你的想象，不光不会有 interactive 状态，还会像服务器一样“同步操作”：

// 在执行 define 时：
var mod = {...};

// 在加载 script 时：
var urlCache = url;
getScript(url, function() {
    save(urlCache, mod);
});
urlCache = null;

 
getScript 是异步的，但其 callback 里，却可“同步”获取到 urlCache 的值，诡异又强悍的 IE！

IE下的总方案

对于 IE9，和现代浏览器一样，采用紧相邻规律就行。

对于 IE6-8，先用 getInteractiveScript 的方案获取，获取不到时，再用同步 cache 的获取方式，倘若还是获取不到，则进一步降级到紧相邻规律（虽然不严格遵守，但大部分情况下，IE6-8 还是符合这一规律的）。

注意：IE6-8 下，虽然用了三种方式组合获取，但依旧可能获取失败。并行加载的文件越多，获取失败的概率越大，主要是 IE6 有问题。原因很复杂，尚未分析出具体规律。（好在概率很低，目前只发现 IE6 下，在获取没有设置缓存头的动态 js 文件时，会经常获取不到正确的 URL。）

目前 RequireJS、BravoJS、SeaJS 等等模块加载器采用的都是这个方案，可靠性不是 100%, 但还是非常值得信赖的，特别是考虑上线时还会经过打包优化。

Army 的方案

Army 最近做了一个很有趣的测试：onload次序测试，发现虽然无法保证 AbBbCc, 但执行的顺序和 onload 的顺序彼此是一致的，比如：ACaBcb. 如果大写字母的顺序是 ACB，则小写字母的顺序一定是 acb.

利用这个规律，可以很方便获取到 URL:

// 在执行 define 时：
var mod = {...};
defQueque.push(mod);

// 在加载 script 时：
getScript(url, function() {
  save(url, defQueque.shift());
});

 
如果能严格做到一个文件一个模块，采用这种方式是很完美的。注意：Army 博客中的测试数据显示还是有极少失败的概率，目前确切原因未知。但这个方法本身的确很好，是所有浏览器都遵守的统一规律。

更复杂的现实情况

API 的设计要尽可能简单，但另一方面，对使用时的场景又得尽可能的包容。在 Army 的方案中，如果有两个文件：

// a.js 是打包部署后的：
define(true, 'http://path/to/a.js', ...);
// 在 army 方案中，打包后，会在 define 的参数前面添加两个参数来指明

// b.js 是新开发的，尚未打包的：
define(function(){...});

// 同时使用时：
use(["a.js", "b.js"], callback);

 
这种情况是很现实的，比如在老产品上开发新功能。

这时，a.js 不会给 defQueue 添加新项，b.js 则会给 defQueque 添加一项。但在 getScript 的 callback 中，比如 a.js 的 callback 里，是不知道 a.js 有无给 defQueue 添加项，这样信息是缺失的，会导致 defQueque.shift() 出来的与当前 callback 不对应而出现错乱。

面对现实情况，看似完美的方案，困境重重。（谁若简单的好策略，热烈欢迎交流回复，很希望能找出完满的方案。）

小结

困了，睡觉。今天的困惑，有可能是明天的希望。

define(function(require, exports, module) {
  var foo = require('./foo');
  ...
  exports.bar = foo.doSomething();
});

For more details, please go to http://seajs.com/

I’ll be highly appreciated if you would review the code or give some feedback to me.

Best regards,
Frank Wang