当你扩展一个对象时，你改变了它的行为。

更改仅由您自己的代码使用的对象的行为是可以的。但是，当您更改其他代码也使用的某些内容的行为时，您可能会破坏其他代码。

当在 javascript 中向对象和数组类添加方法时，由于 javascript 的工作方式，破坏某些东西的风险非常高。多年的经验告诉我，这种东西会导致 javascript 中出现各种可怕的错误。

如果您需要自定义行为，最好定义您自己的类（可能是一个子类）而不是更改本机类。这样你就不会破坏任何东西。

改变一个类的工作方式而不对其进行子类化的能力是任何优秀编程语言的一个重要特性，但它必须很少使用并且必须谨慎使用。

没有可衡量的缺点，例如性能下降。至少没有人提到任何。所以这是个人喜好和经验的问题。

专业人士的主要论点：它看起来更好，更直观：语法糖。它是一个特定于类型/实例的函数，因此它应该专门绑定到该类型/实例。

主要的反对意见：代码可以干扰。如果lib A 添加了一个函数，它可能会覆盖lib B 的函数。这可以很容易地破坏代码。

两者都有一个道理。当您依赖两个直接更改您的类型的库时，您很可能最终会得到损坏的代码，因为预期的功能可能不一样。我完全同意这一点。宏库不得操作本机类型。否则，作为开发人员，您将永远不知道幕后到底发生了什么。

这就是我不喜欢 jQuery、下划线等库的原因。别误会我的意思；它们的程序设计得非常好，工作起来很迷人，但它们很大。你只使用了其中的 10%，理解了大约 1%。

这就是为什么我更喜欢原子方法的原因，在这种方法中，您只需要真正需要的东西。这样，你总是知道会发生什么。微型图书馆只做你想让他们做的事，所以他们不会干涉。在让最终用户知道添加了哪些功能的情况下，扩展本机类型可以被认为是安全的。

TL;DR如有疑问，请不要扩展本机类型。仅当您 100% 确定最终用户将了解并希望该行为时才扩展本机类型。在任何情况下都不要操作本机类型的现有函数，因为它会破坏现有接口。

如果您决定扩展类型，请使用Object.defineProperty(obj, prop, desc); 如果不能，请使用类型的prototype.

我最初提出这个问题是因为我希望Errors 可以通过 JSON 发送。所以，我需要一种方法来对它们进行字符串化。error.stringify()感觉比errorlib.stringify(error); 正如第二个结构所暗示的那样，我是在操作errorlib而不是在操作error本身。

在我看来，这是一种不好的做法。主要原因是整合。引用 should.js 文档：

OMG IT EXTENDS OBJECT???!?!@ 是的，是的，应该有一个 getter，不，它不会破坏你的代码

好吧，作者怎么知道？如果我的模拟框架也这样做呢？如果我的Promise库也这样做呢？

如果你在自己的项目中这样做，那就没问题了。但是对于图书馆来说，这是一个糟糕的设计。Underscore.js 是一个以正确方式完成事情的例子：

var arr = [];
_(arr).flatten()
// or: _.flatten(arr)
// NOT: arr.flatten()

如果您逐个查看它，也许某些实现是可以接受的。

String.prototype.slice = function slice( me ){
  return me;
}; // Definite risk.

覆盖已经创建的方法会产生比它解决的更多的问题，这就是为什么在许多编程语言中通常声明要避免这种做法。开发人员如何知道功能已更改？

String.prototype.capitalize = function capitalize(){
  return this.charAt(0).toUpperCase() + this.slice(1);
}; // A little less risk.

在这种情况下，我们不会覆盖任何已知的核心 JS 方法，而是扩展 String。这篇文章中的一个论点提到新开发人员如何知道此方法是否是核心 JS 的一部分，或者在哪里可以找到文档？如果核心 JS String 对象获得一个名为capitalize的方法会发生什么？

如果不是添加可能与其他库冲突的名称，而是使用所有开发人员都可以理解的公司/应用程序特定修饰符，该怎么办？

String.prototype.weCapitalize = function weCapitalize(){
  return this.charAt(0).toUpperCase() + this.slice(1);
}; // marginal risk.

var myString = "hello to you.";
myString.weCapitalize();
// => Hello to you.

如果您继续扩展其他对象，所有开发人员都会在野外遇到它们（在这种情况下）we，这会通知他们这是公司/应用程序特定的扩展。

这不会消除名称冲突，但确实减少了可能性。如果您确定扩展核心 JS 对象适合您和/或您的团队，那么这可能适合您。

扩展内置函数的原型确实是一个坏主意。然而，ES2015 引入了一种新技术，可用于获得所需的行为：

利用WeakMaps 将类型与内置原型相关联

以下实现扩展了Number和Array原型，而根本不接触它们：

// new types

const AddMonoid = {
  empty: () => 0,
  concat: (x, y) => x + y,
};

const ArrayMonoid = {
  empty: () => [],
  concat: (acc, x) => acc.concat(x),
};

const ArrayFold = {
  reduce: xs => xs.reduce(
   type(xs[0]).monoid.concat,
   type(xs[0]).monoid.empty()
)};


// the WeakMap that associates types to prototpyes

types = new WeakMap();

types.set(Number.prototype, {
  monoid: AddMonoid
});

types.set(Array.prototype, {
  monoid: ArrayMonoid,
  fold: ArrayFold
});


// auxiliary helpers to apply functions of the extended prototypes

const genericType = map => o => map.get(o.constructor.prototype);
const type = genericType(types);


// mock data

xs = [1,2,3,4,5];
ys = [[1],[2],[3],[4],[5]];


// and run

console.log("reducing an Array of Numbers:", ArrayFold.reduce(xs) );
console.log("reducing an Array of Arrays:", ArrayFold.reduce(ys) );
console.log("built-ins are unmodified:", Array.prototype.empty);

如您所见，即使是原始原型也可以通过这种技术进行扩展。它使用映射结构和Object身份将类型与内置原型相关联。

我的示例启用了一个reduce仅期望 anArray作为其单个参数的函数，因为它可以提取信息如何创建一个空的累加器以及如何从数组本身的元素中将元素与此累加器连接起来。

请注意，我可以使用普通Map类型，因为当弱引用仅表示从未被垃圾收集的内置原型时，它们没有意义。但是， aWeakMap不是可迭代的，除非您拥有正确的密钥，否则无法对其进行检查。这是一个理想的功能，因为我想避免任何形式的类型反射。