last重启location匹配，用新uri从server块重新查找；break终止当前rewrite并继续在原location内执行后续指令。
在 Nginx 配置中，rewrite 指令的 last 和 break 标志看似相似，实则触发完全不同的请求处理流程。关键区别在于：是否重新发起内部重写匹配（即是否重启 location 查找）。
last：重写后重启 location 匹配
使用 last 时，Nginx 会：
- 执行完当前 rewrite 规则后，用新 URI 替换旧 URI
- 立即停止当前 location 块内后续的 rewrite 指令
- 根据新 URI 重新搜索匹配最合适的
location块 - 从新匹配到的 location 块开头重新执行所有指令（包括其中的 rewrite）
这相当于一次“内部重定向”，适合需要切换上下文的场景，比如将 /api/v1/xxx 重写为 /v1/xxx 后交由专门处理 /v1/ 的 location 处理。
break：重写后终止重写阶段，继续当前 location
使用 break 时，Nginx 会：
- 执行当前 rewrite 规则，更新 URI
- 停止当前 location 块中所有剩余的 rewrite 指令
- 不重新匹配 location，直接进入该 location 块的后续处理阶段（如 proxy_pass、root 等）
它更像“URI 本地改写”，常用于路径标准化，例如把 /static/abc.css 改成 /assets/abc.css，仍由同一个静态文件 location 服务。
实际行为差异示例
假设有如下配置：
location /old/ {
rewrite ^/old/(.*)$ /new/$1 last;
}
location /new/ {
return 200 "served by /new/";
}
访问 /old/test → 重写为 /new/test → 重新匹配 → 进入 /new/ location → 返回 “served by /new/”。
若把 last 换成 break：
location /old/ {
rewrite ^/old/(.*)$ /new/$1 break;
return 200 "served by /old/";
}
访问 /old/test → URI 改为 /new/test，但仍在原 /old/ location 内继续执行 → 直接返回 “served by /old/”，/new/ location 完全不参与。
如何选择：看是否需要切换处理逻辑
选 last 当：
- 重写后应由不同 location（如不同 proxy_pass 或 root）处理
- 需应用新 location 中的 rewrite、access 控制等整套逻辑
选 break 当：
- 只是微调路径，后续仍走当前 location 的常规处理（如 alias、try_files）
- 要避免多轮 location 匹配带来的性能或逻辑干扰
