Nginx的include指令决定配置加载、逻辑生效与维护可持续性，需按功能分目录（upstreams/、routes/、snippets/、security/），路径以/etc/nginx为基准，加载位置严格对应作用域，且须用编号控制通配符加载顺序。
nginx 的 include 不是“加个文件”那么简单，它直接决定配置是否能加载、逻辑是否生效、维护是否可持续。用对了，千行配置如丝般顺滑；用错了，一个路径或位置偏差就能让 nginx -t 报错，甚至线上服务中断。
按功能分目录，别堆在 conf.d 里
把所有 .conf 塞进 /etc/nginx/conf.d/ 是最常见也最危险的懒人做法。时间一长，谁加的 upstream？哪个文件定义了 rate_limit？根本没法追溯。推荐明确划分职责目录：
-
upstreams/：只放 upstream 块，命名体现服务用途，比如
payment-api.conf、auth-service.conf -
routes/：每个业务路径一个文件，内容仅含 location 块，例如
/routes/user-api.conf内只写location /user { proxy_pass http://user-upstream; } -
snippets/：纯复用片段，无上下文依赖，像
proxy-params.conf（含 proxy_set_header 系列）、cache-control.conf（含 expires 和 add_header） - security/：集中管理 IP 黑白名单、UA 过滤、CORS 策略，避免在每个 server 里重复写 if 判断
路径必须绝对，且以 /etc/nginx 为基准
include 的路径不是“相对于当前文件”，而是始终以 nginx 主配置根目录（通常是 /etc/nginx/）为起点。写相对路径容易翻车：
-
include mime.types;→ 实际读取/etc/nginx/mime.types -
include ./conf.d/api.conf;→ 等价于/etc/nginx/conf.d/api.conf -
include ../shared/headers.conf;→ 只要权限允许，可向上跳转，但不建议跨级太深 - 含空格或特殊字符的文件名必须加引号：
include "my app.conf";
加载位置决定作用域，不能越界
同一行 include 写在不同块里，效果天差地别。Nginx 启动时原样插入内容，所以被引入的文件只能包含当前上下文允许的指令：
- 在
http { }最外层 includeupstreams/*.conf：upstream 对所有 server 和 location 可见 - 在某个
server { }里 includesnippets/ssl.conf：该文件只能有 ssl_certificate、ssl_protocols 等 server 级指令 - 在
location /api { }中 includesnippets/auth-header.conf：只影响这个 location，适合加鉴权头或限流 - map、log_format、upstream 必须声明在 http 块顶层，不能塞进 server 或 location 里
控制加载顺序，用编号前缀代替字母序
通配符匹配（如 *.conf）按文件系统字母顺序加载，这直接影响 server_name 匹配优先级和指令覆盖关系。靠文件名排序比靠人工记忆可靠得多：
- 泛域名或兜底配置用
99-wildcard.conf，确保最后加载 - 默认站点用
00-default.conf，最先生效 - 核心业务 API 用
10-order-api.conf、20-user-api.conf，按重要性排 - 每次新增或调整后，执行
nginx -t校验，再nginx -s reload生效
