JavaScript中何时需要主动使用prototype？

首先澄清核心误区 #

• 题解里的写法和Map的特性没有任何关系，这是JS自定义构造函数实现类功能的通用标准写法。
• 你平时调用arr.filter()、map.set()的时候不需要碰prototype，本质是因为JS引擎早就把这些内置方法提前挂在了对应内置构造函数的原型上：比如数组实例能用到的filter方法，早就写在Array.prototype上了；Map实例能用到的set方法，早就写在Map.prototype上了。你拿到实例对象后，顺着内置的原型链就能直接找到这些方法，自然不需要手动操作prototype。

为什么题解选择给prototype挂方法，而不是其他写法？ #

对比三种常见的实现方式，差异会非常直观：

1. 你疑惑的“直接写addScore = function(...)”的写法
   这种写法只是在当前作用域定义了一个独立的全局（或模块级）函数，既不属于Leaderboard的实例，也没法通过.addScore()的方式被实例调用，函数内部的this更是无法访问到实例存储的map属性，完全不符合Leaderboard类的功能要求。
2. 把方法直接写在构造函数内部，挂为实例自身属性的写法

   var Leaderboard = function() {
       this.map = new Map();
       // 直接把方法绑定在每个新建的实例上
       this.addScore = function(playerId, score) {
           if (this.map.has(playerId)) score = this.map.get(playerId) + score;
           this.map.set(playerId, score);
       }
   }
   

   这种写法功能上能跑通，但存在明显的内存浪费：每new一个新的Leaderboard实例，就会在内存里生成一份完全相同的addScore函数副本。新建100个实例就有100份重复的函数定义，完全是无意义的内存占用。
3. 挂在构造函数prototype上的写法
   所有通过Leaderboard构造函数生成的实例，会自动共享挂在prototype上的addScore函数——不管你新建多少个实例，内存里永远只有一份函数定义。实例调用这个方法时，会顺着原型链自动定位到这个共享函数，内部的this也会正确指向当前发起调用的实例对象。
   现在前端开发常用的class语法本质上就是这种写法的语法糖：你写class Leaderboard { addScore() {} }，底层的实现逻辑和Leaderboard.prototype.addScore = function(){}完全一致。

什么时候才需要用到prototype？ #

严格来说prototype不是语法层面“必须”使用的内容——哪怕你把所有方法都写在构造函数内部，功能逻辑也能正常跑通。我们选择用prototype，本质是出于内存效率和代码可维护性的最优选择：

• 给自定义构造函数生成的所有实例批量共享方法/属性时，把内容挂在prototype上，避免每个实例都冗余拷贝一份相同的内容，这是最常见的使用场景。
• 当你需要给JS内置对象（数组、Map、字符串等）的所有实例增加自定义扩展方法时，才需要手动修改对应内置构造函数的prototype（实际业务开发中这种操作需要极度谨慎，避免原生对象被污染引发不可预期的bug）。

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