Apache RewriteRule冲突核心在于规则顺序、作用范围与路径排除不当，需从具体到泛用排列规则，显式排除静态资源，并确保mod_rewrite启用、AllowOverride All及Directory内配置到位。
Apache RewriteRule 冲突不是“写错一条规则”，而是多条规则之间互相干扰、覆盖或提前终止导致的逻辑失效。核心解决思路是：**控制匹配顺序、明确作用范围、排除干扰路径**。
规则顺序必须从具体到泛用
Apache 严格按 .htaccess 或配置文件中从上到下的顺序逐条匹配，遇到带 [L] 的规则就停止后续匹配。如果兜底规则（如 RewriteRule ^(.*)$ index.php [L]）写在前面，所有请求都会被它吃掉，后面更具体的路由（比如 ^api/v2/ 或 ^admin/login）根本没机会执行。
- 把高优先级、路径最明确的规则放在最顶部，例如：
RewriteRule ^single-portfolio/(\d+)/([\w-]+)$ single-portfolio.php?id=$1&title=$2 [L] - 中间放中等粒度的业务规则，如产品页、分类页重写
- 最后才放通用兜底规则，且必须确保目标脚本能正确解析原始 URL
静态资源和真实文件必须显式排除
常见 404 或图片不显示，往往是因为 RewriteRule 过于宽泛，把 /assets/img/logo.png 或 /css/main.css 也重写到了 PHP 脚本里。服务器返回了 HTML 内容，但浏览器期待的是图片二进制流。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 在关键规则前加条件判断：
RewriteCond %{REQUEST_FILENAME} !-f（不是真实文件）和RewriteCond %{REQUEST_FILENAME} !-d（不是真实目录） - 对已知静态资源目录做负向排除，比如用
RewriteRule ^(?!assets/|images/|js/|css/).*$ index.php [L] - 避免使用像
^((\w+)\/)+(\w.+)$这类无差别捕获的正则，它会误伤带连字符、子目录层级深的合法资源路径
环境配置必须到位，否则规则根本不运行
再精准的规则，若底层环境没启用，也等于没写。90% 的“规则不生效”问题出在这里。
- 确认
mod_rewrite已加载：检查httpd.conf中LoadModule rewrite_module modules/mod_rewrite.so未被注释 - 对应目录必须允许覆盖：
<Directory "/var/www/html"> AllowOverride All </Directory>，不能是None - 虚拟主机内需在
<Directory>块中写RewriteEngine On，不能只写在<VirtualHost>根层级 - 重启 Apache 生效：
sudo systemctl restart apache2（Debian/Ubuntu）或sudo apachectl restart（CentOS/macOS）
调试要抓关键信号，别只看页面
浏览器看到 404 或空白图，不代表规则没触发；可能已重写但 PHP 没取对原始路径，或日志里早有线索。
- 打开 Apache 错误日志（通常是
/var/log/apache2/error.log），搜索rewrite或regex相关报错 - 用
curl -I http://localhost/product/123查看响应头，确认是否发生 301/302 重定向（说明用了[R]，不是内部重写） - 在 PHP 入口脚本（如
index.php）开头加error_log(print_r($_SERVER, true), 3, '/tmp/route.log');，检查REQUEST_URI和REDIRECT_URL是否被正确传递
