应用目录结构

一个Meteor应用由目录下的前端文件（HTML、CSS、脚本、资源文件等）和后端文件组成。 由于Meteor存在一个打包/bundle的阶段，因此，Meteor对应用的目录结构进行了约定， 以便其打包过程能够顺利完成。

默认情况下，Meteor会搜索应用目录（包括子目录）中的所有JavaScript文件，打包后分别 送往前端和后端运行，文件和子目录的名称会影响打包结果。Meteor对以下的子目录将特别处理：

≡ client —— 参与打包的前端代码文件夹

任何名称为client的目录，其文件都不会被送往后端运行。这类似于使用if(Meter.isClient){...} 进行前端代码隔离的效果。

在生产模式下，client目录里的文件将被自动合并、压缩，但在开发模式下，JavaScript 文件和CSS文件并不进行压缩处理（CSS还是会合并，但JavaScript文件不进行合并处理），以便于 开发过程中的调试和错误定位。

Meteor会搜索目录中所有的模板文件中的三个顶层元素：head, body, template，其中所有 的head段会合并，body段和template段的声明都将转换为模板操作的JavaScript代码。

≡ server —— 参与打包的后端代码文件夹

任何名称为server的目录，其文件都不会送往前端运行。这类似于使用if(Meteor.isServer){...} 进行后端代码隔离的效果，但不同的是，server目录内的部分代码不会发送到前端，因此一些敏感的 代码（比如身份验证等）应当放在这个目录。

Meteor会收集除了client, public和private子目录之外的所有JS文件，然后交给后端NodeJS 运行。后端的JavaScript代码对每个请求将使用一个单独的线程来处理，这不同于通常NodeJS的异步 代码模式，因为Meter认为这种模式更适合Meteor应用场景。

≡ public —— 不参与打包的前端资源文件夹

应用根目录下public子目录中的文件仅用于前端，这些文件不会被打包，可视为http访问的虚拟根目录。 例如，public目录下的logo.jpg文件，可以通过url："/log.jpg"来访问。这个目录可以用来放置favicon.ico, robots.txt，或者一些静态的HTM文件。

≡ client/compatibility —— 不参与打包的前端兼容库目录

有些前端JavaScript库依赖于使用var定义的全局变量。为了兼容这些库，这个目录里的文件在被送 往前端时，不会被嵌套在一个作用域中，并且会在其他前端JavaScript文件之前先执行。

≡ tests —— 仅用于测试的文件夹

任何名为test的目录内的文件仅用于测试，前端和后端都不会使用。