今天把入口文件引用错误了，导致加载的时候找不到文件，页面报错，查了一下网上的资料，对模块化加载做了个简单的了解..
-
一个底层框架文件；
-
一个网站业务框架文件，包含整个业务模块类；
-
多个业务文件，包含每个具体页面有关系的业务代码；
为了减少一个HTTP请求，大家可能将底层框架和业务框架文件合成一个文件，作为一个公用文件引入到每个需要使用javascript的页面中，再具体的页面中引入和当前页相关业务js文件。为了减少页面加载脚本阻塞现象，还可以将脚本文件放在html的body底部进行加载。
每个页面最多引用两个js文件，打开首页后，后续页面都可以使用缓存中的合并过的js。如果底层框架改动不太频繁，那么缓存在用户浏览器中的合并过的框架文件能够使用较长的时间，反之改动频繁，代码缓存就失去了意义。
但是模块化加载，当网站使用过一段时间后，可能就会发现一些问题出来了。
-
合并的框架文件过大。虽然可以使用YUI Compressor等第三方压缩工具压缩、启用gzip、使用CDN等优化手段优化。但底层框架会随着开源框架升级，公用模块增多，导致合并后的框架文件越来越大。
-
业务框架改动频繁，导致浏览器缓存作用减小。由于业务的增加，可能公用的业务模块越来越多，导致业务框架频繁修改。代码修改后，浏览器需要重新加载新的框架文件。
-
团队开发问题。随着团队人数的增加，可能每个人开发一个公用业务模块，造成多人需要对同一个文件进行修改。若使用TFS这种独占式签出的版本管理工具，会对团队的开发效率造成一定影响。
再看看使用模块加载器、并对javascript进行过模块化处理的网站的javascript架构：
-
一个模块加载器文件
-
多个底层模块，多个业务模块
-
多个页面相关的脚本调用文件
模块加载肯定是有优点的：
-
按需加载：只加载当前页面需要的模块和文件，不需加载任何多余文件和代码。大大缩减了代码量
-
并行加载：很多loader提供了并行加载多个文件的功能，减少了代码加载的时间，优点能做到下载和执行相分离。
-
利于团队开发：团队中每个人负责开发各自的模块，之间互不影响。
-
最大限度的利用缓存：模块颗粒化后，每次更新可能只是其中一个小模块，其他未更新的可以利用浏览器中的缓存。
既然javascript模块化、使用模块加载器有这么多的好处，那么我们需要付出哪些努力：
-
选用或实现loader
-
底层框架的模块化：我们需要将底层框架按照各自的只能分成不同的模块，分清楚之间的依赖关系。
-
实现业务模块：将原来的业务模块按照loader约定的代码方式进行修改，实现新的业务模块按照loader的方式编写。