为什么我不能从构造函数内部覆盖构造函数的原型？

你可以，但为时已晚。新实例已经生成，继承自旧原型。也许阅读如何new工作。

我不喜欢原型通常是如何从构造函数外部定义的。

就是那样子。您真的不应该从构造函数中设置原型 - 每次创建新实例时都会执行它。这特别是原型不应该是什么。另请参阅在构造函数中*内部*分配原型方法 - 为什么不呢？

并希望在逻辑上更好地封装事物。

您可能想看看各种（揭示）module模式。或者甚至可能在某个Class框架中。

我目前正在寻找更具体的原因，我不应该继续我一直在展示的模式。

它在 Internet Explorer 中不起作用。它不会在任何不支持该__proto__属性的ES5 兼容环境中工作。您永远不应该使用它在现有对象上设置原型。相反，使用Object.create（或其垫片）进行正确的 javascript 继承- 这要求您覆盖构造函数之外的原型。

我的建议是在它extend的构造函数之外调用你的助手，它仍然有一个很好的语法。

对特定问题的回答

为什么我不能从构造函数内部覆盖构造函数的原型？

这是因为构造函数实际上是在您的对象已经被实例化之后被调用的。并且由于您的对象在您的构造函数接触任何东西之前已经成功实例化，您的构造函数也已经被分配了一个“默认”原型。

添加属性this.constructor.prototype似乎有效——因为您实际上是在操作构造函数的预先分配的默认原型对象，您的所有实例都继承自该对象。

在我的示例中，this.constructor.prototype最终指的是构造函数的默认分配原型：完全覆盖这意味着从那一刻起所有新实例都将具有该新原型——正如贝尔吉所说，“太晚了”——你当前的实例将没有那个新原型，因为它仍然具有旧的默认分配原型，因为它已经被实例化。

避免废话的更好模式

我开始明白，我的问题中提出的技术根本行不通。这个问题本身通常是被误导的。通过将 Bergi 的智慧与我自己的个人偏见相结合，我提出了这种模式，以此来避免必须完全找到原始问题的答案：

function extend(p){
  return { to: function(C){ for (k in p) if (p.hasOwnProperty(k)) 
  C.prototype[k]=p[k]; return C; } };
};

var orifice = new function Orifice(){
  this.exhaust=function(){};
  this.ingest=function(){};
};

var Sphincter = extend(orifice).to(function Sphincter(){
  this.relax=function(){};
  this.tighten=function(){};
});

这是扩展功能，扩展：

function extend(parentObject){
  return { 
    to: function(ChildConstructor){
      for (key in parentObject) 
        if (parentObject.hasOwnProperty(key)) 
          ChildConstructor.prototype[key] = parentObject[key];
      return ChildConstructor;
    }
  };
};

我用它来测试它是否有效：

// TESTING
var s=new Sphincter();
var tests=['relax','tighten','exhaust','ingest'];
for (var i in tests) console.log("s."+tests[i]+"() is "+(tests[i]in s?"present :)":"MISSING!"));