企业官网建设流程全解析

1. rewrite到底在解决什么问题

1.1 从一次用户访问说起

先不急着看指令的参数，我们从一次真实访问说起。假设你的站点部署在某服务器上，用户习惯于访问http://example.com/product/123，但应用的老接口其实是http://example.com/index.php?id=123&cat=product。如果直接让用户访问后者，一是URL难看、难记，二是搜索引擎收录的地址一旦变化，权重就白白流失了。这时候就需要Nginx的rewrite重写功能，把美观的URL在内部映射回真实的处理路径，这是它最基础也最常用的能力。

我当年第一次接触Nginx的rewrite时，网上资料一搜一大把，但大多贴一段配置让人照抄，没人讲清楚它背后到底怎么运转。结果我抄了一个跳转规则，服务直接报500，查了半天才发现是死循环。后来花了几个晚上把官方文档和一线的排错经验揉在一起，才算彻底把这些指令吃透。这篇就把我实际使用中的理解、踩过的坑、总结出来的排错套路一次讲清。

要理解rewrite，先得把它和HTTP请求的处理流程挂钩。Nginx接收到一个请求后，会先解析URI，然后进入location匹配阶段，最后才在rewrite模块里执行URL改写或重定向。这个模块干两件事：一是把URI在服务器内部改成另一个值，重新走一遍location匹配；二是直接返回30x跳转，告诉浏览器去访问一个新地址。前者用户无感知，后者浏览器地址栏会变，这是本质区别，后面所有配置思路都围绕这两点展开。

1.2 不同业务场景对跳转的需求差异

我接触过的项目里，rewrite几乎无处不在，但每种场景对它的要求完全不同。先列几个最高频的：

• 站点迁移旧域名换新域名，必须做301永久跳转，把旧域名的权重迁移到新域名，同时保留路径参数。
• 强制HTTPS访问，所有HTTP请求统一跳转到HTTPS对应地址，既保留参数又不丢路径。
• 移动端和PC端适配，根据User-Agent跳转到不同站点或不同路径。
• URL规范化，比如统一去掉URL末尾多余的斜杠、统一大小写、修复重复斜杠。
• 伪静态化，把动态接口地址伪装成静态化的URL，既美观又能保护真实参数结构。
• 防盗链和防乱码，根据Referer或特定参数做拦截或跳转。

这些场景看起来都是"跳转"，但实现时的配置差异极大。有些只需一条简单的rewrite语句，有些则要配合location优先级、if判断和变量捕获一起做。而且rewrite和location匹配顺序互相影响，用错了就会出现规则不生效、跳转错误、甚至无限循环。所以我建议你按"先理解执行机制、再套用场景模板"的思路来学，而不是看到一条配置就去抄。

如果你只记得一句话，那就记住这句：rewrite是对URL的二次加工，发生在Nginx内部定位到location之前或之后的关键节点，理解了这个时序，后面所有场景都能想明白。

2. rewrite核心语法与匹配原理

2.1 rewrite指令的三段式结构

rewrite指令的语法非常简洁，就三个部分：

rewrite 正则表达式 替换内容 [标志位];

正则表达式用于匹配当前请求的URI，替换内容是匹配成功后的目标地址，标志位决定这次改写之后的处理方式。举个例子：

rewrite ^/product/(\d+)$ /index.php?id=$1 last;

这条规则的意思是把形如/product/123的请求，内部改写成/index.php?id=123。这里面有两个关键点。第一，^和$分别锚定URI的开头和结尾，避免部分匹配造成规则意外生效；第二，正则里的小括号是捕获组，$1就是取第一个捕获到的内容，实际请求的数字直接放到了参数里。

需要注意，这里的"URI"默认不包含查询字符串，比如请求/product/123?page=2，rewrite规则匹配到的是/product/123，page=2这个查询参数不会被正则匹配到，但重写后的URL会默认自动拼接上原有参数。如果你在替换内容里显式写了一个问号和参数，Nginx会优先使用替换内容自带的参数，行为上略有差异，这一点在配置时需要格外留神。

