我正在处理一个pipe理很多重写规则的主pipe团队。 您对网站当前pipe理的规则数量有什么经验？
我可以看到几十个（如果不是更多的话）随着网站的增长和合同而出现，并且需要设定这样的预期，这不是不合常规。
谢谢
他们是否关心pipe理许多规则的后勤或performance？
在前一种情况下，如果像Alex一样，大多数规则实际上来自内容移动和营销活动等事情，那么考虑将由数据库生成的HashMap组合起来，由CMS或CRUD工具pipe理。 他们可以由您的内容人员进行testing，然后在您的服务器团队中尽可能less地投入生产。
如果问题出在性能上，那么这就是一个“string多长时间”的问题，但是我确实在网站上使用了几百个重写规则来支持内容迁移等对响应没有可衡量影响的内容次服务器。
您可以考虑使用http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritemap ，这将允许从散列文件读取单个规则。
我们最近有这方面的实际经验。 看到我的答案在这里： https : //stackoverflow.com/questions/1364673/apache-redirects-rewrite-maximum/18120886#18120886
我最近也有同样的问题。 由于我没有find实际的答案，我们实施了一个htaccess 6规则，其中3个有20万个条件。
这意味着一个大小为150 MB的htaccess文件。 实际上，在没有人使用这个特定的网站的情况下，即使页面加载时间在几秒钟内也不错。 然而第二天，我们的整个服务器被攻击，负载远高于400.（机器是8核心，16 GB RAM，SAS RAID5，所以通常没有问题的资源）我build议，如果你需要执行这样的事情。 devise你的规则，所以他们不需要条件，并把它们放在一个dbm重写映射。 这很容易解决我们的性能问题。
http://httpd.apache.org/docs/current/rewrite/rewritemap.html#dbm
很明显，每个人都将有一个明显不同的规则数量来pipe理取决于个人的情况。 我猜想几十个规则并不less见。 我们通常使用重写来处理内容移动，技术变化等事情。 我们的营销部门不断向我们提供search引擎优化请求，例如我们通常使用重新编写的过期内容。 最后，我们还要处理一些营销活动，例如打印指定不存在的URL的营销活动，所以我们通过添加一个重写小节来使其有效。
作为比较，在我的组织中，在我们的生产环境中，我们有140个重写文件，跨越了19个子域。