前端的小伙伴们，晚上好呀～结束了一天的搬砖，是不是感觉脑子有点沉甸甸的？别着急，咱今晚就用一道轻松的 TypeScript 面试题，给大脑来个温柔的按摩，既能放松心情，又能悄悄充充电，何乐而不为呢？

最近好多小伙伴跟我吐槽，说在面试的时候，遇到 TypeScript 的题目总是有点慌，尤其是面试官追着问类型推导、类型断言这些细节的时候，心里更是突突跳。别慌，今天这道题就专门针对咱们日常开发中特别容易踩坑的点，帮大家把基础打得更扎实。

类型断言的灵活运用

先来看题目：假设有一个函数，接收一个参数，这个参数可能是字符串，也可能是数字，我们需要在函数里判断它的类型，并返回不同的结果。如果是字符串，返回它的长度；如果是数字，返回它的平方。要求用 TypeScript 来实现，并且正确使用类型断言。

宝子们，别着急动手写代码，咱们先把思路理清楚。首先，参数的类型肯定是联合类型，也就是 string | number。那怎么判断它到底是字符串还是数字呢？在 JavaScript 里，我们可能会用 typeof，在 TypeScript 里也一样适用哦。接下来，重点就是类型断言的使用啦，这可是 TypeScript 里很重要的一个知识点，用好了能让代码更清晰，用不好可就容易出问题咯。

代码拆解：每一步都明明白白

// 定义一个函数，接收一个可能是字符串或数字的参数
function processValue(value: string | number) {
// 使用typeof来判断参数的类型
if (typeof value === 'string') {
// 这里使用类型断言，告诉TypeScript这个value现在就是字符串类型
return value.length; // 字符串的长度
} else {
// 否则就是数字类型，同样使用类型断言
return value * value; // 数字的平方
}
}

咱们来仔细看看这些注释哈。第一行定义函数，参数类型是联合类型，这是很常见的场景，咱们日常开发中经常会遇到需要处理多种类型的情况。然后用 typeof 来做类型判断，这是最直接的方法，简单又好用。在判断为字符串的分支里，类型断言就像是给 TypeScript 的一个提示，告诉它 “嘿，现在这个值就是字符串啦，你就按字符串来处理吧”，这样后面使用 length 属性的时候，就不会报错啦。数字分支也是一样的道理，断言之后，就可以放心地进行乘法运算啦。

面试官可能会这么问，咱也能轻松应对

问题一：为什么要用类型断言，不用不行吗？

宝子们，这时候咱就可以笑着跟面试官说：“当然可以不用啦，但用了类型断言能让代码更明确，更符合咱们的意图呀。比如说在这个例子里，虽然 typeof 已经做了判断，TypeScript 其实已经能推断出 value 在不同分支里的类型了，不过加上类型断言，能让代码的可读性更好，尤其是在更复杂的场景里，别人一看就知道咱们是故意让 TypeScript 按某种类型来处理的，减少误解。”

问题二：类型断言有几种方式呀？

这时候咱就可以掰着手指头数啦：“主要有两种方式哦，一种就是咱们刚才用的这种，像 < 类型> 值这样的写法，不过在 JSX 里不能这么用，得用另一种方式，就是值 as 类型。比如说在 React 里写 JSX 的时候，就得用 as 来做类型断言，这也是很常见的用法呢。”

问题三：类型断言会不会有风险呀？

咱就坦诚地说：“肯定是有一定风险的啦，如果咱们断言的类型和实际类型不一致，就会出问题啦。比如说如果一个值实际上是布尔类型，咱们却断言成字符串，那在访问 length 属性的时候就会报错啦。所以咱们用类型断言的时候，一定要确保断言的类型是合理的，最好是在有充分判断的情况下使用，就像咱们刚才的例子，先用 typeof 做了判断，再进行断言，这样就安全多啦。”

类型断言，是方便之门还是风险之源？

最后呢，咱们来聊个有意思的话题。有的小伙伴觉得，类型断言可太好用了，遇到类型问题，一断言就解决，简直是方便之门；可有的小伙伴却觉得，类型断言就像是一颗定时炸弹，用多了会让 TypeScript 的类型检查失去意义，增加代码的风险。那宝子们，你们在项目中是更倾向于严格的类型检查，尽量避免使用类型断言，还是觉得在合理的场景下，适当使用类型断言能提高开发效率呢？快来评论区说说你的看法吧，咱们一起讨论讨论～

好啦，今天的分享就到这里啦，希望这道题能让大家在放松的同时，又学到了一点新知识。如果觉得有用，别忘了点赞关注哦，以后每天晚上都会有一道这样的面试题，陪大家一起成长～

Tags：前端面试问题

微信扫一扫：分享

微信里点“发现”，扫一下

二维码便可将本文分享至朋友圈。