个性化缓存需提取、归一化、隔离cookie值：用map清洗并哈希敏感字段，未登录用户统一为“anon”；按业务粒度组合key，禁用裸cookie；用proxy_cache_bypass控制绕过，优先采用后端注入的可信头如$http_authorization。
直接用 $cookie_ 变量拼进缓存键，看似简单，实则高危——它极易引发缓存爆炸或用户数据串线。真正可行的个性化缓存，核心不是“读取 cookie”，而是“提取 + 归一化 + 隔离”。
别裸用 $cookie_xxx，先做归一化映射
原始 cookie 值千差万别（如 token=abc123xyz、token="def456"），直接塞进 key 会导致同一用户多次请求生成不同 key，命中率归零。应通过 map 指令清洗并收敛：
- 用正则提取关键字段，忽略引号、空格等干扰格式
- 对敏感值（如 token、uid）做哈希处理，避免明文暴露且压缩长度
- 未登录用户统一映射为固定值（如
"anon"），确保游客缓存可复用
示例：
http {
map $http_cookie $user_id_hash {
~*uid=(?:["']?)(\d+)(?:["']?) md5($1);
default "anon";
}
}
按业务维度组合缓存键，不堆砌变量
个性化 ≠ 每个用户一个 key。要结合接口语义决定隔离粒度：
- 用户资料页（/api/user/profile）：必须含
$user_id_hash，保证 A 看不到 B 的数据 - 首页 Banner（/）：只需区分
$cookie_region或设备类型，用$cache_device即可 - 静态资源（/logo.png）：完全不应受 cookie 影响，key 中剔除所有用户标识
推荐写法：
proxy_cache_key "$scheme$request_method$host$uri|$user_id_hash|$cache_device";
用 proxy_cache_bypass 控制绕过，而非让 cookie 参与 key
调试、灰度、开发模式等场景，不该靠改缓存键来实现，而应让 cookie 充当“开关”：
-
proxy_cache_bypass $cookie_dev_mode $arg_debug;—— 有该 cookie 就不查缓存 -
proxy_no_cache $cookie_dev_mode $arg_debug;—— 有该 cookie 就不存缓存 - 此时
$cookie_dev_mode不参与 key 构建，彻底规避串线风险
优先选用更可信的身份信号替代 cookie
前端 cookie 易被篡改、注入、丢失。更稳的方式是依赖后端注入的可信头：
-
$http_authorization：JWT 或 Basic Auth token，经后端校验后透传 -
$http_x_user_role：由后端写入的权限角色，比前端 cookie 更易审计 -
$http_x_forwarded_user：在可信网关层统一注入的用户标识
这些变量天然具备身份唯一性，且不受浏览器第三方脚本干扰，是构建安全缓存键的更好起点。
