nginx -t 是唯一可靠的前置检查命令，它递归加载所有配置文件并校验语法、括号、分号、路径等，出错时明确提示文件名和行号，必须在 reload 前执行。
配置文件有语法错误时，Nginx 本身就会主动阻止服务重启或重载，这是它的默认安全机制，无需额外设置。关键在于你得用对命令、看清反馈，并在操作前主动验证。
nginx -t 是唯一可靠的前置检查命令
执行 nginx -t 会触发完整语法解析：读取主配置、递归加载所有 include 文件、校验指令格式、括号匹配、分号结尾、上下文合法性等。只要任一环节出错，它立刻报错并退出，且明确指出错误位置（如行号、文件路径）。
- 务必在修改后、重启前运行一次，不要跳过
- 如果使用了 include，确保被包含的文件路径真实存在且可读
- 常见低级错误：server 块末尾漏掉 }、location 路径引号不闭合、log_format 缺少分号
reload 不会静默失败，失败即中断
nginx -s reload 不是“尝试重载”，而是原子性操作：先调用内部 test 流程，全部通过才 fork 新 worker；一旦 test 失败，旧进程照常运行，新进程根本不会启动，命令直接返回非零状态并输出错误。
- 终端里看到 “configuration file ... test failed” 就说明 reload 已被拒绝，服务仍在原配置下运行
- 不会出现“看似成功但配置没生效”的情况
- 脚本中可用
$?判断返回值，为 1 即表示配置未通过
避免误用 restart 导致服务中断
用 systemctl restart nginx 或 nginx -s stop && nginx 这类“先停后启”方式，如果配置有误，Nginx 启动阶段就会失败，导致服务彻底中断——这不是阻止重启，而是引发宕机。
- 生产环境严禁在未验证的情况下用 restart 替代 reload
- reload 是唯一能保障服务不中断的配置更新方式
- 若必须用 restart（例如升级二进制），请确保 nginx -t 已通过，且有回滚预案
错误日志和权限问题也会伪装成语法错误
有些报错看起来像语法问题，实际是路径或权限导致的解析失败。比如：
- include "/etc/nginx/conf.d/*.conf" 中某个 conf 文件被 chmod 000，nginx 读不到，可能报“unexpected end of file”
- log_format 指向的路径不可写，有时会在 test 阶段报“open() ... failed”，误判为指令错误
- error_log /var/log/nginx/error.log; 但 /var/log/nginx 目录不存在，同样触发 test 失败
遇到可疑错误，先查 tail -n 20 /var/log/nginx/error.log，再结合 nginx -t 输出交叉判断。
