解决.htaccess中RewriteCond问号(?)转义导致的重定向失效问题

嘿，我太懂你这种抓耳挠腮的感觉了——Apache的Rewrite规则里，问号的处理确实容易踩坑，尤其是涉及到?page=这种查询参数的时候。咱们拆解一下问题，一步步搞定：

核心误区：问号是URL的分隔符，默认不包含在REQUEST_URI里 #

首先要明确：URL里的?是请求路径和查询字符串的分隔符。当你用RewriteCond %{REQUEST_URI} ...的时候，匹配的是?前面的路径部分，根本碰不到后面的page=参数。这也是为什么你直接写?page=会失效的核心原因。

正确姿势1：用%{QUERY_STRING}匹配查询参数 #

如果你的目标是匹配包含page=的查询参数，直接针对查询字符串变量写规则就行，完全不需要处理问号：

# 匹配查询字符串开头就是page=，或者中间包含&page=的情况
RewriteCond %{QUERY_STRING} (^|&)page= [NC]

• (^|&)确保匹配的是独立的page参数，不会误匹配类似xxpage=123的情况
• [NC]是忽略大小写，可选，根据你的需求调整

举个完整的重定向例子，比如把所有带page=参数的请求永久重定向到新页面：

RewriteEngine On
# 匹配包含page参数的查询字符串
RewriteCond %{QUERY_STRING} (^|&)page= [NC]
# 重定向到/new-page，末尾的?是为了清除原查询字符串
RewriteRule ^(.*)$ /new-page? [R=301,L]

正确姿势2：如果必须在路径里匹配?（罕见场景） #

如果你的URL里真的把?作为路径的一部分（比如example.com/foo?page=bar这种非标准格式），那你需要在正则里转义问号——因为?在正则表达式里是特殊字符（表示匹配0或1次前面的元素），所以要用\?来转义：

# 匹配请求路径中包含?page=的情况
RewriteCond %{REQUEST_URI} \?page=

调试小技巧 #

如果还是不确定规则是否生效，可以开启Apache的Rewrite日志来排查：

# 在Apache配置里添加（注意不要在生产环境长期开启，会占日志空间）
LogLevel rewrite:trace3

查看日志就能清楚看到每个请求的匹配过程，快速定位问题。

内容的提问来源于stack exchange，提问作者casusbelli