Nginx 动静分离：root 路径、浏览器缓存与发布策略

系统采用 Nginx 转发请求、Jetty 运行 Java 应用时，可以让公开静态资源直接由 Nginx 返回，减少应用服务器处理这类请求的工作。是否改善整体性能，还要通过请求量、延迟与资源占用来判断。

路径映射先讲清楚

假设 URL /assets/app.css 对应服务器文件 /srv/blog/assets/app.css，可以在已有 server 块中配置：

location /assets/ {
    root /srv/blog;
    try_files $uri =404;
    expires 1h;
}

root 将完整 URI 拼接到目录后，所以这里不是 root /srv/blog/assets。alias 的替换规则不同，不能只改指令名就认为等价。只把允许公开的文件放进静态目录，不要通过后缀匹配误将需要权限验证的业务附件暴露出去。

配置修改后先执行 nginx -t，通过后再按部署方式 reload。生产验证不需要为了测试而关闭 Jetty，可以在隔离环境确认静态请求不会到达后端，并检查访问日志、Content-Type、404 与缓存头。

浏览器已有资源且缓存仍新鲜时，可以直接使用本地副本而不发请求。需要再验证时，可能携带 If-Modified-Since 或 If-None-Match；服务器确认未变化后返回 304，浏览器继续使用已有正文。

因此 304 仍有一次网络往返，不等于“没有请求”，也不能仅凭出现 304 就证明整体性能优化成功。动态响应同样可以按业务语义设置缓存；是否能缓存由响应头和数据属性决定，而不是只看它是否来自 Java 程序。

示例的一小时只是演示。文件名带内容指纹的资源可以采用更长缓存；固定文件名如果长时间缓存，发布后可能继续读到旧 JS/CSS。HTML 入口与资源应采用匹配的更新策略，验证页面引用与文件发布顺序。

最后比较变更前后的静态请求后端命中量、延迟、带宽和错误率。如果瓶颈在数据库或业务计算，动静分离只能减少部分开销，不能替代对实际慢链路的定位。