三段式看着简单，真正复杂的在于正则表达式的编写。很多人栽在正则上，不是不会写，而是没掌握Nginx正则的匹配习惯。Nginx默认使用PCRE正则库，和你在其他语言里用的正则大部分相通，但要注意几个细节：\d可以直接匹配数字，\w匹配字母数字下划线，.在默认情况下不匹配换行。如果URL里出现特殊字符，比如?、&、%，正则里要记得转义或在设计时避开这些字符。

2.2 正则表达式的关键元字符

正则表达式是rewrite的灵魂。我见过很多半路出家的运维，配置文件抄得飞起，正则一复杂就抓瞎。其实不需要背几十个元字符，掌握下面这批就够应付九成场景：

实际编写时有几个易错点。.在正则里是万能匹配，不是字面上的点，很多新手写^/index\.html$时，把点转义了没问题，但写^/index.html$时，点会匹配任意字符，比如indexxhtml也能过，这在严格匹配时会埋雷。还有一个更隐蔽的坑：正则中$在Nginx里除了表示URI结尾，还能引用捕获变量，比如$1、$2，所以在替换内容里写$时务必形如$1，如果你要字面输出一个美元符号，反而要特殊处理，不过实际业务中极少遇到。

同一规则里捕获组不要超过9个，虽然技术上支持更多，但可读性和维护性会急剧下降。我自己的习惯是最多3个捕获组，多了就拆成多条规则或用变量中转。

2.3 常见的rewrite表达式案例

光看元字符不够，我给几个我项目里真实用过的表达式，配合说明，你配置的时候可以直接套：

# 纯数字ID的伪静态 rewrite ^/news/(\d+)$ /show.php?id=$1 last; # 分页URL重写，捕获页码和分类 rewrite ^/list/(\w+)/page/(\d+)$ /list.php?cat=$1&page=$2 last; # 去掉URL末尾多余的斜杠 rewrite ^/(.*)/$ /$1 permanent; # 统一旧路径到新路径 rewrite ^/old/path/(.*)$ /new/path/$1 permanent;

第一条最常用，很多内容站的文章地址都是这种格式。第二条适合带分类和分页的列表页，捕获组分别对应分类名和页码。第三条要注意，它会匹配所有以斜杠结尾的路径并把末尾斜杠去掉，如果目标路径本身是目录，反而可能影响访问，所以要结合location一起设计。第四条是站点改版时做路径映射的标准写法，(.*)把旧路径后面的所有内容原样拼到新路径上。

正则表达式还有一个使用习惯值得强调：能用精确字符匹配尽量不用点号万能匹配。比如^/product/[0-9]+$比^/product/.*$严谨得多，前者不会把/product/abc也抓进来。严谨的正则不仅减少误伤，也能降低别人接手配置时的理解成本。

3. 执行顺序、标志位与内部跳转机制

3.1 执行阶段与顺序

rewrite看起来就是个改URL的指令，但执行顺序才是最容易翻车的地方。很多人只知道往server块里塞几条rewrite，然后发现完全不按预期工作。实际上Nginx处理一个请求的rewrite流程是有明确先后顺序的：

1. server块里的rewrite指令，按书写顺序依次执行。
2. 如果rewrite命中了带last标志的规则，会停止当前级别的rewrite，重新进行location匹配。
3. location匹配完成后，location块内部的rewrite指令继续执行。
4. 执行完location内所有rewrite后，请求进入后续处理阶段（比如转发到后端或返回静态文件）。

举个例子。你在server块里写了把/old改成/new的rewrite，同时有个location /new的匹配块。当用户访问/old时，server级别的rewrite执行后URI变成了/new，然后Nginx重新匹配location，命中location /new，这才是预期流程。如果这一步你用了break而不是last，Nginx不会再重新匹配location，后续的处理逻辑就完全不同。

