启用静态文件缓存即自动在Nginx配置中插入expires指令，生成Cache-Control: max-age=2592000和Expires响应头，由Nginx直接输出、优先级高于PHP header()，覆盖.js/.css/.png等常见静态后缀，不依赖PHP、不占内存、无需重启即可生效；30天有效期适配现代前端hash文件名机制，避免CDN因max-age过短导致缓存失效。
宝塔里「启用静态文件缓存」到底干了什么
它不是开个开关就完事，而是自动在 Nginx 配置里插入 expires 指令，生成标准的 Cache-Control: max-age=2592000 和 Expires 响应头。这俩头是浏览器识别缓存有效期的核心依据，不是装饰品。
关键点在于：这个操作绕过了 PHP 或其他后端逻辑，直接由 Nginx 在响应发出前写入，所以优先级高于大多数脚本里用 header() 输出的缓存控制指令。
- 生效范围默认覆盖所有常见静态后缀：
.js、.css、.png、.jpg、.woff2等 - 不依赖 PHP 进程，不占内存，也不触发 fastcgi_cache 的复杂淘汰逻辑
- 修改后无需重启 Nginx，保存即刻写入配置并重载
为什么选「30 天」而不是「7 天」
现代前端构建工具（如 Webpack、Vite）默认给静态资源文件名注入 hash，比如 main.a1b2c3.js。内容一变，URL 就变，浏览器天然不会复用旧缓存——所以根本不怕缓存太久。
选 7 天反而容易出问题：
- 部分 CDN 边缘节点会把 max-age
- 用户重复访问时，30 天能稳稳命中
from disk cache；7 天可能刚过期就又请求一次，白白浪费连接 - 宝塔下拉菜单里的「30 天」对应的是
max-age=2592000（秒），这是经过验证的兼容性与实效性平衡点
Chrome DevTools 显示「from memory cache」是不是没生效
不是。这恰恰说明缓存机制正在工作。「from memory cache」是浏览器进程内短期复用，属于更激进但临时的优化；「from disk cache」才是你设的 30 天真正起效的表现。
验证是否真的生效，只看响应头：
- 打开 Chrome DevTools → Network → 刷新页面 → 点一个
index.css文件 - 切换到 Response Headers 标签页
- 确认存在
Cache-Control: max-age=2592000且Expires是未来时间（比如Mon, 06 May 2026 10:27:00 GMT） - 如果看到
no-cache或max-age=0，大概率是 PHP 脚本自己输出了冲突头，比如 WordPress 插件调用了header('Cache-Control: no-cache')，它会直接覆盖 Nginx 的expires
想让某个文件不缓存，比如 favicon.ico 或调试用的 main.dev.js
宝塔面板的「启用静态文件缓存」是全局开关，没法按路径或后缀排除。真有这种需求，必须手动改 Nginx 配置，在默认静态规则之前加特例。
进站点设置 → 「配置文件」→ 找到 server { } 块，在类似下面这行之前插入 location 块：
location ~ .*\.(js|css|png|jpg|gif|jpeg|bmp|webp|ico|svg|woff|woff2|ttf|eot)$ {
插入内容示例：
location = /favicon.ico {
expires -1;
}
location ~ ^/static/main\.dev\.js$ {
expires -1;
}
注意：expires -1 表示禁用缓存（等价于 Cache-Control: no-cache），且必须放在通用规则之前，否则会被覆盖。这类手动配置一旦写错，可能导致整个站点 500，建议改前备份原始配置。
