rewriterule的[co]标志仅设置响应cookie，不读取或校验请求cookie，故无法直接用于灰度路由决策；灰度必须依赖rewritecond配合%{http_cookie}提取并匹配已有cookie值，再通过[e]环境变量复用状态，确保安全、稳定、可维护的流量分发。
为什么 RewriteRule 的 [CO] 标志不能直接用于灰度路由决策
很多人误以为给请求加个 Cookie 就能靠它做灰度分流，但 [CO] 只负责「设置响应头中的 Set-Cookie」，它不读取、不校验、也不参与后续规则匹配。灰度发布真正依赖的是「基于已有 Cookie 做条件判断」，而不是靠 [CO] 写一个新 Cookie 就完事。
典型错误是这样写：
RewriteRule ^/api/.*$ /api-v2/ [CO=gray:1:example.com:86400:/]
这只会每次响应都塞一个 gray=1，但完全没用——因为下一次请求是否走 v2，得看有没有这个 Cookie，而这里没配 RewriteCond 去检查它。
如何用 RewriteCond + %{HTTP_COOKIE} 识别灰度用户
灰度逻辑必须从「读取 Cookie」开始，再结合正则匹配值，最后决定重写目标。关键不是写 Cookie，而是读它、信它、用它。
-
RewriteCond %{HTTP_COOKIE} gray=1：匹配任意位置含gray=1的 Cookie 字符串（注意：不区分字段边界，gray=123也会命中） - 更安全的写法：
RewriteCond %{HTTP_COOKIE} (?:^|;\s*)gray=1(?:;|$)，用非捕获组和边界断言避免子串误匹配 - 若需多值支持（如
gray=v2或gray=canary），正则改用gray=(v2|canary)，并在RewriteRule中用%1引用分组 - Cookie 值建议由前端或登录服务统一注入，Apache 不生成也不验证签名，所以务必确保上游可信
如何组合 [E] 和 %{ENV:...} 实现跨规则复用灰度状态
单条 RewriteRule 无法把 Cookie 判断结果“传递”到后续规则中；如果多个路径都要根据同一灰度状态路由，重复写 RewriteCond 易出错且难维护。这时该用环境变量中转。
示例：把灰度标识存入环境变量，后续所有规则都可直接引用
RewriteCond %{HTTP_COOKIE} (?:^|;\s*)gray=(v2|canary)(?:;|$)
RewriteRule ^ - [E=GRAY_VERSION:%1]
<p>RewriteCond %{ENV:GRAY_VERSION} =v2
RewriteRule ^/api/(.*)$ /api-v2/$1 [L]</p><p>RewriteCond %{ENV:GRAY_VERSION} =canary
RewriteRule ^/api/(.*)$ /api-canary/$1 [L]</p>
注意：[E] 必须配合 ^ -（即空替换）才能只设变量不改 URL；[L] 防止后续规则干扰；=v2 是字符串精确匹配语法，比正则更高效。
Cookie 域名、路径与 HTTPS 安全标志的实际影响
灰度 Cookie 若配置不当，会导致浏览器不携带、Apache 读不到，整个链路就断了。这不是规则写错，而是部署细节失效。
-
[CO]设置 Cookie 时，域名必须匹配请求 Host，否则浏览器拒绝存储；例如请求是app.example.com，却设CO=gray:1:example.com，多数现代浏览器会忽略 - 路径参数（第 4 个）要覆盖所有需灰度的入口，比如设为
/而非/api/，否则静态资源请求带不上 Cookie - 生产环境必须加
Secure和HttpOnly标志，对应[CO]的第 5、6 位：如[CO=gray:v2:app.example.com:86400:/:Secure:HttpOnly] - 若后端服务依赖 Cookie 值做鉴权或埋点，
HttpOnly会阻止 JS 读取——这反而是好事，避免前端篡改灰度标识
灰度发布最易被忽略的，其实是 Cookie 的生命周期管理：没有自动过期机制，也没有服务端校验逻辑，一旦用户长期不清理 Cookie，就会永远卡在旧版本里。上线灰度策略前，得先想好怎么退、怎么清、谁来触发。
