无法制作第三方API请求(Unable to make third-party API Request)

 简短的回答是“是的”。 
 
 简化的长答案是“是的，尽管发电机有一些开销（在某种意义上是固定的，它不会随着要生成的项目数量而变化），这使得当要生成的项目数量很少时，节省的成本就会消失。” （但当然，在这种情况下，总成本足够小，无论如何都很重要） 
 
 对于长期答案过于复杂的警告： 
 
 CPython（参考Python解释器）对代码的优化很少; 它可以在非常有限的情况下进行小的窥视孔优化（例如，它可以在字节代码中将1 + 2 + x转换为3 + x ，但由于运算符重载和操作顺序，它无法将x + 1 + 2转换为x + 3 ，因为它不能假设x + 1将返回一个int ，并且它无法知道对于x证明的任何类型，加法是关联的。 因此，当您在CPython中使用生成器时，它将始终在运行时作为生成器执行。 
 
 相比之下，在大多数现代浏览器中，JavaScript引擎使用JIT-ing将JavaScript代码编译为本机代码; 它可以进行推测/自适应优化 ，它可以编译为假定特定类型和值的代码，并且只有在假设失败时才会依赖于解释原始JS。 这意味着你无法确切地说出在热循环中执行生成器代码的情况下将会采取什么措施（对于长期节省而言，昂贵的分析和优化将被认为是值得的）。 
 
 如果JS引擎确定生成器通常会产生少量可以提前计算的输出（通常是完全消耗的），那么生成过程没有明显的副作用，并且它会更有效而不是如果内存密集，那么生成本机代码并不能实际创建或运行生成器，而是产生一个输出Array （或者用于数字之类的东西，可能是ES6 类型的数组以减少内存使用） 。 我不了解哪些JS引擎（如果有的话）可能尝试执行这样的优化，但考虑到过去七年左右JS引擎的最新技术发展变化（最常用的现代JS引擎是最慢的）可能至少比2008年9月1日发布V8之前最快的引擎快10倍，今天发生的优化可能很快就会明天改变。 

The short answer is "Yes."
 
The simplified long answer is "Yes, though generators have some overhead (fixed in the sense that it doesn't change with the number of items to be generated) that make the savings vanish when the number of items to be generated is small." (but of course, in that case, the total cost is small enough that it rarely matters anyway)
 
Excessively complex caveat to the long answer:
 
CPython (the reference Python interpreter) does very little optimization of code; it can make small peephole optimizations in very limited circumstances (e.g. it can convert 1 + 2 + x to 3 + x in the byte code, but due to operator overloading and order of operations, it can't convert x + 1 + 2 to x + 3, because it can't assume x + 1 will return an int, and it can't know that addition is associative for whatever type x turns out to be). So when you use a generator in CPython, it will always be executed as a generator at run time.
 
By contrast, on most modern browsers, the JavaScript engine uses JIT-ing to compile the JavaScript code down to native code; it can make speculative/adaptive optimizations where it compiles to code that assumes specific types and values and falls back on interpreting the original JS only if the assumptions fail. Which means you can't actually say for sure what will be done in the case where your generator code is executed in a hot loop (where expensive analysis and optimization would be considered worthwhile for the long term savings).
 
If the JS engine determines that the generator is usually producing a small number of outputs that can be calculated ahead of time, that are usually fully consumed, that the generation process has no visible side-effects, and that it would be more efficient and not too memory intensive, it would be well within its rights to produce native code that doesn't actually create or run a generator, but instead produces an Array of outputs (or for stuff like numbers, perhaps an ES6 typed array to reduce memory usage). I have no insight into which JS engines, if any, might attempt to perform such an optimization, but given how rapidly state of the art has been changing for JS engines over the last seven years or so (the slowest commonly used modern JS engine is probably at least 10x faster than the fastest engine from Sept. 1, 2008, before V8 released), the optimizations that occur today could easily change tomorrow.