起因是我加入了卡颂大佬的TS学习群，本以为自己也能坚持每日学习打卡，结果自己还是太年轻，经常被沉重的业务压的喘不过气，每天回家只想躺平。

现在稍微空闲一点了，决定还是利用碎片时间，强化自己的TS能力，拒绝做只会搬砖的码农！

我对TS的态度

很久以前我学习TS都是翻阅官方文档，去进行各种类型的浏览，以及在演练场操练。

殊不知这种学习方式其实并不会对我本身的TS能力有多大的提升，反而会让我觉得TS在我心里其实是一个可有可无的东西。因为简单的浏览完官方文档之后，我只会这么认为：哦，几个类型罢了，要用的时候在JS的基础上把他注明就好了。至于什么类型体操啥的

因为TS在界内其实一直都有人对其保持褒贬不一的态度，很多人认为TS只是徒增工作量罢了；也有人认为TS能够很好的保持代码的健壮性和可维护性。

而我本人对于TS其实是保持一个中立的态度，即如果我自己写代码，我可能会避重就轻，能不写就不写～

但是对于别人写的代码，我会认为：woc这写的什么鬼东西，都不用TS写类型注释的吗？这人太菜了，这代码肯定一堆bug～

“把TS当成一门新语言进行学习”

直到昨天在打卡群里看见卡颂大佬分享了他总结的一篇文章：

当时我心里就在想，woc，这不就是我现在被TS一直困惑住的现状吗？点开一看，果然卡颂大佬给了我想要的答案！

无可厚非，我本人在项目中写TS代码时，就是上面这种情况。文中提到个人认为最重要的一点就是：不要依赖JS的惯性思维去学习TS，而是要把TS当成一门新语言去重新进行学习。

当时看到这句话时简直醍醐灌顶！五雷轰顶！！是啊，JS、TS两者所处的代码维度并不是一致的，两者操作的基础细粒度也是不一样的：

JS：

• JS作为语言，操作的单位是变量，语法规范定义的是变量之间的操作逻辑，工作在代码运行时；

TS：

• TS作为语言，操作的单位是类型，语法规范定义的是类型之间的操作逻辑，工作在代码编译时；

如果我们都默认为，TS是JS的一个超集，TS的诞生只是为了补充JS所欠缺的类型系统，那就永远都学不好TS。我们始终都要认清一点：

TS是区别于JS的一门新语言，尽管它有补充JS类型系统的作用，但不要用JS先入为主，两者是不一样的概念。

所以，我也不再纠结于TS究竟是不是一门好语言了，因为凭我中立的态度，要求别人写代码需要用上TS，到头来自己却看不懂，那岂不是贼尴尬哈哈哈～因此也就有重新学习的必要了～

进入学习主题

关于如何正确的面对TS的弊端和益处，我想我跟作者是抱有相同态度的。

• 在小公司小项目中，可以选择不使用TS去影响开发效率并维持项目的灵活度；
• 反之，在比较大型的项目或是第三方库中，从长远角度着想，我们必须使用TS。

虽然这样可能会牺牲部分JS的灵活度，但取之而来的是更多正向的反馈。我们更多时候更需要TS的类型提示、类型推导以及类型精确的标注。这时候，我们更加可以凭借类型系统的辅助支持，在编程的过程中大展身手而不用担心代码的可维护性和健壮性，因为一切都会是符合预期的、都将是有迹可循的。

当然，这并不代表是在贬低那些不使用TS的项目或者支持不用TS的开发者们，正所谓各花入各眼，怎么样编程完全取决于每个人，编程是活的，不要被条条框框束缚死了。

关于TS带来的心智负担，我对TS的态度也是从这里发生改观。

里面有一个观点我非常认同：

我自认为我很菜，没有接触过很多高大上的性能优化的问题和场景。但我在浏览评论区的时候发现，其实大多数前端开发工程师在工作生涯中其实很少会接触到专门去做性能优化相关的需求，更多的还是出现了问题的时候，思考要如何去解决它。

那我认为，其实如果在开发阶段就可以通过一些手段去阻止性能问题、甚至是其他问题的出现的话，那我们为什么不采用呢？TS就是一个很好的例子呀难道不是吗？

关于如何系统的学习TS。

小册作者也给出了相当明确的学习路线：

我也是非常认同，首先我们就要非常熟练的认识到每一种类型，因为TS的操作单位它就是类型，只有把类型核心学习好了，才能进一步的学习TS的语法、工程等其他内容。

总结

最后，以上内容纯属作者自己本人发表的意见，不连带任何一方的因素。这个系列的内容只是用来记录我对这本小册的学习笔记而已，不要杠，你杠就是你对。