TypeScript泛型使用核心原因解析：为何不用any替代？

先看一下你给出的示例代码：

class Greeter<T> { 
  greeting: T; 
  constructor(message: T) { 
    this.greeting = message; 
  } 
  greet() { 
    return this.greeting; 
  } 
}
let greeter = new Greeter<string>("Hello, world");
let button = document.createElement('button');
button.textContent = "Say Hello";
button.onclick = function() { alert(greeter.greet()); }
document.body.appendChild(button);

一、这个场景下用泛型的主要原因 #

咱们从实际开发的角度拆解：

• 编译时类型安全：当我们指定Greeter<string>时，TypeScript会强制要求构造函数的参数必须是string类型，greeting属性也只能是string，greet()返回的也必然是string。如果哪天你不小心把"Hello, world"改成了123，编译阶段直接就会报错，提前把bug扼杀在摇篮里，不用等到运行时alert出一个莫名其妙的数字才发现问题。
• 灵活复用代码：这个Greeter类不用修改一行代码，就能适配不同类型的问候内容。比如你想做一个数字问候器，直接new Greeter<number>(999)就行；想传一个自定义对象，new Greeter<{content: string}>({content: "Hi there"})也完全没问题，不用为每种类型单独写一个类，大大提升了代码复用性。
• 更好的开发体验：编辑器能根据泛型参数提供精准的代码提示。比如你输入greeter.greet().的时候，编辑器会自动弹出字符串的所有方法（比如toUpperCase()、split()），因为它明确知道返回的是string类型，写代码效率高多了。

二、为什么不能用any替代泛型 #

如果把T换成any，看起来好像能实现同样的功能，但会带来一堆隐患：

• 彻底丢失类型检查：用any的话，你可以给构造函数传任何类型的值，甚至后续还能把greeting改成完全不同的类型，比如greeter.greeting = 123，TypeScript不会拦你。等到运行时alert出来的是数字，或者如果传了一个对象，alert显示[object Object]，完全不符合预期，排查问题也麻烦。
• 编辑器提示全失效：当你用any时，编辑器不知道greeter.greet()返回的是什么类型，不会给出任何方法提示。如果你想调用greeter.greet().toUpperCase()，编辑器不会提醒你如果返回的不是string会报错，只能等到运行时才发现问题。
• 代码可读性与维护性下降：其他开发者看代码时，用泛型能一眼明白Greeter是用来处理某种特定类型的问候内容，而用any的话，完全看不出这个类的预期用途，后续维护时很容易踩坑。

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