我最近一直在使用Javascript Fetch API。据我了解，默认情况下，所有重定向都是透明处理的，最后，我从重定向链中的最后一个调用得到响应。
但是，我可以使用{redirect:'manual'}调用fetch，在这种情况下，它将返回不可用信息的opaqueredirect响应。从https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect
https://fetch.spec.whatwg.org/#http-fetch说，如果将重定向设置为“手动”，则响应将变为opaqueredirect:
该规范还说:
考虑到所有这些，为什么在使用Fetch API时将一组重定向到手册？在我看来，这似乎毫无用处。是否有一些有用的用例？
最佳答案
我认为简短的答案是:除非您要使用https://github.com/whatwg/fetch/issues/66描述的服务人员代码来做某事，否则您永远不需要redirect: 'manual'。
更长的答案:
当浏览器开始导航到资源时，HTML spec seems to require浏览器最初将重定向模式设置为manual，然后……(重新)在未设置重定向模式的情况下进行操作？ (在这种情况下，默认情况下返回到follow。)我不明白为什么规范中的算法采用这种方式，但是猜测它一定与处理导航失败的情况有关。无论如何，我相信manual重定向模式在所有规范中都是唯一的用法。
无论如何，Fetch API的设计目的是公开浏览器在提取中使用的所有相同原语，但这并不意味着Web应用程序代码中这些原语总是有很好的用途(与浏览器本身对原语)。
因此，我认为Fetch规范曾经要求即使您可以使用redirect: 'manual'调用API，但浏览器会抛出该错误-我想是因为那时没有人提出任何有效的理由来设置除浏览器进行导航。
但是由于https://github.com/whatwg/fetch/issues/66改变了这种行为，ojit_a描述了(拐角)情况，其中服务 worker 代码中需要redirect: 'manual'。
可以在Fetch API中设置的类似情况，但在Web应用程序代码中实用性很小的情况是mode: 'no-cors'。最初添加它只是因为浏览器将其用于某些请求，因此Fetch API公开了它。但这是另一种情况，仅适用于服务人员，其效用有限-稍后将响应缓存为按原样提供，而无需检查响应(mode: 'no-cors'阻止了Web应用程序代码的工作)。
关于javascript - 获取API-重定向: manual的用途是什么，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/42716082/