使用 alias 后浏览器本地缓存失效，根本原因在于其改变了资源路径结构或响应头行为：一是 location 匹配优先级错位导致缓存指令未生效；二是 alias 不支持正则 location 且路径拼接错误引发 404；三是文件路径变更使 etag 或 last-modified 频繁变动；四是 https 混合内容被拦截；五是 root 与 alias 混用造成路径解析异常。
使用 alias 后浏览器本地缓存失效，通常不是 alias 本身导致的，而是它改变了资源的实际路径结构或响应头行为，间接干扰了缓存逻辑。核心问题在于：Nginx 对不同 location 匹配方式的处理差异，会改变 expires、Cache-Control 等缓存指令是否生效，以及是否触发了意外的重定向或 404。
location 匹配优先级错位，缓存指令未被应用
alias 必须配合精确匹配的 location 使用，否则容易被更高优先级规则覆盖：
- 若你写了
location /static/ { alias /var/www/assets/; }，但同时存在一个更靠前的location ^~ /static/或location /块，并在里面设置了add_header Cache-Control "no-cache"，那么所有子路径（包括/static/js/app.js）都会继承这个 header，强制禁用缓存 -
alias不支持正则匹配的 location 中直接使用（如location ~ \.js$），否则可能因路径拼接错误返回 404 —— 浏览器收到 404 不会缓存，且后续重试时可能绕过本应生效的缓存策略
文件路径变更导致 ETag 或 Last-Modified 失效
alias 将请求路径映射到另一个物理目录，如果该目录下文件的修改时间（mtime）或 inode 信息与原路径不一致，Nginx 默认生成的 ETag 或 Last-Modified 值就会变化：
- 例如，原来
/static/app.js指向/app/dist/app.js（有稳定 mtime），改用alias指向/tmp/build/app.js（每次构建新建文件，mtime 总是当前时间），会导致每次响应的Last-Modified都不同 - 浏览器在协商缓存（
no-cache或max-age=0场景）中依赖这些头做比对，值频繁变动 → 总是返回 200 而非 304 → 表现为“缓存不命中”
HTTPS 混合内容或协议降级引发加载拦截
当 alias 指向的目录包含未配置 HTTPS 的静态资源（比如硬编码 http:// 的图片链接），或 Nginx 未统一处理 $scheme，会导致：
- 主页面是 HTTPS，但通过
alias服务的资源实际由 HTTP 提供 → 浏览器标记为混合内容 → 直接阻止加载，不走任何缓存流程 - 部分浏览器对混合内容资源即使允许加载，也会忽略其缓存头，或强制重新拉取
root 和 alias 混用造成路径解析异常
常见误操作是在同一 location 中既写 root 又写 alias，或在 alias 后遗漏末尾斜杠：
-
alias /var/www/static;（缺/）→ 请求/css/main.css会被映射成/var/www/staticcss/main.css（路径拼错）→ 返回 404 → 缓存自然失效 -
root是“追加路径”，alias是“替换路径”，二者语义冲突；混用时 Nginx 以最后生效的为准，容易掩盖真实路径问题
排查时先用 curl -I 检查资源响应头是否含 Cache-Control 和 Expires，再确认 ETag 是否稳定、状态码是否为 200/304，最后核对 location 块的顺序和匹配逻辑。不复杂但容易忽略。
