重写原生JavaScript原型是否影响性能？实例创建耗时探讨

好问题！你已经精准get到了原型共享内存的核心优势，但关于性能影响和实践可行性的疑问确实值得好好梳理——我来逐个给你拆解清楚：

实例创建的全局耗时：几乎不会受影响 #

首先要明确：JS对象实例本身不会存储原型上的函数，它们只是通过原型链指向共享的原型对象。当你创建新实例时，JS引擎只需要初始化实例自身的属性（如果有的话），完全不需要处理原型上的任何函数。所以不管原型上挂了多少方法，实例创建的速度都和原型为空时几乎没差别。

函数索引规模更大：创建对象时根本不存在“加载索引”的过程 #

你提到的“加载函数索引”其实是个误解——创建对象的过程和原型上的函数索引没有关系。只有当你访问实例的某个方法时，引擎才会沿着原型链向上查找对应的属性。

现代JS引擎（比如V8）对原型链查找做了极致优化，比如内联缓存（IC）机制，会把常用的查找路径缓存起来，哪怕原型上有几百个方法，正常情况下的查找速度也快到可以忽略。只有当你频繁修改原型链，或者查找路径特别长（比如多层嵌套原型）时，才可能出现可感知的性能下降，但这种场景在实际开发中极少出现。

向Object原型添加大量函数：性能影响微乎其微，但枚举问题才是真正的大坑 #

性能层面，除非你往Object.prototype上挂几千个甚至上万个函数，否则几乎不会对全局性能产生影响——引擎的优化足以应对这种规模的原型扩展。

但真正的问题是可枚举属性的遍历：默认情况下，添加到原型上的方法是可枚举的，这意味着当你用for...in循环遍历任何对象时，都会把这些原型方法也列出来。比如你本来只想遍历自己对象的name、age属性，结果循环里突然冒出where、map这些Underscore方法，很容易导致逻辑bug。

当然你可以用Object.defineProperty把这些方法设为enumerable: false，但Underscore有上百个函数，一个个设置的工作量极大，而且旧环境（比如IE8及以下）还不支持这个API。

能否把Underscore全加到Object/Array原型？技术可行，但极度不推荐 #

从技术角度说，你完全可以写个循环把Underscore的所有方法挂载到Object.prototype或Array.prototype上，但这是JS社区公认的反模式，原因有这些：

• 命名冲突风险：如果你的对象本身有一个where属性，或者其他库也修改了原型并使用了同名方法，直接就会覆盖，引发难以排查的bug。
• 代码可读性差：其他开发者看到myObject.where()时，根本不知道这是原生方法、你自定义的原型方法，还是Underscore的方法，维护成本极高。
• 原型污染：修改Object.prototype会影响所有JS对象，包括原生的包装对象（比如new String("test")），很容易触发意想不到的行为。

相比之下，Underscore原本的_.where(myObject, ...)写法虽然多敲几个字符，但清晰、安全，不会带来任何额外的风险。

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