我也遇到过同样的问题，在我们的代码深处，我们有这样的伪代码:

创建iframe 加载iframe提交一个表单 2秒后，移除iframe

thus, when the server takes more than 2 seconds to respond the iframe to which the server was writing the response to, was removed, but the response was still to be written , but there was no iframe to write , thus chrome cancelled the request, thus to avoid this I made sure that the iframe is removed only after the response is over, or you can change the target to "_blank". Thus one of the reason is: when the resource(iframe in my case) that you are writing something in, is removed or deleted before you stop writing to it, the request will be cancelled

如果您使用axios，它可以帮助您

// change timeout delay: Instance.defaults.timeout = 2500;

https://github.com/axios/axios#config-order-of-precedence

你可能想要检查“X-Frame-Options”标题标签。如果它设置为SAMEORIGIN或DENY，那么iFrame插入将被Chrome(和其他浏览器)根据规范取消。

另外，注意一些浏览器支持ALLOW-FROM设置，但Chrome不支持。

为了解决这个问题，你需要删除“X-Frame-Options”标题标签。这可能会让你容易受到点击劫持攻击，所以你需要决定风险是什么以及如何减轻它们。

在我的情况下，它开始出现后chrome 76更新。

由于一些问题在我的JS代码，窗口。位置被多次更新，导致取消先前的请求。 虽然这个问题之前就存在，但chrome在更新到版本76后开始取消请求。

在我的情况下，问题的原因是另一个。

我的应用程序坐在代理后面，Chrome请求被发送与If-Modified-Since HTTP头。当这个头文件出现时，预期的行为是:

只有在给定日期后最后一次修改时，服务器才会以200状态发送回所请求的资源。如果请求此后未被修改，则响应将是一个没有任何正文的304;

代理没有满足这一期望，响应一个304状态代码，但一个非空的主体，从而导致请求被取消。

在修复代理行为后，请求就像一个魅力。

以我为例，我发现它是jquery的全局超时设置，一个jquery插件设置全局超时为500ms，这样当请求超过500ms时，chrome就会取消请求。