Nginx 改配置后先测试再重载的正确顺序
改完 Nginx 配置文件，直接执行 nginx -s reload 是有风险的。正确顺序是先 nginx -t 验证，再重载。这条顺序能避免一次手误把线上站点打挂。
什么情况下会撞上它
典型场景是给站点加一个 server 块、改 location 规则、调 proxy_pass 上游地址，或者加一条重写规则。改完保存，顺手 reload，结果终端返回一行错误，站点随即 502 或直接连不上。
另一种情况更隐蔽：配置里少了一个分号，nginx -t 没跑，reload 之后新 worker 起不来，旧 worker 还在，但新连接的处理已经乱了。所以关键不是“会不会报错”，而是“报错时有没有把旧服务拖下水”。
为什么先测试有效
Nginx 的 reload 不是重启进程，而是给 master 进程发信号，让它重新读取配置、启动新的 worker、再优雅退出旧 worker。这个流程里，配置解析发生在 master 进程内。
如果配置有语法错误，master 在解析阶段就会失败，不会走到“启动新 worker”那一步。此时旧 worker 仍在按旧配置服务，连接不受影响。nginx -t 做的事就是提前触发这次解析，把错误挡在 reload 之前。
换句话说，nginx -t 是“试读”，reload 是“换书”。先试读，读不通就不换。
怎么做
第一步，改完配置先测试。这条命令只检查语法和基本结构，不改变运行状态：
nginx -t通过时输出类似：
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful第二步，只有看到 test is successful 才重载。这条命令让 master 重新加载配置：
nginx -s reload如果第一步就报错，输出会指出文件和行号，例如：
nginx: [emerg] unexpected "}" in /etc/nginx/conf.d/example.conf:42
nginx: configuration file /etc/nginx/nginx.conf test failed按行号回去改，改完再跑一次 nginx -t，直到通过。
怎么确认成了
nginx -t 返回 test is successful 且退出码为 0，说明语法层面没问题。reload 之后，可以用 nginx -s reload 无输出、进程号变化来侧面确认：master 进程号不变，worker 进程号会换一批。
更直接的验证是访问一个受影响的 URL，看返回是否正常。语法通过不等于逻辑正确，比如上游地址写错，nginx -t 照样通过，但请求会 502。
边界和坑
nginx -t 只保证语法和结构，不保证业务正确。proxy_pass 指向一个不存在的上游、root 指到空目录，它都测不出来。
另外，nginx -t 默认读主配置，如果配置分散在 conf.d 里，它会一并加载，所以不用单独测子文件。但如果用了 -c 指定其他配置文件，测试和 reload 必须用同一个 -c，否则测的不是同一份。
还有一个容易忽略的点：nginx -t 通过不代表 reload 一定成功。极端情况下，端口被占用、权限不足等问题会在 reload 阶段才暴露。所以 reload 后仍要看一眼错误日志，确认没有新的 [emerg] 或 [alert]。
最后，这套顺序适用于单机 Nginx。如果配置由配置管理工具批量下发，测试步骤应该放进下发流程里，而不是靠人手动跑。