这个时序是理解整个rewrite的钥匙。我见过一个真实案例：配置里在server层把http://请求强制跳转https://，又在location里对某个路径做了rewrite，结果用户访问某个具体路径时怎么都不跳HTTPS，排查半天发现location里的rewrite执行完直接进入了后端处理，根本没有回到server层的跳转逻辑。后来通过在location里显式增加对应的HTTPS跳转规则解决。这种问题在系统学习执行顺序之前，光靠试错真的头大。

3.2 flag标志的选择技巧

标志位决定了rewrite完成后的动作，是配置文件里最容易被随手乱写的地方。四个标志各有用处，我一个个说：

last和break是最容易混淆的一对。很多初学者把两者混用，结果行为差别很大。last是"改完再找一下合适的location"，break是"改完就这样处理下去"。一句话记法：如果你把URI改成了一个真实存在的、能被某个location精准匹配的路径，用last；如果你只是在当前location里微调一下URI，不希望再跑去别的location，用break。

redirect和permanent则直接作用于用户浏览器。301是永久跳转，浏览器和搜索引擎都会把旧地址替换成新地址；302是临时跳转，地址栏会变，但搜索引擎仍认为旧地址有效。实际常用的原则是：确定不会回退的用301，比如换域名、强制HTTPS；临时活动页、运维切换期间的用302，改回旧地址也方便。

这里有一个容易被忽略的坑：redirect和permanent后面的URL如果要带参数，务必使用完整的URL格式，比如https://example.com/new?from=$request_uri。直接写相对路径的话，Nginx在某些场景下会自动补全server_name，但补出来的域名未必是你想要的，尤其是在多域名共用一个server的情况下。

3.3 与location匹配的配合关系

rewrite和location的关系，很多人学了很久还是绕不清楚。我打一个比方：location像是一个个门口挂着牌子的办公室，请求来了，先看牌子哪个对得上，然后进对应的办公室办事；server层的rewrite像是在大厅里设置的一个引导台，它改写了你要去的方向，然后你重新找办公室。

因为rewrite改写URI之后可能重新匹配location，所以规则设计时要考虑"改了之后会落到哪里"。比如你的业务逻辑全部在location /index.php里，那你rewrite的目标就应该写成/index.php，而不是随便写一个不存在的路径。一旦目标URI没有匹配到任何location，Nginx会按默认规则处理，通常是找静态文件，找不到就404，这个结果往往不是你想要的。

在location内部写rewrite时，还要注意是否存在再次匹配到自身的可能。比如：

location /download/ { rewrite ^/download/(.*)$ /files/$1 last; }

这里重写后的URI是/files/...，如果后续没有其他规则，/files路径会被静态文件处理器接管，这是常见用法。但如果你把last换成permanent，则变成浏览器可见的302跳转，URL暴露了真实内部路径，通常不是想要的。

在多location环境下，一个常见的错误是：在location /里写了一条rewrite，原本只想作用于特定路径，结果因为location /是兜底匹配，所有没被其他location拦下的请求全部命中这条规则，导致跳转风暴。解决办法就是正则匹配尽量写精确，或者把通用rewrite放server层，只在需要特殊处理的location里单独写规则。

3.4 实际配置示例

光讲理论边界太虚，我放一个我实际项目里用过的完整示例，你可以对照理解执行顺序：

