企业级Nginx配置文件命名规范要求按功能职责（如ssl-cert.conf）、环境维度（/prod/、/staging/子目录）和站点角色（api-payment-prod.conf）明确标识，禁用模糊名称，确保可读、可追溯、可复用、可审计。
企业级 Nginx 配置文件的命名规范，核心目标是让配置可读、可追溯、可复用、可审计。不是起个“看着顺眼”的名字，而是通过命名直接暴露意图、环境、作用域和生命周期。
按功能职责拆分命名
每个配置文件只承担单一语义职责，文件名需明确体现其功能边界：
-
ssl-cert.conf：仅含
ssl_certificate和ssl_certificate_key路径，附注证书有效期（如# expires: 2027-03-15） -
ssl-protocol.conf：专注 TLS 版本、密钥交换与加密套件（
ssl_protocols、ssl_ciphers、ssl_prefer_server_ciphers） -
security-headers.conf：集中管理
Strict-Transport-Security、X-Content-Type-Options等响应头 -
rate-limit.conf：定义
limit_req_zone和具体 location 下的限流策略 - upstream-app.conf：仅描述后端服务列表与健康检查参数，不混入 server 或 location 块
按环境维度加前缀或归入子目录
避免在配置中硬编码 if ($env = "prod") 这类易出错逻辑。推荐用物理路径隔离：
- 统一基线放在
/etc/nginx/https/common/（如通用 HSTS、CSP 模板） - 生产专用配置放
/etc/nginx/https/prod/（如完整证书链、严格 cipher suite） - 预发/测试环境配置放
/etc/nginx/https/staging/（如自签名证书、宽松超时） - 站点级入口配置（如
example.com.conf）中通过include https/common/*.conf;和include https/prod/*.conf;显式加载
按站点与角色明确标识
站点配置文件名应包含业务标识和部署角色，便于快速定位归属：
- api-payment-prod.conf：面向支付网关的生产 API 入口
- www-cms-staging.conf：CMS 系统的预发静态门户
- monitor-grafana-internal.conf：内网监控系统反向代理，带访问控制
- 禁用模糊命名如
nginx.conf.bak、test.conf、new.conf—— 它们无法回答“这是谁的？在哪用？是否生效？”
审阅要点：命名是否传递有效信息
每次上线前或 CR（Code Review）时，可快速核对以下问题：
- 该文件名能否让人 3 秒内判断出它属于哪个业务、哪个环境、承担什么安全或路由职责？
- 是否存在两个功能重叠的文件（如同时有
ssl.conf和https.conf）？应合并或明确主从关系 - 是否所有
include路径都使用通配符或显式文件名？禁止出现include ../conf/*这类不可控路径 - 证书类文件是否附带有效期注释？无注释的证书配置视为待验证项
- 是否有未被任何
server或http块引用的“孤儿”配置文件？应归档或删除
命名不是风格问题，而是配置治理的第一道防线。清晰的命名能让一次 grep 查到根源，一次 ls 看清架构，一次误删也能立刻识别影响范围。
