简介

将静态资源缓存到浏览器，并设置合理的有效时间，下次请求如果缓存没有失效，就直接读取浏览器的缓存，如果缓存过期了，发时请求到nginx，nginx判断内容是否变化，没变化 nginx 就直接响应302 状态码，浏览器收到 302 就会直接从本地读取数据了。变化了，就响应200重新响应新数据。

原理

• 原理： 浏览器会根据服务器返回的响应头中的 Expires 或 Cache-Control 指令来判断缓存是否过期。如果未过期，则直接从本地缓存中读取资源，而不会向服务器发送请求。
• 相关指令：
  • Expires: 指定资源的过期时间。
  • Cache-Control: 提供更细粒度的缓存控制，常见的值有：
    • max-age: 指定资源在缓存中的最大存活时间（秒）。
    • no-cache: 需要经过协商缓存才能使用。
    • no-store: 禁止任何存储。

实践

server {
    listen       80;
    listen  [::]:80;
    server_name blogs.systemcaller.cloud;

    location ~* \.(js|css|png|jpg|jpeg|gif)$ {
        expires 6m;
        root /root/wordpress/wordpress_data;
    }
}

以上配置设置了对静态资源缓存6分钟。

1. listen 80; 是监听 ipv4 的 80 端口。
2. listen [::]:80; 是监听 ipv6 的 80 端口。
3. server_name blogs.systemcaller.cloud; 是监听 blogs.systemcaller.cloud 这个域名。
4. location ~* .(js|css|png|jpg|jpeg|gif)$ 是使用正则匹配以静态文件后缀结尾的 url 。
5. expires 6m; 是指定过期时间为 6 分钟。其他单位比如天 d 、秒是 s 。
6. root /root/wordpress/wordpress_data; 是如果以上匹配成功了，就路由到这个目录下去找静态资源。请注意这是 docker 容器内的目录，不能是宿主机的映射目录。搞错了的话，资源找不到 404 了。

扩展

细说下 root 后的位置问题：

比如请求的是 http://blogs.systemcaller.cloud/a/b/test.jpg 那么实际访问的是/root/wordpress/wordpress_data/a/b/test.jpg 这个文件。

当你出现配置后访问 404 时，第一步首先判断是否匹配正确了，第二步看 nginx 的日志，日志中会记录实际访问的资源路径，就可以判断哪里不小心配错了。