server { listen 80; server_name example.com www.example.com; # 强制HTTPS，所有HTTP请求301到HTTPS if ($scheme != "https") { rewrite ^(.*)$ https://example.com$1 permanent; } # 旧路径迁移 rewrite ^/old-blog/(.*)$ /blog/$1 permanent; location / { # 伪静态规则 rewrite ^/article/(\d+)$ /index.php?id=$1 last; rewrite ^/category/(\w+)$ /index.php?cat=$1 last; # 动态请求直接交给PHP处理 location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; } } location ~* \.(jpg|png|gif|css|js)$ { expires 30d; access_log off; } }

这个配置里，用户访问http://example.com/old-blog/post1时，先走80端口server的HTTPS跳转，变成https://example.com/old-blog/post1；然后命中旧路径迁移规则，再301到https://example.com/blog/post1；接着进入location /，如果路径形如/article/123，就内部改写成/index.php?id=123并重新匹配到location ~ \.php$，最终交给PHP处理。静态文件请求因为正则location优先级更高，直接命中静态缓存规则，不参与PHP处理。

整个流程走下来，你会发现每一条rewrite其实都在回答一个问题：我这个URL应该去哪。想清楚了这个问题，配置就不再是一堆规则的堆砌，而是一条清晰的请求路径。

4. 典型业务场景配置实战

4.1 域名与URL规范化

域名层面的规范化是rewrite最广泛的应用。最常见的需求有两种：主域名统一和协议统一。

主域名统一：用户可能通过多个域名访问你的站点，比如example.com、www.example.com、example.net，为了SEO和防止重复内容，需要把非主域名301到主域名。配置方式如下：

server { listen 80; server_name example.net www.example.com; return 301 http://example.com$request_uri; } server { listen 80; server_name example.com; # 正常站点配置 }

有人会问，这里为什么用return而不是rewrite？因为这是一个纯固定的跳转，不需要复杂的正则改写，return更高效也更易读。rewrite能干的事，return不一定能干，但纯域名跳转这种场景，return是更好的选择。如果你有类似"把旧域名的某个前缀路径单独跳过去"的需求，再回到rewrite。

URL规范化则更细碎，比如统一去除路径末尾的斜杠。这里有个反直觉的地方：对目录来说，末尾斜杠是必需的，去掉反而可能导致404。所以我一般只对文件类URL做去斜杠处理，目录类按原样放行。可以用一条正则精确匹配：

rewrite ^/(.*?)/+$ /$1 permanent;

这条规则会把/abc//或/abc/这种URL变成/abc。但要注意，正则里的+右斜杠是多次出现的场景，如果本身路径就是目录，需要结合实际站点结构决定是否启用。

4.2 强制HTTPS跳转

强制HTTPS大概是现代站点中最常见的rewrite需求了。虽然很多云厂商的负载均衡器或者CDN层面已经做了，但源站如果没配好，仍然会漏掉一部分裸访问。最通用的配置还是那三板斧：

server { listen 80; server_name example.com www.example.com; return 301 https://example.com$request_uri; } server { listen 443 ssl; server_name example.com www.example.com; # SSL证书配置省略 # 站点业务配置 }

这种写法和之前的域名统一一样，用return而不是rewrite，因为整站统一跳转用return就足够高效。但如果你的站点一部分路径已经走HTTPS，一部分还走HTTP（比如某些老旧接口），就需要用rewrite配合if来精确控制：

if ($scheme = "http") { rewrite ^/secure/(.*)$ https://example.com/secure/$1 permanent; }

这里要特别提一个所有配置过HTTPS跳转的人都会遇到的大坑：跳转时把端口号弄丢了。如果你的站点跑在非标准端口上，比如https://example.com:8443，你写rewrite ^(.*)$ https://example.com$1 permanent;时，$1只包含路径，不包含端口，跳转后端口直接丢了，用户访问的是443端口，如果443端口没开，直接无法访问。正确做法是把端口写死在跳转地址里，或者用$host:$server_port变量拼接，但后者在纯HTTP环境下可能把80端口也带出来，所以还是建议显式写完整。

另外提醒一句：虽然if在Nginx里有被称为"百害之首"的说法，但限定在rewrite场景下的if+return或if+rewrite是官方文档认可的安全用法。真正要避免的是在if里写proxy_pass等复杂的反向代理配置，那种场景下if的继承和上下文问题非常多。如果你看到一篇教程教你在location里用if包一层proxy_pass，请保持怀疑。

4.3 伪静态与路径重写

伪静态是内容型网站的重头戏。以前写PHP站点，URL是show.php?id=123，后来为了SEO改成了/show/123.html这种形态。Nginx配置里要做两件事：一是把真实访问的静态化路径rewrite回show.php?id=123，二是防止用户直接访问动态地址造成权重分散。第一件事的配置是：

location / { rewrite ^/show/(\d+)\.html$ /show.php?id=$1 last; rewrite ^/list/(\d+)-(\d+)\.html$ /list.php?cat=$1&page=$2 last; }

第一条匹配数字ID的详情页，第二条匹配分类分页列表页。关键点在于last标志，它会重新匹配location，让改写后的URI落到PHP处理块里。

但很多站点的问题恰恰出在"防动态访问"上。如果用户直接访问show.php?id=123，而你的站点没有做任何防护，搜索引擎会收录两个地址指向同样内容，造成重复内容分权。正确的做法是检测到动态地址访问时301到静态化地址。这里如果直接写rewrite ^/show\.php\?id=(\d+)$ /show/$1.html permanent;是无效的，因为我在前面提过，rewrite的正则不匹配查询字符串。要处理这个问题，必须用参数变量：

if ($args ~* "^id=(\d+)$") { set $page_id $1; rewrite ^/show\.php$ /show/$page_id.html permanent; }

这里的思路是先用if配合正则捕获查询参数里的ID，赋值给变量，然后再做301跳转。为什么不能直接在rewrite里用$args？因为rewrite的正则匹配目标只是URI，不含查询串，而$args是完整查询字符串，你可以整体拼到跳转地址里，但想从里面提取某个参数值就需要if加正则。这是rewrite参数处理的经典解法，值得多写几遍加深记忆。

伪静态还有一个细节：目标PHP文件的真实路径和重写后的URI不能冲突。比如你的rewrite目标是/show.php，但用户如果构造一个/show.php的访问，同时你的rewrite规则里恰好有^/show.php$的正则，那么Nginx内部会反复改写。解决办法是把动态脚本放到独立目录，比如/internal/show.php，这样对外静态化、对内动态处理，互不干扰。很多框架就是这么干的，入口文件放在单独目录里，避免和公开路径交叉。

4.4 基于参数的跳转规则

参数处理是rewrite里最考验细节的地方，搞不好就会跳错。前面已经演示了用if提取参数的方法，我再补充几个参数相关的常见场景。

参数透传是默认行为，这个很多人不清楚。比如你rewrite^/go/(.*)$ /redirect.php?url=$1 last;，用户访问/go/https://example.com时，$1里如果包含了特殊字符，Nginx传给后端时可能会转义异常。碰到这种需要透传URL的场景，最好用$request_uri或者配合proxy_pass使用，而不是硬拼接。$request_uri包含完整的原始请求行（路径加查询串），用它可以最大程度保留原始信息。

去掉特定参数的需求也常见，比如用户访问/product/123?utm_source=ad，你想在跳转时清除广告参数。Nginx本身没有直接删除参数的指令，但可以用正则重写查询串：

if ($args ~* "(.*)(?:^|&)utm_source=[^&]*&?(.*)") { set $args $1$2; rewrite ^/product/(\d+)$ /product/$1 permanent; }

这是个纯正则处理字符串的活，看着丑陋但实用。核心思路是：把$args里匹配到的广告参数段扣掉，剩下的部分重新赋值给$args，最后再做跳转。这里要特别小心正则的贪婪匹配，如果原参数顺序调整，正则可能匹配错误。我一般会在测试环境先跑一下预期结果，确认无误再上生产。

平台内嵌分享链接的跳转也是靠参数。比如微信内自动跳转App下载页，需要一个中转页面，配置里可能是这样：

location = /app/download { if ($args ~* "^platform=(android|ios)$") { set $platform $1; rewrite ^/app/download$ /download.php?platform=$platform last; } return 404; }

location = /app/download是精确匹配，不走正则location，能最大程度降低其他规则干扰。然后通过if判断参数合法后，把参数映射到实际处理脚本。如果参数不对，直接返回404，相当于做了一层访问控制。这种写法比单纯rewrite更稳妥，因为它在进入rewrite之前就过滤掉了非法请求。

参数场景我最后再总结一句：rewrite本身不擅长处理查询字符串，凡是涉及参数提取、删除、重组的需求，基本都要借助if+ 变量 + 正则三步走。不要试图写一条复杂的正则在rewrite里解决所有问题，拆分处理才是正途。

5. 常见问题与排查技巧实录

5.1 循环重定向与500错误

rewrite配置最大的噩梦就是浏览器报"重定向次数过多"或者Nginx报500。这两类问题背后往往是同一个原因：rewrite规则把自己改成了自己，或者A规则改到B，B规则又改回A。

我遇到过一个印象深刻的案例。某站点配置了强制HTTPS跳转，同时在location里对部分路径做rewrite，结果访问首页一切正常，访问某个咨询页就无限循环。排查发现：location里那条rewrite把/info改成了https://example.com/info，浏览器访问这个地址后，Nginx又执行了一次HTTPS跳转检查，发现$scheme变成了https，放行，但location的rewrite又执行了一遍，把URI再次改成https://example.com/info，而这个"完整URL"又匹配到了location规则里的正则，于是再次重写，循环到浏览器崩溃。

这种问题的定位方法很简单，先看日志。Nginx错误日志里会打印类似rewrite or internal redirection loop的信息，后面通常跟着URI。看到这个，基本就能确定是哪条rewrite导致的死循环。解决办法通常是三个方向：

• 给rewrite加一个前置条件，比如用if判断$scheme、$host或URI前缀，确保只对特定请求执行。
• 把flag从permanent/redirect改成break或last，避免浏览器参与循环。
• 重写正则，让目标URI不再是原规则的匹配范围。

500错误有一点要注意：它不一定总是rewrite循环，也可能是rewrite正则捕获组引用错误。比如$1被用在了一个根本没有捕获组的正则里，Nginx在执行时会报unknown "1" variable。碰到这种错误，打开错误日志基本能看到明确的变量名提示，逐个排查即可。

还有一类问题隐藏在permanent跳转里：浏览器对301有缓存。如果某条301规则写错了，哪怕你立刻改正配置，已经访问过的用户浏览器里仍然会有旧的跳转缓存，继续把人带到错误地址。这个坑很难现场Debug，所以生产环境测试新跳转规则时，我强烈建议先用redirect（302）观察几天，确认无误再改成permanent（301）。一旦用了301，后期想纠正就非常被动。

5.2 不理解location和rewrite的先后

rewrite和location哪个先执行？很多人搞反，导致配置不生效。我再强调一遍：server块的rewrite先执行，然后重新匹配location；location内部的rewrite在该location匹配成功后才执行。如果server块里没有rewrite，请求会先进入location匹配。这个顺序决定了配置的摆放位置。

还有一个经典误区：在location /里写了rewrite，以为只影响根路径，其实location /是前缀匹配的兜底，所有没被更精确前缀或正则location接管的请求都会落进来。所以那些落在location /里的rewrite规则，本质上对所有"落进兜底"的请求生效，设计时要格外注意正则的限定范围。

一个我常用的判断方法：如果规则只在特定路径下生效，优先放到对应location里；如果规则是全站统一的（如HTTPS跳转），放server块；如果规则依赖uri路径变化后重新匹配location，用last配合server级rewrite。按这个习惯组织配置，可读性和稳定性都会好很多。

有时候你发现rewrite规则没生效，先检查一件事：是否被更优先的location提前拦截了。Nginx的location匹配优先级是：

1. =精确匹配，最高优先级。
2. ^~前缀匹配，如果匹配则不再检查正则location。
3. 正则location，按书写顺序匹配，第一条命中生效。
4. 普通前缀location，取最长匹配。

如果你的请求路径命中了location = /xxx，那server层rewrite改写后的URI如果不等于/xxx，反而可能落到别的location。所以设计rewrite时，务必考虑"改完之后去哪"，否则会出现：rewrite执行了，但业务逻辑没走到预期后端。

5.3 定位rewrite问题的三板斧

我排查rewrite问题主要靠三板斧，比对着配置猜效率高得多。

第一板斧：开启Nginx调试日志。在编译Nginx时如果带了--with-debug，可以在配置里加：

error_log /var/log/nginx/debug.log debug;

然后nginx -s reload，再访问一次触发问题的URL，接着翻debug.log。里面会有非常详细的rewrite过程，比如rewritten redirect、rewritten uri、test location这些关键词，能直观看到每个正则是否命中、URI最终变成了什么。这是定位问题最底层的办法。

第二板斧：用curl观察响应头。

curl -I http://example.com/old/path

如果返回301，Location头会明确告诉你跳到了哪里。多试几轮，就能画出跳转链路。加-L参数可以让curl跟随跳转，再配合-v查看每一步的响应信息。这个方法在定位302/301循环时极高效。

第三板斧：在配置里临时加return 200 "debug info";。比如在可能命中的location里直接返回一个测试字符串，然后看哪个location生效。这种方式适合确认"Nginx到底进了哪个location"，因为很多rewrite不生效的根源其实是location匹配优先级的问题。

这三板斧配合使用，绝大多数rewrite问题半小时内能定位。我见过太多运维在配置里加注释、删规则、试来试去，最后发现是不起眼的location优先级在捣乱。与其盲目试错，不如直接看日志和响应头，把请求处理路径摸清楚。

5.4 踩坑经验速查表

我把这几年用Nginx rewrite踩过的高频坑整理成一张表，放在这里，你配置完可以对查一遍：

这张表是我每次帮人排查rewrite问题时的默认检查清单。大部分问题都能在表里找到影子，对照排查比临时翻文档高效得多。

6. 我自己在rewrite配置上的一些体感

说了这么多技术细节，最后聊几点横跨多个项目之后的个人感觉。

第一，rewrite的配置风格很重要。同一个功能，有人写成一长串复杂的正则，有人拆成两条清晰的规则，维护成本天差地别。我自己的习惯是：每一条rewrite都配一行注释，说明业务意图，不写"rewrite xxx"，而是写"用户访问旧商品详情页时301到新地址"。三个月后再看配置，你会感谢当时的自己。

第二，rewrite规则的数量要克制。Nginx的rewrite模块在每次请求时对正则表达式做匹配，规则写得越多越复杂，性能消耗越大。如果一个路径既需要rewrite又需要防盗链判断，建议合并成一条规则，或优先用location控制范围。对于极高流量的站点，甚至可以把这个逻辑前置到CDN或负载均衡层，最后源站的rewrite规则越精简越好。我个人在压测时观察到，一两条精准的rewrite对吞吐影响微乎其微，但十几条带复杂正则的rewrite叠加下来，QPS会明显下降。

第三，配置变更要留退路。rewrite的301属于永久动作，一旦用户浏览器缓存了错误跳转，恢复成本极高。所以我对生产环境的rewrite变更有个固定流程：先在测试环境完整模拟，再用302灰度验证，最后切换301并保留旧规则至少30天。这个流程看起来繁琐，但救过我好几次。

第四，Nginx的rewrite只是URL处理的一环，不要指望它能解决所有路由问题。业务上复杂的路由逻辑，更适合由后端框架或API网关处理，Nginx只做最基础的路径映射和跳转。选型时想清楚这一层，架构会更清晰。有时候我看到有人用rewrite硬刚需求，写出一大堆复杂规则，其实把目光放远一点，在后端加个路由文件反而更简单。

我在使用Nginx rewrite的这几年里，最大的体会是：它是一个"小而深"的模块。语法简单到三分钟就能学会，但执行机制、正则细节、与location的交互关系要真正吃透，需要不少实战机会。如果你能把上面这些内容理解透，再遇到手头站点的URL改造、跳转优化、伪静态配置这些问题，心里基本就有谱了。