nginx处理静态资源的理静能力，比多数人想象的态资要强得多。我见过不少团队，理静明明用nginx做反向代理，态资却让应用服务器直接扛着图片和CSS文件，理静结果Tomcat或Node进程CPU飙到80%，态资而nginx空闲得像在休假。理静这纯粹是态资配置没到位。

核心就一句话：能交给nginx的理静，别让后端碰。态资静态文件的理静读取、缓存、态资压缩、理静过期策略，态资nginx全都能干，理静而且干得比应用服务器漂亮。拿我调过的一个电商站点来说，商品图、JS打包文件占了总请求量的70%以上。原先这些请求打到Java应用上，每次都要走一遍Servlet过滤器链，光解析HTTP头就浪费不少时间。改成nginx直接alias指向磁盘目录后，响应时间从120ms降到8ms，压测时nginx轻松吃掉每秒5000个请求，后端负载直接清零。

配置其实不复杂。一个典型的location块就能解决大部分问题：

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {  root /data/static; expires 7d; add_header Cache-Control "public, immutable"; access_log off; gzip_static on; gzip_types text/css application/javascript image/svg+xml; try_files $uri =404; } 

这里有两个细节容易踩坑。第一，root和alias的区别。如果location匹配的是URI路径，比如/static/，那用alias /data/files/能去掉static这一层目录；但如果你用正则匹配文件扩展名，就得用root，让nginx把完整URI拼到root后面。搞混了，文件永远404。第二，gzip_static on这个指令，它让nginx直接读取预压缩的.gz文件，而不是每次请求都现压缩。你得提前用gzip命令生成对应文件，但换来的是CPU零消耗，吞吐量翻倍。

另一个常见误区是缓存策略一刀切。很多配置直接expires max，结果用户改了头像，浏览器还显示旧图。合理的做法是按文件类型区分：带hash的打包文件（比如app.8f3k2.js）可以设一年，因为文件名变了URL就变，不存在更新问题；但用户上传的图片、普通商品图，设个7天或24小时就够了，配合ETag做弱验证，既减少请求，又不会让用户看到过期内容。

还要注意一个隐蔽的性能杀手——sendfile。nginx默认开启，但有些人在location里覆盖成了off，导致文件读取走用户态缓冲区拷贝，大文件下载时CPU占用飙升。除非你依赖X-Accel-Redirect做权限控制，否则别关它。顺带提一句，如果你用nginx处理视频流或大PDF，记得加aio on和directio 4m，绕过页缓存直接读磁盘，避免大文件把内存挤爆。

最后说个真实案例。我帮一个SaaS平台排查过慢请求，发现他们所有静态资源都走了HTTPS反向代理到Node，再让Node去读S3。每次请求要经过两次网络往返，延迟自然高。后来改成nginx直接通过proxy_pass到S3的CDN域名，但用proxy_cache在本地落一层缓存，命中率能到90%以上。配置里加个proxy_cache_valid 200 1h;，热点文件就不用反复回源了。改动不到十行，首屏加载时间从3.2秒降到1.1秒。

别把nginx当成简单的流量转发器。它本身就是为高并发静态内容而生的工具，用好这几个指令，比加服务器硬件划算得多。你去看那些性能调优的帖子，绕来绕去最后都会回到nginx的静态文件处理上——这玩意儿值得你花半小时把配置文档翻一遍。