核心是确保全链路不发生意外解码或归一化：用$request_uri构建缓存键，关闭merge_slashes和ignore_invalid_headers，location前缀匹配+proxy_pass不带尾缀以透传原始编码，再通过debug日志和X-Cache头验证。
在 Nginx 缓存配置中“完美保留原始客户端请求中的特殊转义字符与编码”，核心不是让缓存“不处理编码”，而是确保整个链路（接收 → 匹配 → 缓存键生成 → 转发 → 响应）不发生意外解码、重编码或路径归一化，从而让后端收到的请求 URI 与客户端发出的一致，缓存也能按真实语义命中。
缓存键必须基于原始编码的 URI 构建
Nginx 的 proxy_cache_key 默认使用 $scheme$proxy_host$uri$is_args$args，其中 $uri 是已解码后的路径（如 /file%2Bname.txt → /file+name.txt），这会导致：
- 含
%2B（+）和%2F（/）等编码的请求被错误归并（/a%2Fb和/a/b可能共用一个缓存项） - 后端实际收到解码后路径，但缓存却按解码后 key 存储，造成前后端语义错位
✅ 正确做法：改用 $request_uri —— 它保留原始未解码的完整请求行 URI（包括 query string）：
proxy_cache_key "$scheme://$host$request_uri";
注意：$request_uri 包含开头斜杠和完整 query，无需额外拼接；若需排除某些 query 参数（如跟踪用的 utm_*），可用 map 预处理，但不要对值做 decode/encode 操作。
禁用影响编码一致性的默认行为
以下配置需放在 http 或 server 块顶层，避免缓存前路径被意外修改：
-
merge_slashes off;：防止//或%2F%2F被压缩成单个/，破坏路径结构 -
ignore_invalid_headers off;：允许含%的自定义 header（如X-Original-Path: /api/v1%2Fuser）通过，避免被直接丢弃 -
underscores_in_headers on;（如有下划线 header）：配合前端传递编码信息时更稳妥
这些设置不针对缓存模块本身，但决定了进入缓存逻辑前的请求“长相”是否可信。
location 匹配与 proxy_pass 必须保持编码透传
缓存生效的前提是请求能正确路由到 cache-enabled location。常见错误是 location 使用正则匹配时，隐式依赖解码后的 $uri，而实际请求含未解码字符：
- ❌ 错误示例：
location ~ ^/static/.*\.js$—— 若请求为/static/file[v1].js（即/static/file[v1].js），解码后匹配成功，但$uri已变，proxy_pass 若拼接不当会丢失原始编码 - ✅ 推荐方式：用前缀匹配 + 显式透传
location /static/ {
proxy_cache my_cache;
proxy_pass http://backend; # 不带尾随 /，Nginx 自动透传原始 /static/xxx[v1].js
}这样既避免正则元字符干扰，又确保 proxy_pass 不做路径重写，原始编码完整抵达后端和缓存系统。
验证缓存是否真正按原始编码工作
最直接的方式是开启 debug 日志或检查缓存目录文件名：
- 启用
error_log /path/to/error.log debug;，搜索cache key:行，确认输出的是/api/search%3Fq%3Dtest%2Bvalue而非/api/search?q=test+value - 查看
proxy_cache_path对应目录下的缓存文件，其 hash 名称应反映原始编码（可通过nginx -t后手动触发请求并观察） - 用 curl 发送含
%2F、%2B、%E4%B8%AD的请求，两次调用对比响应时间与X-Cache: HIT头
如果第二次响应快且带 HIT，且后端 access log 中路径与原始请求完全一致，说明编码从始至终未被破坏。
