硬编码路径是自动化运维中典型的“断点风险源”，会导致跨环境失效、版本升级失败、容器化不兼容及集群动态适配失灵；应通过环境变量注入、模板预处理或符号链接实现路径解耦。
Nginx 默认目录结构中的路径不应在代码中硬编码——这不是一个可取的实践，而是自动化运维中典型的“断点风险源”。所谓“在代码中硬编码路径”，比如写死 root /usr/share/nginx/html;、access_log /var/log/nginx/access.log; 或 include /etc/nginx/conf.d/*.conf;，本质上是把部署细节耦合进配置本身，违背了环境无关、配置即代码（GitOps）的基本原则。
下面从实际角度说明为什么不能硬编码，以及真正该怎么做：
为什么硬编码路径会出问题
-
跨环境失效：开发机用
/opt/app/current，生产用/data/www/myapp，硬编码会让同一份配置在不同环境启动失败 -
升级失败：版本发布后目录变为
/opt/app/releases/v2.1.0，但root /opt/app/releases/v1.9.3;还在配置里，静态资源 404 -
容器化不兼容：Docker 中挂载日志到
/logs/，而配置里写死/var/log/nginx/，日志就丢失 -
集群动态适配失灵：自动扩缩容时新节点 IP 变了，但
proxy_pass http://10.1.2.3:8080;没更新，流量打空
哪些路径最容易被误写死（高频雷区）
-
root和alias指令中的文件系统路径 -
access_log/error_log的日志文件路径 -
include指令指向的子配置路径（如include /etc/nginx/sites-enabled/*;） -
ssl_certificate和ssl_certificate_key的证书路径 -
log_format中定义的格式名虽不涉路径，但若配合硬编码日志路径使用，会加剧耦合
正确做法：让路径由部署层决定
-
用环境变量注入（Nginx ≥1.19）
启动前设置：export APP_ROOT=/opt/myapp/current export LOG_DIR=/logs
配置中写：
root $APP_ROOT; access_log $LOG_DIR/access.log main;
-
模板预处理（Ansible/Jinja2/Bash）
root {{ nginx_root_path }}; ssl_certificate {{ ssl_cert_path }}/fullchain.pem;部署时由 playbook 或 CI 脚本填入真实值。
-
统一符号链接（最轻量可靠）
所有节点约定：ln -sf /opt/myapp/releases/v2.1.0 /opt/myapp/current ln -sf /etc/letsencrypt/live/example.com /etc/nginx/ssl/live
Nginx 只认
/opt/myapp/current和/etc/nginx/ssl/live/fullchain.pem，发布时只改软链，配置零改动。 -
证书路径抽象化
配置始终写：ssl_certificate /etc/nginx/ssl/cert.pem; ssl_certificate_key /etc/nginx/ssl/key.pem;
由部署脚本把真实证书
cp或ln -s到该位置，解耦签发方式（Let’s Encrypt / 自签名 / HashiCorp Vault）。
不复杂但容易忽略。
