[交互]交互的实战问题1

状态码 431 Request Header Fields Too Large

最近做项目，遇到一个问题，后台导出表格时，当条数超过一定数量时，会报：431 Request Header Fields Too Large 的问题，然后就在网上搜索这个问题，本质的问题就是 http 请求 header 过大。

这个问题网上的解决方案基本一致，就是修改服务器的 header 的大小。方案如下：

在 springboot 项目中，在 yml 文件中，添加如下内容：

server:
port: 8090
tomcat:
max-swallow-size: -1
max-http-header-size: 2MB

需要说明的是，max-http-header-size 是在 server 下，不是 tomcat 下。

网上很多人这样修改后都成功了，我的依旧报这个错误。然后我分析了一下，既然是服务器的问题，我用的是前后端分离，请求首先到达的是 ngnix，然后我又查了 ngnix 相关的修改，ngnix.conf 的修改如下：

http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #'$status $body_bytes_sent "$http_referer" '
    #'"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    client_header_buffer_size 10240k;
    large_client_header_buffers 6 10240k;
}

就是修改了 client_header_buffer_size 和 large_client_header_buffers 两个值。如果你的 ngnix.conf 中没有这个值，添加上就行。

修改后，项目的问题就没有了。

Referrer Policy: no-referrer-when-downgrade

发出请求，导致出现 Referrer Policy: no-referrer-when-downgrade，一直请求不成功

分析后发现，是请求连接出现问题，我这里的问题是-api 前少了/，导致请求 API 和域名拼接起来，所以导致上方问题。

• referrer-http 表示请求来源的字段
• no-referrer-when-downgrade 表示从 https 协议降级为 http 协议时不发送 referrer 给跳转到的网站的服务器。

路径参数

路径参数，这里的路径参数是指请求路径中拼接的参数，不是指 get 请求？后拼接的参数

示例：

/car/{id}/color

我看到服务端大多使用路径参数，我很少使用改方式，主要是{id}作为一个参数，存在很多不确定性，例如：id 中有.等特殊字符会导致服务端参数获取出现问题，会增加报错的风险

示例：
获取所有 year 生产的车列表

/car/{year}

获取所有具有某个色号的车列表

/car/{colorId}

以上则会产生混乱的风险

虽然也可以通过添加前缀加以区分,但是为什么要使用该方式？通过解说，发现这个好像是后端 restful 风格的最佳实践…

高并发问题

使用场景

一般当页面初始化的时候，可能存需要通过多个接口获取多个初始化数据

单个接口分别发出请求也能达到获取初始化数据，但是如果请求过多，并且获取的时间相差太大，导致有的接口已经完成有的仍在获取，影响用户操作，因此希望三者可以同步

使用的方法

const config = {
  url: "",
  method: "",
  params: {} //get 方法，其他的是data
};

axios.all([axios(config1), axios(config2), axios(config3)]).then(
  axios.spread(function (res1, res2, res3) {
    console.log("所有请求完成");
    console.log("请求1结果", res1);
    console.log("请求2结果", res2);
    console.log("请求3结果", res3);
  })
);

异常情况

只要一个接口存在异常，就无法获取正常返回接口的处理，只能对异常的结果进行处理

虽然返回的异常结果可以明确说明是哪个接口，并返回错误信息，但是当有多个接口错误的时候，仅仅返回第一个错误的信息，其他接口的错误信息并不返回，并且正常的接口也没有返回信息，无法回调

而在正常情况下，我们需要针对正常与异常返回数据的接口，分别回调进行数据处理

此时在网上找到了解决的方案,但是网上的代码有点难以理解，理解了半天，终于明白，关键问题是添加以下代码：

axios(one).catch((error) => ({ error }));

最终代码为：

const all = (config) => {
  const list = config.map((one) => {
    return axios(one).catch((error) => ({ error }));
  });
  return new Promise((resolve, reject) => {
    axios
      .all(list)
      .then((...res) => {
        const someError = res.some((one) => one.error);
        if (someError) {
          throw res;
        }
        resolve(res);
      })
      .catch((erro) => {
        reject(erro);
      });
  });
};