压缩、缓存等优化配置

1、Spring Boot 内置 Web 服务器（Tomcat） 的配置：

服务监听哪个端口、URL 怎么编码、要不要压缩响应，以及怎么信任前面反向代理传来的头。

server:
  port: 4001  #程序对外监听的端口，访问后端大致是 http://主机:4001/...
  tomcat:
    uri-encoding: UTF-8  #请求 URL（路径、查询参数）按 UTF-8 解码。默认是它，这里起强调作用
  compression:
    enabled: true
    min-response-size: 1024
    mime-types: application/json,application/xml,text/html,text/xml,text/plain,text/css,application/javascript
  forward-headers-strategy: framework    #信任并消化前面代理转过来的真实协议/域名/IP 信息

 压缩：

开启 HTTP 响应压缩（通常是 gzip）。
返回内容较大时，先压一下再发给客户端，省带宽、有时也更快。

-

响应体至少 1024 字节 才压缩。
太小的响应压完可能更慢、甚至更大，所以设门槛。

-

只对这些内容类型压缩，例如：

• application/json：接口 JSON
• text/html / text/plain / text/css
• application/javascript 等

图片、已经压过的文件一般不在这里；对 JSON/文本最有用。

-

forward-headers-strategy: framework

前面如果有 Nginx / 网关 / 负载均衡，它们常会加：
X-Forwarded-For（真实客户端 IP）
X-Forwarded-Proto（原来是 http 还是 https）
X-Forwarded-Host（对外域名）
设成 framework 表示：由 Spring 框架处理这些转发头，让应用能正确知道：

真实客户端 IP
对外是不是 HTTPS
对外域名是什么
生产环境前面几乎都有反向代理时，这项很常见。不配的话，应用可能以为自己是 http://内网IP:4001，重定向、链接生成、日志里的 IP 会不准。

-

compression.* —— 自动对符合条件的响应生效
启动后由内置 Tomcat（或当前 Web 容器）处理：
请求方支持压缩（一般会带 Accept-Encoding: gzip，浏览器、常见 HTTP 客户端都会）
响应类型在你配的 mime-types 里（你们接口多数是 application/json，在列表中）
响应体 ≥ min-response-size（1024 字节）
满足就自动压缩再返回。
Controller / Service 不用写任何压缩相关代码。
不满足就不压，接口照常返回，只是没压缩。

forward-headers-strategy: framework —— 自动影响请求解析

启动后由 Spring 处理代理转发头，影响全局请求上下文，例如：
request.getScheme() / 是否 HTTPS
request.getServerName() / 对外域名
客户端 IP 相关解析
同样 不用在每个接口里手动读 X-Forwarded-*。
前提是前面 Nginx/网关已经正确设置了这些头。

 

是否压缩实际顺序

某个接口返回时，服务器大致会看：

1. 客户端支不支持压缩
   请求头里有没有 Accept-Encoding: gzip（或类似）。没有 → 不压，原样返回。

2. 响应类型在不在名单里
   是不是 application/json、text/html 等你配置的 mime-types。不在 → 不压。

3. 响应体够不够大
   是否 ≥ min-response-size（1024）。太小 → 不压。

都满足 → 服务器把响应体压成 gzip（等）再发出去，并加上类似 Content-Encoding: gzip。

所以不是“先判断类型再判断 1024”的固定死顺序（实现细节可能略有差别），但逻辑上就是：类型允许 + 够大 + 客户端愿意收压缩 → 才压。

压缩和解压响应体由：服务端（你们的 Spring Boot / Tomcat）、客户端（浏览器、前端、Postman、带 HTTP 库的程序）完成，我们不用写程序完成。

 

2、caffeine缓存 

1、写缓存名称配置 2、将需要找的缓存名称写方法上

浏览页那份数据不要每次都去数据库现查，先放在本机内存里，最多留 200 份，每份最多 60 秒。类似Java进程内的Redis

  cache:
    type: caffeine  #进程内内存缓存，数据在这台 Java 服务自己的内存里，重启、换机器，缓存就没了
    cache-names: browse:response  #缓存名称！！！
    caffeine:
      spec: maximumSize=200,expireAfterWrite=60s   #最大缓存200个（key）的，60秒过期

用户第一次查--->该key不存在-->查库，放到缓存--->返回前端

后续指定时间内查--->该key缓存存在，返回

注意：必须和方法上的 @Cacheable(cacheNames = "browse:response") 对上。名字不对，注解找不到这个抽屉。