nginx指令必须在允许的上下文中使用，错置会报错；作用范围遵循层级继承与就近覆盖原则，如http块设值默认继承至server/location，但子块显式定义即覆盖，且部分指令（如add_header）子块一写则父级同名配置彻底失效。
理解 Nginx 配置中指令的上下文生效范围，核心是抓住“指令只能在它被允许的块里写，且作用范围由所在块的层级决定”。写错位置会报错，写对位置但没理清嵌套关系，会导致行为不符合预期。
指令必须出现在合法的上下文中
Nginx 不是所有指令都能随便放。每个指令都明确限定可在哪些上下文（context）中使用。比如：
- worker_processes 只能在 main（全局）上下文，也就是最外层、花括号之外的位置；放在 http 或 server 块里会直接启动失败。
- listen 和 server_name 只能在 server 块内；放在 http 块顶层或 location 里都不合法。
- root 和 proxy_pass 可以出现在 server 或 location 块中，但语义和效果不同——放在 server 里是默认路径，放在 location 里才是针对该路径的精确控制。
子块自动继承父块配置，但可被覆盖
配置具有层级继承性：http 块里的设置默认影响其下所有 server，server 里的设置默认影响其下所有 location。但这种继承不是“强制复制”，而是“默认值提供”：
- 在 http 块设 keepalive_timeout 65;，所有 server 都按 65 秒处理长连接；若某个 server 块里又写了 keepalive_timeout 15;，那这个站点就只用 15 秒。
- error_log 是 array 类型指令，父块写了多个，子块再写一个，就会完全替换掉父块的所有 error_log 设置，而不是追加。
- gzip 是普通类型指令，在 http 块设为 on，某个 location 里设为 off，那只对该 location 生效，其他 location 仍保持 on。
include 不改变上下文，只是文本拼接
include 不是“跳转执行”，而是把目标文件内容原样粘贴到当前行的位置。这意味着：
- 在 server 块里 include /path/to/location.conf;，那这个文件里只能写 location 指令或合法的 location 块内容；如果它开头就写 http { ... }，Nginx 启动时立刻报错。
- 路径顺序很重要：include /etc/nginx/conf.d/*.conf; 按字母序加载，后加载的同名指令（如重复的 log_format）会覆盖前面的。
- 想复用一组通用配置？把它写成独立文件，并确保它只含当前上下文允许的指令，再在对应位置 include。
匹配 location 时，作用域只看最终选中的那个块
多个 location 可能同时语法上“匹配”一个请求，但 Nginx 只选**优先级最高且最先匹配成功**的一个，然后完全使用它的配置，不会叠加或合并其他 location 的设置：
- location = /api { ... } 和 location /api { ... } 同时存在，请求 /api 会命中 = 精确匹配，/api/v1 才走前缀匹配的那一个。
- 一旦进入某个 location，里面的 root、proxy_pass、try_files 就完全接管本次请求，外面 server 块的同名指令不再参与。
- 别指望 “server 里设了 root，location 里没设，就自动用 server 的”——如果 location 里需要静态服务，就必须显式写 root 或 alias，否则可能 404。
