为何Iterator Protocol（迭代器协议）要挂载到Symbol属性中实现？

首先明确Symbol的核心设计定位：ES6 引入Symbol类型的核心目的之一，是提供全局唯一、不会与普通字符串属性名冲突的属性键标识符，解决 JS 长期存在的内置行为扩展容易和用户自定义代码冲突的问题。

为什么可迭代协议要基于 Symbol.iterator 实现 #

你说的“将Iterable Protocol封装在Symbol内部”，本质上是用标准内置的知名Symbol Symbol.iterator 作为可迭代协议的识别标志，这个设计完全是为了满足向后兼容要求：

• 如果可迭代协议用普通字符串作为属性名（比如约定叫__iterator__），那么ES6标准推出之前已经存在的大量业务代码中，很可能已经有自定义对象实现了同名的自定义方法，标准落地后这些老对象会被JS引擎误判为符合可迭代协议，直接导致运行错误，完全破坏向后兼容性。
• Symbol属性键天然全局唯一，用户自己定义的属性名不可能和标准内置的Symbol.iterator重名，不管是老代码还是新代码，都不会出现意外冲突，标准的落地完全不会影响已有业务的运行。

为什么可迭代协议不能做成独立外部功能 #

这个设计完全符合JS基于原型、对象行为自包含的设计逻辑，做成独立外部功能反而会有大量无法解决的问题：

• 不需要额外维护全局映射规则：如果可迭代判断依赖外部逻辑，就需要引擎单独维护一份“可迭代对象/类型”的全局映射表，用户要给自定义对象增加迭代能力，还得额外去映射表注册，使用成本远高于直接给对象加个Symbol.iterator方法。
• 没有上下文隔离问题：如果用外部全局映射表，不同执行上下文（比如页面里的多个iframe）之间的可迭代判断会因为映射表不共享出现逻辑不一致，而Symbol.iterator是绑定在对象本身的属性，不管在哪个上下文里判断结果都一致。
• 运行时调整更灵活：要修改某个对象的迭代行为，直接修改对象上的Symbol.iterator方法即可，不需要操作任何外部规则，符合JS动态类型的设计特点。
• 性能更高：判断对象是否可迭代只需要检查自身/原型链上是否存在Symbol.iterator对应的方法，这个属性查找逻辑是JS引擎早就深度优化过的，比查外部映射表快得多。

事实上所有知名Symbol（包括Symbol.toStringTag、Symbol.asyncIterator、Symbol.hasInstance等）都是同样的设计思路：用不会冲突的唯一键作为语言内置行为的扩展点，在不破坏现有生态的前提下给JS增加新的标准能力，可迭代协议只是这套设计的其中一个应用场景。

内容的提问来源于stack exchange，提问作者Alexander Gharibashvili