JavaScript类为何在constructor内外重复声明初始化同名属性

针对你给出的Rectangle类示例，很多人刚接触类公共字段语法时都会有类似疑问：既然constructor执行时总会覆盖height、width的取值，在constructor外部声明这两个属性是不是冗余写法？答案是完全不是冗余，这些字段有不可替代的实际作用，常见的适用场景包括：

• 作为类结构的自文档，降低维护成本
  公共字段统一写在类定义的最顶部，相当于直接给所有开发者列了一份清晰的实例属性清单：这个类的实例一定会对外暴露height、width两个属性。你不需要翻完几十上百行的constructor逻辑，从零散的this.xxx赋值语句里拼凑实例的属性结构，尤其是当constructor里有大量条件分支、异步逻辑、初始化方法调用的时候，顶部的字段声明能大幅降低读代码、改代码的成本。
  同时IDE、静态检查工具可以直接根据字段声明做代码提示、类型校验，不需要动态推导constructor里的赋值逻辑，提示准确率会高很多。
• 提供稳定的兜底默认值
  公共字段的初始化时机早于constructor函数体内的逻辑执行：当你进入constructor开始写业务逻辑的时候，所有声明过的类字段已经完成初始化——写了初始值的字段会被赋值为对应默认值，没写初始值的字段也会被挂载到实例上、值为undefined。
  这种机制可以很好地兜底逻辑漏洞：如果后续重构代码时调整了constructor的赋值逻辑，某条分支下漏写了height或者width的赋值，字段的默认值就会生效，不会出现访问属性得到undefined、甚至顺着原型链找到意外值的问题。哪怕你确定constructor里100%会覆盖这两个值，height = 0的写法也相当于明确了属性的默认值语义，后续改逻辑时不需要反复确认“这个属性没传参的时候默认应该设成啥”。
• 保证constructor早期调用方法时的属性可用性
  如果你在constructor里、给属性正式赋值之前就调用了类的原型方法（比如参数校验、初始化埋点、事件绑定这类操作），方法内访问实例属性时，拿到的就是类字段初始化后的稳定值，不会因为还没执行到赋值语句就出现属性不存在的问题。
  举个实际的例子：

  class Rectangle {
    height = 0;
    width;
    constructor(height, width) {
      this.logInitStatus(); // 赋值前就调用原型方法
      this.height = height;
      this.width = width;
    }
    logInitStatus() {
      // 因为提前声明了height字段，这里访问this.height能稳定拿到初始值0，不会顺着原型链找到意外值
      console.log(`矩形初始化，初始高度为${this.height}`);
    }
  }
  

  如果你不在类顶部声明height字段，执行this.logInitStatus()的时候this.height还没被赋值，访问时会顺着原型链向上查找，很容易拿到意料之外的结果。
• 显式声明无初始值字段的存在性
  示例里的width;是没有设置初始值的字段声明，它的核心作用是明确属性的存在性：width是这个类实例的固定自有属性，哪怕暂时没赋值，它也是真实存在于实例上的。
  如果你不写这句声明，在constructor执行this.width = width之前，实例上根本没有width这个属性，用'width' in instance判断会返回false；声明之后，哪怕还没赋值，这个属性也已经挂载到实例上，只是值为undefined，不会出现属性存在性判断不符合预期的问题。

很多人觉得类字段只是“把constructor开头的赋值语句挪到类顶部”的语法糖，从纯执行结果来说大部分场景下确实差异不大，但它核心的价值是工程层面的：明确类的公共接口、降低多人协作的维护成本、减少边界场景下的逻辑漏洞，这也是标准语法推荐这种写法的核心原因。

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