TypeScript - 弱类型的问题JS这种弱类型语言在去应对大规模应用开发时，有可能会出现的一些常见问题：必须要等到

JS 这种弱类型语言在去应对大规模应用开发时，有可能会出现的一些常见问题：

必须要等到代码运行阶段才能够发现代码当中的一些类型异常，而且如果不是立即去执行，而是在某一个特定的时间才去执行，这样就会在代码上线后留下隐患。如果是强类型语言的话这里我们直接去调用对象当中一个不存在的成员，这里语法上就会报出错误。根本就不用等到去运行这行代码。
```
const obj = {}
obj.foo()
```
JS 缺少为函数的传参类型进行判断的机制，当传参的类型不对或者漏传时。在开发阶段都是不容易被发现的。虽然通过约定的方式也可以规避相应的问题，但是约定是根本没有任何保障的，特别是在多人协同开发的情况下。根本不能保证每个人都能遵循所有的约定，而如果使用的是一种强类型的语言，这种情况就会被彻底避免掉。因为在强类型语言当中如果我们要求传入的是数字，如果传入的是其他类型的值在语法上就行不通。
```
function sum (a, b) {
  return a + b
}
sum(100, '200')
sum(10)
```
通过索引器的语法去给对象添加属性，对象的属性名只能够是字符串或者是 symbol 。但是由于 JS 是弱类型的，就导致在索引器中可以使用任意类型的值去作为属性，而在内部会自动转换成字符串。如果说开发者不知道对象属性名会自动转换成字符串的特点，这里就会感觉很奇怪。这种奇怪的根源就是，我们用的是一个比较随意的弱类型语言。如果是强类型语言的话，这种问题也可以彻底避免。因为在强类型情况下这里索引器它明确有类型要求，不满足类型要求这样一个成员，在语法上就行不通。
```
const obj = {}
obj[true] = 100
console.log(obj['true'])
```

总结：第一个例子当中因为弱类型的关系，我们程序当中的一些类型异常，需要等到运行时才能够发现；第二个例子当中，因为弱类型的关系，类型不明确就会造成函数功能有可能发生改变；第三个例子当中因为弱类型的关系，就出现了开发者对对象索引器的一种错误用法。综上弱类型这种语言，它的弊端是十分明显的只是在代码量小的情况下这些问题都可以通过约定的方式来规避。而对于一些开发周期特别长的大规模项目这种约定的方式仍然会存在隐患。只有在语法层面的强制要求才能够提供更可靠的保障，所以说强类型语言的代码在代码可靠程度上是有明显优势的。使用强类型语言就可以提前消灭一大部分有可能会存在的类型异常，而不必等到运行过程当中才会发现的 bug 。