fetch() 在扩展程序中有效，但在 Chrome 控制台/代码片段中失败

Question

我的 Chrome 扩展执行了一个 get 请求，效果很好。由于使用代码片段测试速度更快，因此我想在 Chrome 控制台或 Chrome 代码片段中执行完全相同的操作。最小的例子：

fetch(url, {
    method: "GET"
}).then(response => response.text())
  .then(html => console.log(html))
  .catch(error => console.log(error))

不幸的是，我只能得到

TypeError: Failed to fetch对于错误和

Failed to load resource: net::ERR_FAILED在 Chrome 的内联错误标记中

在我的 Chrome 扩展中，我遇到了 CORS 问题，因此我在 AWS Lambda 函数中所做的是将标头设置为

const headers = {
    'Content-Type': 'application/json',
    "Access-Control-Allow-Headers" : "Content-Type",
    "Access-Control-Allow-Origin" : "*",
    "Access-Control-Allow-Credentials" : true
};

所以我认为CORS 不是这里的问题。但我似乎无法弄清楚在扩展程序中运行请求与在控制台/代码片段中运行请求会产生什么差异。我在这里可能会缺少什么？

我也没有在 AWS CloudWatch 中看到该请求，所以我想它甚至没有离开我的机器。我正在对安装了 0 个扩展的 Chrome 用户进行测试，在隐身模式下也会发生同样的情况

为了解决我的服务器的任何问题，我还插入了https://lockevn.medium.com/snippet-to-fetch-remote-rest-api-and-display-in-console-of-chrome-devtool中的示例-6896a7cd6041

async function testGet() {
    const response = await fetch('https://jsonplaceholder.typicode.com/posts')
    console.log(await response.json())
}

async function testPost() {
    let r = await fetch('https://jsonplaceholder.typicode.com/posts', {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
        },
        body: JSON.stringify({
            lockevn: 1
        }),
    })
    console.log(await r.json())
}


testGet()

testPost()

Chrome 的“网络”选项卡显示请求已停止

链接的“解释”给出

排队：浏览器在以下情况下对请求进行排队：

• 有更高优先级的请求。

• 已为此源打开 6 个 TCP 连接，这是限制。仅适用于 HTTP/1.0 和 HTTP/1.1。

• 浏览器正在短暂分配磁盘缓存空间

已停止：请求可能因排队中描述的任何原因而被停止。

更高的优先级似乎很奇怪，6 个连接也不是问题，因为我在测试之前重新启动了浏览器，而且磁盘缓存问题听起来也不像问题。我不是没有防病毒软件的 macOS

Answer 1

我设法找到了问题。为了避免通过在 AWS 仪表板选项卡中打开 Chrome 开发人员控制台来潜在地授予我的请求特权，我创建了一个新选项卡 ( chrome://new-tab-page/) 并在控制台中执行了请求。这返回了所描述的错误。

当我用示例代码更新我的问题时，我想先确认它是否正在运行，然后再要求某人尝试它是否在他们的机器上运行。为了快速运行时验证，我在 Stackoverflow 选项卡中打开了控制台，它起作用了。我只想检查代码是否可以被解释，但结果实际上返回了结果。这对于我的 AWS 实例也是有效的，如果我在 https 网站上运行它，它就可以正常工作。不知道为什么没有记录这一点，但提到“磁盘缓存”是一个潜在的错误。

tldr don't open Chrome Console in new tab for requests in the console, use any website.这可能与 CORS 标头仅在请求没有空标头开头时才起作用有关（？）

我特别避免使用网站控制台实例进行测试，因为我想防止 AWS 页面上的潜在 cookie 执行其他人无法在其计算机上执行的操作。好的想法坏结果哈哈

非常感谢您的评论建议的帮助，非常感谢。