apache mod_rewrite生产环境避坑核心是确保配置链完整、权限精准、日志可查、规则带保护条件：必须验证模块真实加载、allowoverride all配合require all granted、rewritecond排除静态资源、用curl和trace3日志调试、优先将规则写入virtualhost而非.htaccess。
Apache mod_rewrite 生产环境避坑指南，核心不是学正则怎么写，而是确保规则稳、准、可查、不伤业务。很多线上故障不是规则写错了，而是配置链断了、权限没开、日志没开、缓存干扰了测试——这些细节决定你能不能在凌晨三点快速定位问题。
确认 mod_rewrite 模块真正在运行
光看配置文件里有 LoadModule rewrite_module 不够，得验证它实际加载了：
- Ubuntu/Debian：
sudo apachectl -M | grep rewrite→ 输出含rewrite_module (shared)才算成功 - CentOS/RHEL：
sudo httpd -M | grep rewrite，若无输出，需编辑/etc/httpd/conf/httpd.conf取消#LoadModule rewrite_module modules/mod_rewrite.so的注释，再重启服务 - 注意：模块启用后必须重启 Apache，仅重载（reload）可能不生效
AllowOverride 必须设为 All，且不能孤立存在.htaccess 里的规则要起作用，得满足两个条件：
-
<directory></directory>块中明确设置AllowOverride All（不是None或FileInfo） - 同时要有
Require all granted（Apache 2.4+ 必需，否则即使匹配也会返回 403） - 若用虚拟主机，这段配置必须写在对应
<virtualhost></virtualhost>内的<directory></directory>中，不能只写在主配置里却忘了指定路径
重写规则要带关键保护条件，避免误伤静态资源
直接写 RewriteRule ^(.*)$ index.php [L] 很危险——它会把 style.css、logo.png 也转给 PHP 处理，导致 500 或空白响应。正确做法是加两行判断：
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [L]
意思是：只有当请求的路径不是真实存在的文件（!-f）且不是真实存在的目录（!-d）时，才交给 index.php。这样 CSS、JS、图片等静态资源照常由 Apache 直接返回。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
调试不能靠浏览器刷新，得用 curl + 日志双验证
- 浏览器缓存 301 重定向、HTTPS 强制跳转等行为，会导致测试失真。每次改规则，先用
curl -I http://yoursite.com/test-path查状态码和响应头 - 开启重写日志（Apache 2.4）：在虚拟主机或主配置中加
LogLevel alert rewrite:trace3，然后查error_log，能看到每条规则是否匹配、是否被跳过、为什么终止 - 日志级别设太高（如
trace8）会影响性能，生产环境建议临时设为trace3，验证完调回warn或error
生产环境慎用 .htaccess，优先写进 VirtualHost.htaccess 每次请求都要逐层向上查找、解析，有性能损耗，也容易因权限或路径错误失效。更稳妥的做法是：
- 把
.htaccess里的规则（如 ThinkPHP 或 FastAdmin 提供的）直接挪到<virtualhost></virtualhost>配置块里 - 包裹在
<ifmodule mod_rewrite.c></ifmodule>中，避免模块未启用时报错 -
DocumentRoot必须指向public/目录（ThinkPHP 6+、Laravel 等现代框架强制要求），否则敏感配置文件可能被直接下载
不复杂但容易忽略
