探讨TypeScript派生类get方法返回字符串字面量方案的JS输出问题

先直接说结论：这种get方法方案在生成的JavaScript中确实存在微小的性能开销，但绝大多数场景下可以忽略；不过它也有一些语义和使用上的小弊端，和成员属性类方案（假设是你提到的链接回答中的方案）相比各有取舍。

1. 生成代码的差异与性能对比 #

先看两种方案的JS输出：

• 你的get方法方案：

  class Derived extends Base {
    get type(): 'derived' {
      return 'derived';
    }
  }
  

  编译后的JS：

  class Derived extends Base {
    get type() {
      return 'derived';
    }
  }
  

  每次访问instance.type时，都会触发一次getter函数调用——哪怕这个函数只是简单返回一个字符串，函数调用本身也会有一点点栈帧创建、执行、销毁的开销。

• 假设链接回答中的方案是readonly成员属性（配合as const解决类型问题）：

  class Derived extends Base {
    readonly type = 'derived' as const;
  }
  

  编译后的JS：

  class Derived extends Base {
    constructor() {
      super();
      this.type = 'derived';
    }
  }
  

  这种情况下，type是实例自身的属性，访问时直接读取内存中的值，没有函数调用的开销。

不过要强调：这种性能差异只有在极高频次访问（比如循环中百万次读取）的场景下才会显现，普通业务场景完全感知不到。

2. 其他弊端与语义问题 #

除了微小的性能差异，get方法方案还有几个值得注意的点：

• 语义误导：getter在JavaScript中通常用于动态计算的值，其他开发者看到get type()可能会误以为这个值是动态生成的（比如依赖其他属性），而不是固定的字符串字面量，增加了理解成本。
• 序列化与属性检查差异：
  • 使用JSON.stringify(instance)时，虽然会正常序列化getter返回的字符串，但如果后续你修改getter逻辑（比如加入动态计算），序列化结果会跟着变；而成员属性的序列化结果是固定的。
  • 用instance.hasOwnProperty('type')检查时，getter定义在原型上，会返回false；而实例自身的成员属性会返回true，这在一些需要判断属性归属的逻辑中可能引发问题。
• 无法直接赋值（当然这可能是优点）：getter默认没有setter，所以无法给instance.type赋值；而如果是readonly成员属性，TypeScript层面会禁止赋值，但JS运行时其实可以修改（除非用Object.defineProperty设置不可写）。不过如果你本来就希望这个值不可变，这一点反而可能是get方法的优势。

3. 什么时候适合用get方法？ #

如果链接中的成员属性方案无法解决你的TypeScript类型问题（比如你提到的“成员属性会引发相同问题”），那get方法是完全可行的选择——毕竟在绝大多数业务场景中，那点性能开销根本不值得纠结，类型安全才是更重要的。

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