Nginx配置加载按上下文层级解析而非线性执行，server块按匹配树优先级而非定义顺序选择，location正则匹配依赖配置顺序，include为预处理展开。
Nginx 加载 nginx.conf 时，并不是简单地从上到下逐行执行，而是按配置块层级和上下文作用域进行解析与合并。加载顺序直接影响指令是否生效、继承关系是否成立、以及最终行为是否符合预期。
配置块的嵌套层级决定作用域优先级
Nginx 的配置基于“上下文（context）”，如 main、events、http、server、location 等。指令只能出现在允许的上下文中，且内层块会覆盖外层同名指令（部分指令不支持覆盖，会报错）。
-
worker_processes只能在main上下文，写在http块里会启动失败 -
root在server块中设置后，其下的location /api可以用root或alias覆盖路径映射 -
index在http中设为index.html，但在某个location中设为index.php，则该 location 下请求目录时会优先找index.php
同级 server 块按监听地址+端口+server_name 匹配，而非配置顺序
server 块之间没有“先定义就先匹配”的顺序逻辑。Nginx 启动时会构建一个虚拟服务器匹配树：
- 精确匹配
server_name example.com优先于通配符*.example.com - 通配符前缀（
*.example.com）优先于后缀（example.*） - 无
server_name或匹配失败时，使用listen指令中带default_server标志的块 - 若多个
server都监听80且都未标default_server，Nginx 默认选第一个（但不应依赖此行为）
location 块匹配是运行时行为，但定义顺序影响正则匹配结果
location 分两类：前缀字符串匹配（含 =、^~）和正则匹配（~、~*）。匹配规则如下：
- 先找最长的前缀匹配（不区分大小写，但
=是精确匹配，优先级最高） - 若存在
^~且前缀匹配最长，则不再检查正则 - 否则，按配置文件中出现的顺序依次尝试正则匹配，第一个成功即停止
例如：
location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; }
location ~ ^/admin/.*\.php$ { deny all; }第二行永远不会生效——因为第一行更早且已匹配所有 .php 请求。应把更具体的正则放在前面。
include 指令是预处理，内容直接插入当前位置
include 不是“导入模块”或“延迟加载”，而是在配置解析阶段将文件内容原样展开。这意味着：
-
include mime.types;实际等价于把mime.types文件全文复制进当前行位置 - 若
include放在http块中间，它引入的types指令就处于http上下文；若误放在server块里，会导致语法错误 - 多个
include的顺序会影响指令可见性，比如先include upstreams.conf，再定义server，才能在server中引用其中的 upstream
