1. require会搜索目录加载文件

2. require会判断是否文件已经加载避免重复加载同一文件。由于上述特征，require在Lua中是加载库的更好的函数。

require使用的路径和普通我们看到的路径还有些区别，我们一般见到的路径都是一个目录列表。require的路径是一个模式列表，每一个模式指明一种由虚文件名
      （require的参数）转成实文件名的方法。更明确地说，每一个模式是一个包含可选的问号的文件名。匹配的时候Lua会首先将问号用虚文件名替换，然后看是否有
        这样的文件存在。如果不存在继续用同样的方法用第二个模式匹配。例如，路径如下：

调用require "lili"时会试着打开这些文件：

require关注的问题只有分号（模式之间的分隔符）和问号，其他的信息（目录分隔符，文件扩展名）在路径中定义。

为了确定路径，Lua首先检查全局变量LUA_PATH是否为一个字符串，如果是则认为这个串就是路径；否则require检查环境变量LUA_PATH的值，如果两个都失败
      require使用固定的路径（典型的"?;?.lua"）

require的另一个功能是避免重复加载同一个文件两次。Lua保留一张所有已经加载的文件的列表（使用table保存）。如果一个加载的文件在表中存在require简单的返回；
      表中保留加载的文件的虚名，而不是实文件名。所以如果你使用不同的虚文件名require同一个文件两次，将会加载两次该文件。比如require "foo"和require "foo.lua"，
 路径为"?;?.lua"将会加载foo.lua两次。我们也可以通过全局变量_LOADED访问文件名列表，这样我们就可以判断文件是否被加载过；同样我们也可以使用一点小技巧让
require加载一个文件两次。比如，require "foo"之后_LOADED["foo"]将不为nil，我们可以将其赋值为nil，require "foo.lua"将会再次加载该文件。

一个路径中的模式也可以不包含问号而只是一个固定的路径，比如：

这种情况下，require没有匹配的时候就会使用这个固定的文件（当然这个固定的路径必须放在模式列表的最后才有意义）。在require运行一个chunk以前，它定义了
一个全局变量_REQUIREDNAME用来保存被required的虚文件的文件名。我们可以通过使用这个技巧扩展require的功能。举个极端的例子，我们可以把路径设为
"/usr/local/lua/newrequire.lua"，这样以后每次调用require都会运行newrequire.lua，这种情况下可以通过使用_REQUIREDNAME的值去实际加载required的文件。

转载自http://www.cnblogs.com/orez88/articles/2139160.html
Lua中的模块(module)机制有点类似于C语言的动态库，可以将一些公共的代码放在模块中，以API的形式提供给Lua应用脚本使用。
使用模块或许还可以做成像Android的Application Frameworks，建立一种新的应用程序编程模型，只是猜想。

模块最简单的使用方式：

• table

Lua语言共有8中数据类型，其中table(表)类型实现了“关联数组（associative array）”。table中可以保存各种数据类型。和table关联的metatable，
它定义了表的操作的一些行为，比如: 使用+操作时，会去查找metatable的属性__add，有的话执行。

• function

function是Lua中8中基本类型之一，和其它类型一样可以作为值传递。和function有关联的表是环境表（environment），可以认为是function的执行环境。
可以通过setfenv()和getfenv()来设置和获取函数的环境表。函数中对于全局的操作，比如：定义全局变量等；就是在这个表中进行的。多个函数可以共享一个表

• require

当使用require加载一个模块时，实际上做了如下的事情：

在表package.loaded中查找模块是否存在，有的话就返回该值。可以使用如下函数输出表中的内容

package.loaded中的内容如下，其中包含了一些默认加载的库和全局表_G

为模块查找加载器（loader），查询package.preload，通常为空

加载Lua文件使用loadfile函数。loadfile会将文件当作函数来加载，require会将模块名作为参数传给该函数。若有返回值则将返回值放入表package.loaded中。
若没有则返回表package.loaded中的值。

• module

当在模块文件中使用module函数的时候，如下所示；

实际上等同于以下的语句：

方式一: 直接将所有组成包的数据和方法定义在包中，代码看起来像是这样：

vector3d = {}  -- 包名  
function vector3d.function1()  
......  
end  
function vector3d.function2()  
......  
      if (vector3d.function1()) then  
      ......  
      end  
end  
return vector3d 

这样定义的就是一个vector3d包，使用require语言打开这个包后，就可以使用 vector3d.function1和vector3d.function2这两个函数了。

这是最直接最好理解的一种Package定义方式，但是有一定的弊端。这个弊端主要体现在Package的实现过程中。可以看到，即使在

vector3d.function2()中使用function1()函数，也必须完整的加上vector3d包名，否则无法进行函数调用。Package的作者要稍微累一点，不过使用者倒是还好。特别的注意最后的 return vector3d 语句，有了这句后调用者可以按照如下方式重命名包:

MyPackage =  require "vector3d"  
MyPackage.function2() 

方式二: 使用局部函数定义所有的Package内函数，然后在Package的结尾处将需要公开的函数直接放入Package中。代码看起来像这样:

vector3d = {}  -- 包名  
local function function1()  
......  
end  
 
local function function2()  
......  
      if (function1()) then  
      ......  
      end  
end  
vector3d = {function1 = functoin1,   
function2function2 = function2  
}  
return vector3d 

最后给包中赋值的部分就是将需要的接口公开的部分。这样做的好处：不需要公开的函数可以完全隐藏起来(都是local函数)；Package内部的各个函数相互之间调用的时候不再需要加Package名称进行区分; 可以按照需要随意的重命名Package公开的接口名称。这种方式的弊端在于定义的时候需要写上local，这算不算弊端就看你了 - -。 就我个人而言，我还是比较喜欢这个定义方式。能明确的区分出接口和私有的定义，公开接口的名称还可以随意改变，这就意味着可以随意替换内部实现而不需要影响外部调用者。

无论用什么方法去定义Package，都是为了在逻辑上更好的规划代码层次。LUA中的table机制的确是一个活力无限的机制啊。Package依靠这个实现，LUA本身自己有些机制也依赖于Table(比如全局变量就放在_G表中)

手册里还有个如何"拆开"Package的代码段，很好的展现了table的强大之处(Package也是在table上构筑的逻辑产物)。将Package拆开的意思，就是将所有 Package中公开的名字放入_G表中。也就是让 Package.A() 变成_G.A  (_G在一般情况下不需要写，默认引用了)

function openpackage (ns)  
      for n,v in pairs(ns)   
     do  
            _G[n] = v  
     end  
end