Nginx配置文件的语法格式

　　在nginx的世界里，每个Nginx模块都可以定义自己的配置指令，所以这些指令的格式五花八门。比如content_by_lua_block后跟着的是Lua语法，limit_req_zone后则跟着以空格、等号、冒号等分隔的多个选项。这些模块有没有必然遵循的通用格式呢？如果有，那么掌握了它，就能快速读懂生产环境复杂的nginx.conf文件。今天便来讲解Nginx配置文件的语法格式。
　　
　　Nginx是由少量框架代码、大量模块构成的，其中，Nginx框架会按照特定的语法，将配置指令读取出来，再交由模块处理。因此，Nginx框架定义了通用的语法规则，而Nginx模块则定义了每条指令的语法规则，作为初学者，如果将学习目标定为掌握所有的配置指令，方向就完全错了，而且这是不可能完成的任务。

　　比如，ngx_http_lua_module模块定义了content_by_lua_block指令，只要它符合框架定义的{}块语法规则，哪怕大括号内是一大串Lua语言代码，框架也会把它交由ngx_http_lua_module模块处理。因此，下面这行指令就是合法的：

　　content_by_lua_block {ngx.say("Hello World ")}

　　所以，在我看来，只要弄清楚了以下2点，就能快速掌握Nginx配置文件，：

　　第一点：Nginx框架定义了每条指令的基本格式，这是所有模块必须遵守的规则，这包括以下5条语法：

　　通过{ }大括号作为分隔符的配置块语法。比如http{ }、location{ }、upstream{ }等等，至于配置块中究竟是放置Javascript语言、Lua语言还是字符串、数字，这完全由定义配置块的Nginx模块而定。

　　通过；分号作为分隔符的指令语法。比如root html;就打开了静态资源服务。

　　以#作为关键字的注释语法。比如#pid logs/nginx.pid;指令就是不会生效的。

　　以$作为关键字的变量语法。变量是Nginx模块之间能够互相配合的核心要素，也是Nginx与管理员之间的重要接口，通过$变量名的形式，就可以灵活控制Nginx模块的行为。

　　include指令可以将其他配置文件载入到nginx.conf中，这样可以提升配置的可维护性。例如include mime.types;语句，就将Content-Type与文件后缀名的映射关系，放在了独立的mime.types文件中，降低了耦合性。

　　第二点：Nginx框架为了提高模块解析指令选项的效率，提供了一系列通用的工具函数，绝大多数模块都会使用它们，毕竟这降低了模块开发的难度以及用户的学习成本。比如，当配置文件中包含字节数时，Nginx框架提供了ngx_conf_set_size_slot函数， 各模块通过它就可以解析以下单位：
　　
　　因此，limit_req_zone指令中zone=one:10m中就定义10MB的共享内存，这替代了很不好理解的10485760字节。

　　再比如，读取时间可以使用以下单位：
　　
　　这样，ssl_session_cache shared:SSL:2h;指令就设置TLS会话信息缓存2小时后过期。

　　除以上规则外，如果编译了pcre开发库后，你还可以在nginx.conf中使用正则表达式，它们通常以~符号打头。

　　由于每个Nginx模块都能定义独特的指令，这让nginx.conf变成了复杂的运维界面。在掌握了基本的配置语法，以及第三方模块定义指令时遵循的潜规则后，你就能游刃有余地编写Nginx配置文件。