apache mod_rewrite生产部署需启用模块、在directory块内设options +followsymlinks和allowoverride all（或fileinfo）、每virtualhost独立配置、路径匹配用^article/而非^/article/、规则后加[l]或[r=301,l]、前置条件排除真实文件目录、屏蔽.git等敏感路径，并用curl和错误日志验证。
Apache mod_rewrite 在生产环境部署不是加几行规则就完事，关键在于权限控制、作用范围明确、安全兜底和可验证性。配置错一处，轻则 404/500，重则路由绕过、敏感路径暴露，甚至被恶意构造 URL 触发 SSRF 或目录遍历。
必须启用模块并放开覆盖权限
mod_rewrite 默认不启用，且 Apache 2.4+ 默认禁止 .htaccess 覆盖，这是生产环境最常见的“规则不生效”原因。
- 执行 sudo a2enmod rewrite 启用模块（Ubuntu/Debian）；CentOS/RHEL 检查
/etc/httpd/conf.modules.d/00-base.conf中LoadModule rewrite_module modules/mod_rewrite.so是否已取消注释 - 在对应站点的
<directory></directory>块中，必须同时设置：Options +FollowSymLinks（多数重写依赖符号链接解析）AllowOverride All（允许 .htaccess 生效）或明确设为AllowOverride FileInfo（更安全，仅允许重写相关指令） -
不能只在
根层级写 RewriteEngine On —— 必须放在<directory></directory>内部，否则规则不生效
虚拟主机内独立配置，避免规则污染
多个站点共用一台 Apache 时，Rewrite 规则不继承、不共享。每个 VirtualHost 必须单独声明作用域，否则会出现跨站跳转、重复重定向或条件误匹配。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 路径匹配写
^article/，不是^/article/（Apache 内部路径已剥离 Host 和协议，开头斜杠会被忽略） - 每条
RewriteRule后建议加[L]（Last），防止后续规则意外介入；需要跳转时明确加[R=301,L] - 条件判断（
RewriteCond）只对紧随其后的那一条RewriteRule生效，不可复用——多条规则需各自配条件
生产级规则必须带安全兜底
直接转发所有请求到 index.php 是常见做法，但若没排除真实文件和目录，会导致 CSS、JS、图片等静态资源也被 PHP 处理，拖慢响应甚至暴露错误信息。
- 标准入口转发应包含两行前置条件：
RewriteCond %{REQUEST_FILENAME} !-f（不是真实文件）RewriteCond %{REQUEST_FILENAME} !-d（不是真实目录） - 屏蔽敏感路径，例如：
RewriteRule ^\.env - [F,L]（返回 403）RewriteRule ^(?:\.git|\.svn|\.hg|\.project) - [F,L] - 如需保留原始查询参数（如 ?utm_source=xxx），加上
[QSA]标志
上线前务必验证与日志辅助
浏览器缓存和 301 跳转会掩盖真实行为，测试必须用无缓存命令行工具，并检查错误日志定位问题。
- 用 curl -I http://your-site.com/old-path 查看响应头是否含
Location:或状态码是否正确 - 开启重写日志（临时）：
在站点配置中加入：RewriteLog "/var/log/apache2/rewrite.log"RewriteLogLevel 3
（注意：Apache 2.4+ 已弃用该方式，改用LogLevel alert rewrite:trace3） - 检查
/var/log/apache2/error.log，搜索mod_rewrite或rewrite关键字，常见报错如 “RewriteCond: No such file” 或 “Invalid command ‘RewriteEngine’” 都指向模块未启或语法错误
