缓存不是越长越好

博客上线后，很多性能优化都会指向静态资源缓存。CSS、JavaScript、图片如果每次都从服务器重新下载，会浪费带宽，也会拖慢移动端首屏。但缓存不是简单地把所有内容都设成一年。缓存过长而没有版本策略，用户可能长期看到旧样式；缓存过短，又失去了优化意义。

对个人博客来说，最稳妥的思路是按资源类型分层：HTML 页面短缓存或不缓存，图片长缓存，CSS 和 JS 中等缓存并配合版本号。

先分清三类资源

第一类是 HTML 页面。首页、文章页、分类页会随着发文和评论变化，通常不建议长缓存。搜索引擎也需要看到最新内容。可以让应用正常返回，必要时只通过反向代理做很短时间的缓存。

第二类是图片。上传后的文章图片通常不会频繁修改，同一个文件名对应的内容基本稳定，可以设置较长缓存。例如 30 天或更久。前提是不要用同一个文件名反复覆盖不同图片。

第三类是 CSS 和 JS。它们会随版本更新，但更新频率低于 HTML。最好的方式是文件名或 URL 带版本标记。这样旧文件可以长缓存，新版本发布时 URL 改变，浏览器自然重新拉取。

Nginx 配置的基本形状

静态目录建议由 Nginx 直接服务，不要让每个图片请求都进入 Flask。常见配置是把 /static/ 指向项目的静态资源目录，并增加缓存头。

location /static/ {
    alias /var/www/blog/static/;
    expires 30d;
    add_header Cache-Control "public, max-age=2592000";
}

这个配置适合图片和上传文件。如果 CSS、JS 更新后用户仍看到旧样式，就需要在模板里给资源 URL 加版本参数，例如根据应用版本、构建时间或文件修改时间生成 ?v=20260604。

图片缓存要配合上传策略

图片长缓存有一个前提：上传文件名必须稳定且唯一。不要让用户上传的 cover.jpg 直接以原名保存，否则后来的文件可能覆盖前面的文件，浏览器还拿着旧缓存。更好的做法是保存时生成随机文件名，或用内容哈希作为文件名。

图片还要控制尺寸和格式。对博客来说，上传原图直接展示很浪费。服务端可以限制最大边长，并转换为 WebP 或压缩 JPEG。缓存解决重复下载，压缩解决首次下载，两者都需要。

总结

Nginx 静态缓存的关键是分类处理。HTML 保持新鲜，图片长缓存，CSS 和 JS 配合版本化 URL。只要文件命名、上传压缩和发布流程配套，个人博客可以用很简单的配置获得明显速度提升，同时不牺牲内容更新。