FastCGI缓存需显式包含$http_authorization并哈希化以实现认证隔离：配置fastcgi_cache_key含$sha1($http_authorization)，配合fastcgi_cache_bypass $http_authorization，并确保后端响应设置Cache-Control: private防止敏感数据泄露。
FastCGI 缓存默认不区分带 Authorization 请求头的请求，导致不同用户（如 A 用户登录后访问 /api/profile）可能命中 B 用户缓存的内容，造成权限越界。要实现基于认证头的权限隔离，核心是让 fastcgi_cache_key 显式包含 $http_authorization，并确保缓存键对未认证与已认证请求真正分离。
关键：在 cache_key 中纳入 Authorization 头
默认 fastcgi_cache_key 通常只含 URI、Host 和部分参数（如 $scheme$request_method$host$request_uri），而 $http_authorization 是空或未参与计算。必须显式加入：
- 使用
$http_authorization变量（Nginx 自动将请求头Authorization转为小写加下划线的变量名） - 注意该变量值含空格和特殊字符（如
Bearer eyJhbG...），需用md5或sha1哈希避免缓存键过长或非法字符问题 - 示例配置：
# 更推荐（哈希化，稳定且安全）：
fastcgi_cache_key "$scheme$request_method$host$request_uri$sha1($http_authorization)";
配合 proxy_cache_bypass / fastcgi_cache_bypass 控制缓存绕过逻辑
仅改 key 不够——还需防止未认证请求（如游客）与已认证请求共用同一缓存条目。应主动绕过缓存未认证流量，或按认证状态分流：
- 设置
fastcgi_cache_bypass $http_authorization;：当存在 Authorization 头时，不读缓存（强制回源），再配合 cache_key 包含该头，确保已认证请求各自独立缓存 - 更精细做法：用 map 定义缓存策略变量
"" "_anonymous";
~^Bearer.* "_bearer";
~^Basic.* "_basic";
}
fastcgi_cache_key "$scheme$request_method$host$request_uri$cache_key_suffix$sha1($http_authorization)";
注意 Authorization 头的传递与清理
Nginx 默认不将原始请求头透传给 FastCGI 后端，但 fastcgi_cache_key 依赖的是客户端请求头，无需透传。不过需确认：
- 确保没有在 server 或 location 块中用
fastcgi_hide_header Authorization;或类似指令意外清空该变量 - 若使用了
auth_request模块做前置鉴权，注意它会剥离原始 Authorization 头；此时应改用$upstream_http_authorization或在 auth_request 子请求中保留原始头供父请求使用（较复杂，建议优先在主请求中直接读取） - 测试是否生效：用 curl 发送不同 token 的请求，观察 Nginx 日志中的
$upstream_cache_status（MISS/HIT/DISABLED）及响应头X-Cache
补充：避免敏感数据被缓存
即使 key 区分了用户，仍需防止用户私有响应（如个人资料、订单列表）落入共享缓存：
- 后端应用应在响应头中明确设置
Cache-Control: private, no-store或no-cache，Nginx 尊重这些指令（需开启fastcgi_cache_valid any 0s;并配置fastcgi_cache_use_stale等行为） - 对确需缓存的认证后接口（如用户角色配置、菜单权限等只读静态资源），才启用 cache，且务必校验响应头是否含
Vary: Authorization（虽 FastCGI 缓存不依赖 Vary，但利于调试和兼容性） - 定期清理缓存时，避免用
fastcgi_cache_purge无差别清除，应支持按用户 token 哈希前缀 purge（需自定义 purge 规则或结合 Lua）
