url 重写模块工具

打开浏览器开发者工具，写模切到 Network 面板，块工刷新页面。写模你会看到一堆请求，块工其中不少 URL 长得像外星文——带一长串参数、写模问号、块工等号、写模百分号编码。块工这些 URL 对搜索引擎不友好，写模对用户更不友好。块工URL 重写模块工具就是写模用来解决这个问题的。

它的块工核心工作只有一件事：把丑的、动态的写模、带参数的块工 URL，转换成干净的写模、语义化的、静态化的 URL。比如把 /product.php?id=123&category=shoes 变成 /shoes/123。用户看着舒服，搜索引擎爬虫也更容易抓取和收录。

它到底在哪个环节干活

URL 重写发生在 Web 服务器层面，不是浏览器端，也不是应用代码里。Apache 有 mod_rewrite，Nginx 有 rewrite 指令，IIS 也有自己的 URL Rewrite 模块。它们拦截进来的 HTTP 请求，按照预先写好的规则，把请求的 URL 映射到实际能处理的脚本或资源上。

拿 Apache 举例。你会在网站根目录放一个 .htaccess 文件，里面写 RewriteRule。规则写对了，用户访问 /about，服务器内部实际执行的是 /about.php，但地址栏不会变。这叫内部重写。还有一种叫外部重定向，服务器返回 301 或 302，浏览器地址栏会跳转。两者用途不同，别搞混。

规则写错，后果很直接

我见过一个电商站，RewriteRule 里用了 [R=301] 却忘了排除后台路径 /admin。结果运营人员一登录后台就被重定向到首页，折腾了半天以为是权限问题。URL 重写规则是按顺序匹配的，一旦命中就停止。顺序错了，或者正则写得太宽，很容易误伤。

另一个常见坑是循环重写。规则 A 把 /old 重写到 /new，规则 B 又把 /new 重写回 /old，服务器直接 500。调试时可以在规则里加 [L] 标志告诉服务器“这条匹配后别再往下走了”，但根本解决办法还是理清映射逻辑。

Nginx 和 Apache 的写法差异

Nginx 的 rewrite 写在 server 或 location 块里，语法更紧凑。比如：

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

Apache 的对应写法是：

RewriteRule ^article/([0-9]+)$ /article.php?id=$1 [L]

Nginx 用 last 或 break 控制流程，Apache 用 [L]。功能类似，但 Nginx 在处理大量规则时性能通常更好，因为它在配置加载阶段就编译了正则。Apache 的 .htaccess 是每次请求都读一遍，流量大了会拖慢响应。

伪静态只是表象

很多人把 URL 重写叫“伪静态”，好像只是为了骗搜索引擎。其实它更大的价值在于解耦。前端展示的 URL 结构可以独立于后端程序的实际文件路径和参数格式。哪天你把 article.php 换成 Laravel 路由 /articles/{ id}，只要重写规则改一下，外部链接完全不用动。

做网站迁移时这个优势特别明显。旧站是 /show.php?type=news&id=456，新站是 /news/456。写一条重写规则，所有旧链接 301 到新地址，SEO 权重不会丢，用户收藏夹也不会失效。

工具本身不复杂，难的是想清楚 URL 设计

URL 重写模块工具提供的是一套正则匹配和替换机制。学语法半天就够了。真正花时间的是规划 URL 结构：分类怎么分层、参数怎么省略、大小写是否敏感、结尾要不要斜杠。这些决策一旦定下来，后期改动的成本很高。

我的建议是，新项目上线前先把 URL 规则写进配置文件，别等到页面都开发完了再补。规则和路由一起设计，后面省事得多。