typescript和java区别_Typescript也许应该这样入门才对

摸鱼酱的文章声明：内容保证原创，纯技术干货分享交流，不打广告不吹牛逼。

前言：Typescript是前端当中一门饱受争议的技术，有人爱有人恨。在本文中，我不会劝你使用或者不使用TS，而是会站在一个客观的角度，探讨TS这门技术所解决的更本质的问题(即JS类型问题)及其解决方案(TS只是其中一种)。希望阁下看完这篇文章之后，能够超脱于TS本身，看到更加本质的问题，看到更多的解决方案。之后具体用不用，就是阁下自己的事情了。

对于JavaScript类型问题和解决方案，我从个人认识出发，用脑图做了以下整理：

接下来的行文，我都会围绕这副脑图展开，如果您有兴趣继续往下看下去，我希望您能在这幅图上停留多一些时间。

好地，按照上述脑图中的逻辑，接下来我会分成以下几个部分来展开探讨本文。

JS类型问题因果

解决方案：原始

解决方案：Flow

解决方案：Typescript

一：JavaScript类型问题因果

在上面的图中，我给出了我对JavaScript类型问题的因果论断。即由于JavaScript是一门动态弱类型的语言，直接导致了JavaScript编写的程序健壮性差，容易产生类型问题。这里先列举几个日常开发当中常遇到的类型问题，而后着重解释一下什么是动态弱类型语言以及为什么这会导致JS大量的类型问题。

好的，我们先看看一些类型问题。

1.常见类型问题

运行时报错

let fn;// or import fn from 'module'

fn()// TypeError: fn is not a function

复制代码

运行不准确

// 例一

let age = 10;

let inputIncrement = '1';

age = age + inputIncrement;// 不报错，结果为"101"，操蛋吧。

复制代码

潜在错误

let fn;

const callback = fn;// 不会立即出现问题，等callback被触发的时候才炸雷，操蛋吧。

复制代码

为了表述直观，我对上述列举的错误进行了简化处理。需要明白的是，这其中涉及到的几种问题只是我们日常开发当中所遇到的类型错误中的冰山一角，这一点有经验的开发者更能深刻体会。

总的来说，JavaScript更容易出现粗心代码。我们可能未必感觉到，在调试和测试阶段找到并处理这些粗心代码已经浪费了我们很多不必要的时间，尤其对于定位错误能力弱的同学来说更是操蛋，有时候艰难找到问题并发现是粗心所导致的时候恨不得扇自己一耳光。更要命的是，有些运行不准确和潜在错误的问题直到上线阶段才发现！

写过其它类型语言的人应该更会明显感觉到，自己写的JavaScript程序比自己写的其它类型语言的程序更容易出现低端错误，特别是代码量大起来之后尤其显著。

经过上面的探讨，我们已经见识了几种常见的类型问题，也即已经体验了JavaScript类型问题的恶果，接下来我们就来探讨一下JavaScript类型问题的恶因，即JavaScript语言本身是一种动态弱类型语言。在阐述他俩的因果关系之前，我们先来通过对比强类型语言和弱类型语言来理解JavaScript的弱类