在构造函数内部*分配原型方法-为什么不呢？

从功能上讲，以这种方式构造代码是否有任何弊端？将原型方法添加到构造函数内部的原型对象中（即，在构造函数的表达式语句关闭之前）会导致意外的作用域问题吗？

是的，存在缺陷和意外的范围界定问题。

1. 一遍又一遍地将原型分配给本地定义的函数，都将重复该分配并每次都创建一个新的函数对象。由于不再引用早期的分配，因此将对其进行垃圾回收，但是与第二个代码块相比，在构造函数的运行时执行和垃圾回收方面，这都是不必要的工作。

2. 在某些情况下会出现意外的范围问题。有关Counter明确的示例，请参见答案末尾的示例。如果从原型方法中引用构造函数的局部变量，则第一个示例将在代码中创建潜在的讨厌的错误。

还有一些其他（较小的）差异。您的第一个方案禁止在构造函数外部使用原型，如下所示：

Filter.prototype.checkProduct.apply(someFilterLikeObject, ...)

而且，当然，如果有人使用过：

Object.create(Filter.prototype) 

如果不运行Filter构造函数，那还会产生不同的结果，可能不太可能，因为可以合理地预期使用Filter原型的某些东西应该运行Filter构造函数才能达到预期的结果。

从运行时性能的角度（对象上调用方法的性能）来看，这样做会更好：

var Filter = function( category, value ){
  this.category = category;
  this.value = value;

  // product is a JSON object
  this.checkProduct = function( product ){
    // run some checks
    return is_match;
  }

};

有一些Javascript“专家”声称不再需要使用原型节省内存（我几天前看了一个视频讲座），是时候开始在对象上直接使用性能更好的方法了，比原型 我不知道我是否准备倡导自己，但这是值得考虑的有趣问题。

我能想到的第一种方法的最大缺点是，犯一个讨厌的编程错误真的非常容易。如果您碰巧认为可以利用原型方法现在可以看到构造函数的局部变量这一事实，那么当您拥有一个以上的对象实例时，您将很快陷入困境。想象一下这种情况：

var Counter = function(initialValue){
  var value = initialValue;

  // product is a JSON object
  Counter.prototype.get = function() {
      return value++;
  }

};

var c1 = new Counter(0);
var c2 = new Counter(10);
console.log(c1.get());    // outputs 10, should output 0

问题的演示：http : //jsfiddle.net/jfriend00/c7natr3d/

这是因为，虽然该get方法看起来像一个闭包，并且可以访问作为构造函数的局部变量的实例变量，但实际上它并不起作用。由于所有实例共享同一个原型对象，因此该Counter对象的每个新实例都会创建该get函数的新实例（可以访问刚刚创建的实例的构造函数局部变量）并将其分配给原型，因此现在所有实例都具有一个get访问最后创建的实例的构造函数的局部变量的方法。这是一场编程灾难，因为这可能永远都不是原本打算的，并且很容易成为弄清问题出在哪里以及为什么原因的抓手。