简短版本：

==可能会进行意外的类型转换，在Javascript中1=="1"为true。===运算符可避免此问题。将不同类型与===进行比较时始终为false。
当你用==比较不同的类型时，typescript编译器会发出一个错误消息。这消除了在Javascript中使用==时可能发生的意外类型转换。
在这种情况下，有效的Javascript会导致typescript编译器中出现错误消息。所有有效的Javascript都是有效的Typescript的想法是一个常见的误解。这是完全不正确的。

较长版本：我认为公认的答案是误导的。Typescript实际上确实修复了== vs ===（至少尽可能地）。

在Javascript中有两个比较运算符：

• ==：当比较基元值（如数字和字符串）时，此运算符将在进行比较之前应用类型转换。1 == "1"计算为true。
• ===：此运算符不进行类型转换。如果类型不匹配，它将始终返回false。

此外，两个运算符将根据其引用比较引用类型。两个单独的对象永远不会被视为彼此相等，即使它们存储相同的值：

let a = {val:1};
let b = {val:1};
c = a;

a==b; // false
a===b; // false
a==c; //true
a===c; //true

因此，在Javascript比较中有两个常见的错误来源：
1.用==比较不同的类型可能导致意外的类型转换。
1.比较对象和数组是基于引用而不是存储在其中的值。
正如已有的答案所说，Typescript被设计为Javascript的超集，因此它不会改变这些比较运算符的行为。如果你在Typescript中编写==，你会得到类型转换。
那么这个问题是如何解决的呢？用编译器。如果你真的写了一段代码来比较不兼容的类型和==，那就是一个编译器错误。试着编译下面的例子：

let str = "1";
let num = 1;

console.log(str == num);

编译器将告诉您：

comparisons.ts:4:13 - error TS2367: This condition will always return 'false' since the types 'string' and 'number' have no overlap.

4 console.log(str == num);
              ~~~~~~~~~~

Found 1 error.

一个常见的误解是任何有效的Javascript也是有效的Typescript。这是不正确的，上面的代码是一个例子，其中typescript编译器将抱怨有效的Javascript。
这将修复两个错误来源中的第一个：意外的类型转换。它不处理第二个错误源：基于引用的比较。据我所知，当你想基于对象存储的值进行比较时，你根本不能使用这些操作符。你必须实现你自己的equals()方法。
还有，你可能已经注意到编译器错误是错误的，比较不会总是求值为false，我认为这是typescript中的bug，有filed an issue。

假设您正在从头开始设计TypeScript，本质上，您正在尝试优化以使更安全的代码更易于编写（TypeScript设计目标1），但有一些注意事项会阻止您做所有您想做的事情。

JavaScript兼容性（TypeScript设计目标7）

JavaScript应该是未做任何更改的有效 typescript 。
CoffeeScript对此不做任何保证，所以它可以将所有==的示例转换为===，并简单地告诉用户 * 不要依赖==的行为 *。TypeScript无法在不破坏所有依赖其行为的JavaScript代码的情况下重新定义==（尽管这对3有很坏的影响）。
这也意味着TypeScript不能改变===的功能，例如，在编译时检查两个操作数的类型，并拒绝比较不同类型变量的程序。
此外，兼容性不限于简单的JavaScript程序;破坏兼容性也会影响JavaScript程序员，因为破坏了他们对==和===之间差异的假设。
引入可能会让用户吃惊的行为，而不是适当考虑其他常用语言所采用的模式。

JavaScript作为编译目标（TypeScript设计目标4）

所有的TypeScript都必须可以用JavaScript来表示。此外，如果可能的话，它应该是惯用的JavaScript。
实际上，TypeScript编译器可以使用返回布尔值的方法来进行所有的比较，完全不用==和===，这对用户来说可能更安全：在每个TypeScript类型上定义一个类型安全的等式方法（很像C++ operator==，只是没有重载）。
因此有一个变通方法（对于比较类的用户）。unknown或any变量可以在使用类型安全的相等方法之前缩小其类型。
∮你喜欢哪一个∮
在JavaScript中的任何地方都可以使用===。这样做的好处是避免了==常见的陷阱，并且不需要维护额外的方法。TypeScript编译器的输出将接近于惯用的JavaScript。**使用==与JavaScript有着非常相似的陷阱，特别是当您使用any、[]、或{}。**例外情况是，如果库代码不一致，使用== null检查null或undefined可以保存麻烦。
引用相等的方法（类似于类的===行为）可能会与深度/值递归相等检查混淆。此外，===在TypeScript中广泛使用，使代码符合约定通常比任何一点类型安全都重要。

你的直觉是正确的。在TypeScript中使用===来模拟相等性检查是没有意义的。TS编译到JS“所以你应该使用JS”中更好的参数是无效的。为什么？因为Typescript确保比较运算符的两个操作数（s）具有相同的类型。当两个操作数具有相同的类型时，==和===的行为相同。“相同”是指100%相同，而不仅仅是“相似”。因此没有 * 更正确 *或 * 不太正确 * 的版本，当两者在JavaScript中的行为完全相同时。
我猜这里的其他评论者只是在寻找方法来保持他们使用===的习惯，或者换句话说是合理化。不幸的是，纯逻辑告诉我们并非如此：用===替换==是没有意义的，除非您打算手动修改生成的JS代码，而这种情况可能永远不会发生。
我使用===专门用于身份检查（当你比较x和x -相同的变量时，在与记忆相关的库代码中有时是必要的），而我的与eqeq运算符相关的错误计数器显示0。
示例：

const s : string = "s"
const n : number = 1
console.log(s == n)

TS2367: This condition will always return 'false' since the types 'string' 
and 'number' have no overlap

我的意见是应该始终使用===。
第一条推理：TypeScript不会将==更改为===。有一些TypeScript转换器只会剥离类型。因此，如果由于某种原因忘记对程序进行类型检查，或者如果您（或您代码的未来维护人员）使用类型转换来覆盖类型安全，则到处使用===会导致代码更健壮。不应该发生这种情况，但许多事情都不应该发生。
第二条推理：null == undefined。TypeScript也是如此。我认为如果编写if (x == null)，代码的可读性会降低，因为它也暗示了对undefined的检查，并且隐式代码的可读性比显式if (x === null || x === undefined)低。如果不是故意这样做，也可能会出现细微的bug。
除了审美偏好，我看不出在任何地方无条件使用===有什么问题。