这对我来说太奇怪了——为什么代码会以这种方式进行防御性检查，当生成器不是唯一产生迭代器的方法时？

请注意，它还应继承自 %IteratorPrototype% ,该类将由 the Iterator helpers proposal 作为 Iterator.prototype 公开。

我很高兴为这个问题打开一个PR,修复似乎很明显。贡献指南建议我应该等待一个“需要帮助”的标签。大家是否愿意做出贡献？

@rbuckton的想法是什么？

请注意，它还应该继承自 %IteratorPrototype%,这将由 Iterator helpers提案作为 Iterator.prototype 暴露。

没有 %IteratorPrototype% 的下层，即使迭代器帮助提案有所进展，我也不认为我们会尝试为这种行为提供一个polyfill。此外，我们的助手通常可以在孤立的上下文中运行(即在一个单独的模块内),所以没有确保创建一个 共享 %IteratorPrototype% 的方法。

我同意 @DanielRosenwasser 的观点，仅仅有一个 Symbol.toStringTag 并不会使某物成为生成器。我们的下层发射旨在支持生成器的语法行为。我不知道我们是否应该走得这么远，以至于完全模拟生成器的整个运行时行为(与 Symbol.toStringTag 和 %IteratorPrototype% 有关)。

相反，我想知道为什么 @wordpress/redux-routine 依赖于 Symbol.toStringTag ,而不是 Symbol.iterator 。

just having a Symbol.toStringTag
To clarify, the check in @wordpress/redux-routine is maybeGenerator[ Symbol.toStringTag ] === 'Generator' . That does seem to be a valid way of checking for native generators.
[wondering why a library would depend] on Symbol.toStringTag , rather than Symbol.iterator
This been mentioned a few times, is the following the type of check you would suggest?

function isGenerator(x) {
  return !!x && typeof x[Symbol.iterator] === 'function';
}

function* makeGen() { }
const gen = makeGen();
console.log(isGenerator(gen)); // true

This check does seem to be satisfied by native, regenerator-runtime, and the TypeScript down-level implementation. I can propose that change to @wordpress/redux-routine .
FYI: @aduth

是的，我认为这可能是一个更合适的检查，尽管如果你这样做了，你会希望给函数起个名字，比如isIterable()。当然，还是要和@aduth确认一下，因为我不希望作为一个局外人假设错误的意图。

在 WordPress/gutenberg#19666 中，我们将检查更改为 @wordpress/redux-routine 。这实际上是在测试生成器接口。
@wordpress/redux-routine 希望对操作对象进行操作。虽然对象数组可能有意义，但显然不适用于这里的一个例子是字符串，即 typeof "foo"[Symbol.iterator] === 'function' 。库不想将字符串的字符视为可产生的动作。
感谢大家的反馈。随着 @wordpress/redux-routine 的更改，我的需要得到了满足。我将把这个问题留给维护者来决定是否还有其他需要考虑的内容，或者你们是否想关闭这个问题。