javascript - 修改原型prototype会有什么风险？

Question

曾经看到过修改prototype这种做法不好，本人实际使用感觉非常方便，有什么不好的？
例如：
要在所有的react组件或vue组件中，做数字的格式化，直接如下：

String.prototype.toNum = Number.prototype.toNum = function(s) {    }

就能在所有组件中的任何字段，方便的调用toNum方法了，无需每个组件引入方法

Answer 1

其实大部分的JavaScript库都在大量的使用。比如Vue。
平常自己用也很好。非要说风险，那就是多人合作时，需要注意一些风险点。

考虑兼容性问题

不要去覆盖已有的函数，自定义的尽量把名字取的奇怪一点，避免未知的情况下覆盖了已有的函数，可以考虑加一些前缀。

// 假设这是一个已有的库代码function doSomethingWithArray(arr) {  for (let item of arr) {    // 基于原始的 Array.prototype.includes 方法进行操作    if (!arr.includes(item * 2)) {      // 执行一些操作    }  }}// 其他地方修改了 Array.prototype.includes 方法Array.prototype.includes = function (value, fromIndex) {  // 自定义的实现，与原始行为不同  return false;};let myArray = [1, 2, 3];doSomethingWithArray(myArray); // 由于原型修改，这里的行为可能不再符合预期

代码可读性问题

别人阅读你代码时候，很陌生的函数''.toNum()，会疑惑干什么用的。尽可能可能把注释写写全问题也不大。告诉人家这个是哪儿定义的做什么用的。

性能影响

某些情况下，会影响JavaScript引擎优化策略，导致性能下降。特别是添加prototype特别多或者数据量特别大的情况下。

Answer 2

我非常喜欢这样的写法，面向对象的高级用法，逻辑上很实用

Answer 3

自己用当然感觉不错，但是如果需要跟人合作就很麻烦了。现代化软件开发几乎不可能一个人完成，都要大量使用第三方开源仓库。如果每个人都往原型上挂东西，每个人写法都不一样，A 跟 B 冲突，一单用了 A，全部跟 B 相关的都不能用，那就是一场灾难。

现实世界也是如此，每个看起来不太合理的规定背后，可能都是你没遇到过的惨痛经历。

Answer 4

在JavaScript中修改内置对象的原型（如String.prototype、Number.prototype等）确实可能带来一些风险，尽管在某些场景下它看起来非常方便。以下是修改原型时可能遇到的一些风险和问题：

1. 命名冲突：如果你添加的方法与现有方法或未来可能会添加的方法同名，那么你的方法将会覆盖它们，这可能导致难以调试的问题。
2. 不可预测性：当你修改原型时，你改变了所有实例的行为。这可能会导致在不知情的情况下影响其他代码段。特别是在大型项目或第三方库中，这种改变可能是灾难性的。
3. 非标准性：修改内置对象的原型并不是ECMAScript标准所推荐的做法。这意味着它可能不会被所有环境或未来的JavaScript版本所支持。
4. 测试困难：如果你修改了原型，那么测试你的代码可能会变得更加困难，因为你需要确保所有的代码（包括你的代码和任何依赖的代码）都与你的修改兼容。
5. 性能问题：虽然这通常不是主要问题，但在某些情况下，修改原型可能会引入一些小的性能开销，因为每次访问一个方法时都需要进行额外的检查。
6. 可读性：对于不熟悉你的代码的人来说，看到你在使用someString.toNum()这样的方法可能会感到困惑，因为他们可能不知道toNum是哪里来的。
7. 扩展性：如果你希望在未来扩展你的toNum方法（例如，添加新的参数或行为），那么你可能会发现很难在不破坏现有代码的情况下进行这样的扩展。

对于你的例子，即希望在所有的React或Vue组件中方便地格式化数字，更好的做法可能是创建一个工具函数或模块，并在需要的地方导入它。例如：

// numFormatter.jsexport function formatNumber(num) {    // 你的格式化代码}// 在你的组件中import { formatNumber } from './numFormatter';// 使用const formattedNum = formatNumber(someNumber);

这种方法更加清晰、可预测，并且更容易测试和扩展。