apache mod_rewrite性能损耗源于规则数量、正则复杂度和执行阶段：规则越多越耗cpu，复杂正则易触发回溯爆炸，.htaccess每次请求重复解析成瓶颈；应精简规则、避免模糊匹配、禁用.htaccess并移至主配置、高频路径前置加[l]终止。
Apache 的 mod_rewrite 本身不“慢”，但它的性能损耗来自执行方式和配置习惯，不是模块本身有缺陷，而是用法不当会放大开销。关键看三点：规则数量、正则复杂度、执行阶段。
重写规则越多，CPU 越忙
每条 RewriteRule 都要被 Apache 按顺序加载、编译（正则）、匹配；每条 RewriteCond 还要额外做字符串比对或环境变量取值。50 条规则 ≠ 50 倍耗时，但若高频路径（如 /api/ 或 /static/）排在后面，前面几十条都会白跑一遍。实测显示：含 60+ 条规则的 .htaccess 在高并发下，单请求 rewrite 开销可占总处理时间 15%～30%。
正则越复杂，解析越拖累^/post/([0-9]+)/?$ 比 /post/ 多出编译+捕获+回溯成本；用 .*、(.*)、嵌套括号或 ^.*\.php$ 这类模糊模式，容易触发 PCRE 回溯爆炸——尤其当 URL 异常长或含特殊字符时，可能卡住线程甚至引发 500。不带 [L] 的规则还会让匹配继续，等于重复执行多轮正则。
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
.htaccess 是隐形性能杀手
它在每次请求时都从根目录逐层向上查找、读取、解析，哪怕只有一行 RewriteEngine On。禁用 AllowOverride 后移至主配置，规则只加载一次进内存；而 .htaccess 每次都要磁盘 I/O + 解析，对 SSD 都是明显瓶颈，流量稍大就可观测到 stat() 系统调用飙升。
怎么量化？用 curl + 日志交叉验证
-
curl -I https://site.com/path看响应头是否干净（避免多重跳转） - 开启
RewriteLog（Apache 2.2）或LogLevel alert rewrite:trace3（2.4+），抓典型请求日志，看 rewrite 轮次、匹配次数、耗时字段 -
ab -n 1000 -c 100对比开启/关闭 rewrite 的 TPS 和平均延迟变化
真正影响性能的，从来不是“用了 mod_rewrite”，而是“在哪用、怎么写、有没有终止”。
