考虑这个简单的规则来隐藏访客的一个丑陋的URL：
RewriteRule ^/CleanPage.html$ /index.php?ugly_parameter=yuck&somevar=12 [L] 这条规则似乎是在日志中产生两套“规则运行”。 首先，它运行所有规则，直到findCleanPage.html匹配。
在这一点上，应该做的，但它做了一些愚蠢的事情：它需要复杂的url，“index.php？ugly_parameter = yuck＆somevar = 12”，并开始从开始尝试匹配到另一个规则！
我怎么告诉它“index.php？ugly_parameter = yuck＆somevar = 12”是我的“最终答案”，不要浪费时间去试试看看它是否与其他东西相匹配？ 我以为这是“L”旗？
[L]参数仅表示这是在当前重写的URL上要考虑的最后一个规则，但不包括内部redirect。
我会假设你已经将RewriteRule从原来的forms中改变了一些，并且你正在试图在.htaccess文件中使用Rule–在这种情况下，你所观察到的行为是可以预期的（但是在这种情况下，Rule会读取RewriteRule ^CleanPage.html$ /index.php?ugly_parameter=yuck&somevar=12 [L]而不是前导斜杠），如http://httpd.apache.org/docs/2.2/mod/mod_rewrite .html＃rewriterule在L-flag下。
在.htaccess文件（或<Directory> -context）中使用RewriteRule时，Apache httpd必须将所得到的重写URL重新input到Apache内核中，因为在处理过程中只是简单地更改文件名 – URL的parsing已经发生了，否则httpd就不会知道在哪里查找正在使用的.htaccess文件。 重新注入URL基本上会重新启动整个请求过程 – 包括任何和所有的RewriteRules。
如果要避免这种情况，则必须在Apache httpdconfiguration文件中的<VirtualHost> -context内指定规则。 在这种情况下，规则可以被应用相当多的时间，以至于不能改变后续的处理，并且该规则将只被应用一次。
如果我做出了任何错误的假设，请将日志级别为3的RewriteLog输出作为进一步分析。