documentroot 仅作为稳定版兜底目录，灰度流量须通过 rewriterule 提前代理至灰度后端，严禁混放灰度代码；需确保 fallback 可靠、响应头重写正确、目录权限与模块配置完备。
DocumentRoot 本身不参与灰度逻辑，但它必须与灰度策略协同部署——关键在于“灰度流量不走 DocumentRoot 默认路径”，而是通过 Location 或 ProxyPass 规则提前拦截并代理到灰度后端，让 DocumentRoot 仅作为稳定版本的兜底服务目录。
灰度发布时 DocumentRoot 的定位要明确
它应始终指向稳定版应用的 public 目录（如 /var/www/stable/public），且该目录只响应未命中灰度规则的请求。不能把灰度代码混放其中，否则会破坏环境隔离、增加误发布风险。
- ✅ 正确示例：
DocumentRoot "/var/www/stable/public"—— 稳定版唯一入口 - ❌ 错误做法：把 canary 分支也放进同一 DocumentRoot 下，再靠 .htaccess 切换 —— 权限混乱、难以审计、易引发 403/500
- ⚠️ 注意：DocumentRoot 对应的
<directory></directory>块仍需保留Require all granted，确保稳定路径可访问
灰度流量必须绕过 DocumentRoot，走代理路由
Apache 不支持基于请求头直接切换 DocumentRoot，所以灰度必须用 mod_proxy + mod_rewrite 在请求进入文件系统前就完成分流：
- 启用必要模块：
proxy、proxy_http、rewrite - 在虚拟主机或主配置中，把灰度规则写在所有
ProxyPass之前：
RewriteEngine On
RewriteCond %{HTTP:X-Release} ^canary$ [NC]
RewriteRule ^/(.*)$ http://canary-backend:8000/ [P,L]
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 匹配成功后，请求直接交给后端处理，完全跳过 DocumentRoot 文件查找流程
- 未匹配则自然回落到 DocumentRoot 提供的稳定服务
配合 Include 实现灰度 IP 白名单隔离（可选增强）
若灰度还需限制访问来源（如仅允许测试人员 IP 访问灰度接口），可在对应 <location></location> 块中用 Include 引入独立白名单文件，不污染主配置：
Include /etc/apache2/whitelist-gray.conf
Require ip 172.16.0.0/12
- 该 Location 可与灰度代理共存（如代理到
/api/v2/路径），形成“先鉴权、再代理”的双保险 - 白名单文件内容只需
Require ip规则，无需嵌套块或额外指令
验证要点：确保 fallback 可靠
灰度失效时，用户必须无感降级到稳定版。检查以下三项是否到位：
- 灰度后端宕机时，
[P]规则失败是否触发默认 DocumentRoot？可通过临时停掉 canary-backend 并 curl 测试 - 所有
ProxyPassReverse是否正确重写响应头（特别是Set-Cookie和Location） - DocumentRoot 目录权限是否严格（
Require all granted）、PHP 模块是否已加载、AddType是否配置
