什么是url重写

你点开一个链接，重写地址栏里躺着一串字符：/product.php?重写id=123&cat=shoes&color=red。丑，重写难记，重写还暴露了后台文件结构。重写另一天你看到的重写是/shoes/red/nike-air-max。清爽，重写语义清晰，重写像一张精心设计的重写门牌。这中间发生了什么？重写就是URL重写。

URL重写，重写说穿了就是重写服务器在背后把“好看”的地址翻译成“真实”的地址。用户和浏览器看到的重写是一套，服务器实际执行的重写是另一套。这个过程发生在请求到达后端代码之前，重写像门口站着个翻译官，把客人说的礼貌用语转换成厨房听得懂的黑话。

Apache的mod_rewrite模块是这门手艺的老祖宗。RewriteEngine On之后，一行RewriteRule ^shoes/([a-z]+)/([a-z0-9-]+)$ product.php?cat=$1&name=$2 [L]就把上面那个漂亮地址映射回了带问号的动态请求。Nginx的rewrite ^/shoes/(.*)$ /product.php?path=$1 last;干的是同样的活，只是语法更简洁。别被正则表达式吓到，它的核心逻辑不过三步：匹配模式、捕获片段、重组目标。

但别把URL重写想得太神。它不改变文件系统的真实结构，只是改写了HTTP请求的“表面说辞”。你访问/about-us，服务器内部可能正在执行page.php?id=about。用户感知不到这层转换，但搜索引擎能。干净的URL对SEO的友好程度，就像把名片印得整整齐齐而不是随手写在餐巾纸上。

我见过一个真实案例。某电商平台早期用item.php?item_id=184729这样的地址，后来迁移到/product/184729。迁移当天流量掉了两成——因为旧链接全失效了。他们花了三周做301重定向才逐步恢复。这事提醒你：重写规则一旦上线，就是一份长期契约。改规则前先想清楚旧链接怎么办，否则搜索引擎会用排名暴跌教做人。

有个细节容易被忽略：重写规则的处理顺序极其敏感。规则是按顺序逐条匹配的，第一条命中后是否继续往下走取决于标志位。[L]表示“这是最后一条”，[R]表示“发个重定向响应给浏览器”，[NC]忽略大小写。一个[L]漏了，可能让请求落到错误的规则里，产生一个诡异的404。调试时最好的工具就是打开服务器错误日志，看它到底把请求转到了哪。

还有种更隐蔽的场景：URL重写能隐藏技术栈。你看/login，不知道后端是PHP还是Python还是Java。这既是安全上的小屏障，也方便你日后换技术框架——只要重写规则不变，用户感知到的地址永远稳定。我见过有人把整个RESTful API都用重写包装了一层，对外全是名词性路径，内部却是乱糟糟的版本号加函数名。说实话，这在团队协作上有点坑，新人容易找不到北，但对外接口的整洁度确实无可挑剔。

最后说个反直觉的事：并非所有URL都值得重写。如果某个动态地址本来就很短，比如/?p=2，强行改成/page/2反而增加一层解析开销。重写的价值在于让重要的、常被引用的URL变得可读、可预测。那些内部用的跳转参数，保持原样就好。工具用在该用的地方，才是工具，否则就是累赘。