改了 alias 指令后只需 reload 而非 restart：nginx 主进程校验新配置并启新 worker，旧 worker 优雅处理完请求后退出，alias 作为 location 内静态路径映射，由新配置实时计算，reload 即可零中断生效。
改了 alias 指令的路径后，并不需要“重启服务”才生效——只需要重新加载配置（nginx -s reload 或 systemctl reload nginx）即可，**重启（systemctl restart nginx）是过度操作，且不必要**。
真正需要“重载”而非“重启”的原因，在于 Nginx 的进程模型和配置加载机制：
主进程负责解析并分发新配置
Nginx 启动后由一个主进程（master）和多个工作进程（worker）组成。主进程不处理请求，只负责读取、校验配置文件，并在收到 reload 信号时：
- 检查新配置语法是否正确
- 若无误，启动新的 worker 进程，用新配置服务新连接
- 同时通知旧 worker 进程优雅退出（处理完当前请求后关闭）
alias 是静态路径映射，完全由配置驱动
alias 指令属于 location 块内的静态配置项，不依赖运行时状态或缓存。它在每次请求匹配 location 时，由 worker 进程实时按规则计算文件路径（例如：去掉 location 前缀，拼接剩余 URI 到 alias 路径）。这个逻辑完全由主进程加载进内存的配置决定，**不涉及磁盘轮询或热更新机制**。
为什么不能“热生效”？没有监听配置文件变化
Nginx 默认不会监控配置文件变更，也不会自动重读。这是设计选择：避免因文件系统事件误触发、保证配置变更的可控性与原子性。所以即使你直接修改了 nginx.conf，旧 worker 进程仍按旧配置运行，直到你显式发出 reload 指令。
常见误解：把 reload 说成 restart
很多人执行 systemctl restart nginx，其实做了两件事：
- 先 stop —— 杀掉所有进程（包括正在处理请求的 worker）
- 再 start —— 重新 fork master 和 worker，从头加载配置
这会造成短暂服务中断，而 reload 是零停机平滑切换，才是修改 alias 后的正确操作。
只要确保配置语法正确（可用 nginx -t 验证），改完 alias 后执行 nginx -s reload，新路径映射立刻生效。
