2026/8/31 19:14:32
FEATURED · 精选文章 
1. 面试开局TypeScript 到底解决了什么问题1.1 与 JavaScript 的本质差异别只说“多了类型”现在这个时间点准备前端面试基本绕不过 TypeScript 这道坎。不管是 React 还是 Vue 3简历上写着“熟悉 TypeScript”的人一抓一把但面试官随便往深里问一问能接住的人其实不多。大部分候选人开口就是“TypeScript 是 JavaScript 的超集多了类型系统”这句话没错但只说到这层基本等于没说。面试官想听的是“多了类型之后到底带来了什么改变”。这里要分清两个层面第一它把 JavaScript 从“运行时才能报错”变成了“编译时就能发现大量问题”第二它给开发过程加上了一套“契约体系”让代码的可读性、可维护性和协作效率都上了一个台阶。举个例子你在写一个 getUserInfo 接口的返回处理时JavaScript 里你只能靠文档或者“赌”后端返回的字段来写字段拼错了只能等运行时报 undefined但 TypeScript 可以直接定义一个 UserInfo 接口字段名错了、类型不对、可选属性没判断编译器立刻就会告诉你。这种体验上的差异才是 TypeScript 真正的价值所在。再说一个容易忽略的点TypeScript 不是“运行时的东西”。它的类型检查发生在编译阶段最终产物还是 JavaScript。这就意味着它不会让你的程序跑得更快也不会替代单元测试它的核心价值是“提前暴露低级错误 提升代码表达能力”。面试的时候如果能把这个边界说清楚会显得你是有实战经验的人而不是背了一堆概念。还有一个高频问题——TypeScript 和 JavaScript 在“开发体验”上的区别。TypeScript 最大的红利之一是编辑器提示。你写一个函数调用处能看到参数类型和返回值类型对象结构一目了然重构的时候也可以放心大胆地改。这个对我的日常开发影响特别大尤其在一个大型团队里别人写的代码你接手时类型就是最好的文档。1.2 类型系统里最基础的三个概念any、unknown、never面试官聊完概念之后十有八九会接着问类型系统的基础概念。这里我强烈建议你把 any、unknown、never 这三兄弟彻底搞明白它们几乎成了面试中的必考点而且特别能区分一个人是不是真的用过 TypeScript。先说说 any。它的意思是“放弃类型检查”相当于把一个变量丢进了一个没有规则的世界里。很多刚接触 TypeScript 的朋友喜欢用 any因为这最省事。我见过不少代码库一遇到复杂对象就“any 走天下”最后类型覆盖率低到可怜这等于掏钱买了 TypeScript 的票却一直坐在 JavaScript 的座位上。面试官问你 any 的问题时不要只说“它代表任意类型”要补充一句“它会破坏类型检查应该尽量少用”。如果他能继续问“什么时候适合用 any”你还可以说接入第三方无类型库的临时过渡、一些复杂的动态数据、以及一些实在无法穷举类型的边界场景。注意是“临时”和“过渡”。再说 unknown它是 TypeScript 3.0 引入的安全版 any。你可以给 unknown 赋任何值但你不能直接使用它——使用之前必须做类型收窄。比如let data: unknown fetchData(); // 报错data 类型是 unknown不能直接调用 length console.log(data.length); // 必须先收窄 if (typeof data string) { console.log(data.length); }这个设计非常符合工程直觉一个你完全不确定类型的值你不能从头到尾都不校验就乱用。一个常见的应用场景是处理 JSON.parse 的返回值或者捕获的异常对象。我在实际项目中会把任何“外部输入的不可控数据”标成 unknown然后再用类型守卫和收窄把它“降级”为具体类型这样既能保证安全又不会像 any 那样失去所有保护。最后是 never。它表示一个“永远不可能出现的类型”。最常见的场景是抛出异常的函数返回类型比如function throwError(message: string): never { throw new Error(message); }这个函数永远不会正常返回所以它的返回类型是 never。另一个场景是在穷举检查中使用 never比如你在 switch 语句的 default 分支里把一个变量赋给一个 never 类型如果某天有人给联合类型新增了一个成员而你没有在 switch 里补处理TypeScript 就会报错。这种写法能把“漏分支”的问题在编译期就暴露出来是很多资深开发者的习惯写法。记住一个判断技巧any 是把类型检查彻底关闭unknown 是“我还不知道它是什么但我不会乱用它”never 是“这里根本没有值”。三者搞清楚了面试中的基础类型题基本就能稳住。2. interface 与 type面试官最爱问的对比题2.1 核心区别与实际使用判断“interface 和 type 有什么区别”这个问题在我经历过的面试中出现频率非常高几乎每一次都会被问到。很多准备过面试的人能说出几条结论但说得不够系统。我们来把它彻底拆开。两者最大的区别有三个维度。第一是“声明合并declaration merging”interface 支持同名声明自动合并type 不支持。比如interface User { name: string; } interface User { age: number; } // User 最终同时拥有 name 和 age const user: User { name: Tom, age: 18 };这个特性在很多第三方库的类型扩展里很有用你不需要改动原来的库文件就能给它的接口类型追加字段。type 做不到这一点同名的 type 会直接报错。第二是“类型表达能力的侧重点”。type 别名更适合表示联合类型、交叉类型、元组、以及一些经过运算后得到的新类型。比如type Status success | error | loading; type ID string | number; type Coordinates [number, number]; type UserWithMeta User { createdAt: Date };这些用 interface 就很难优雅地表示。interface 则更擅长描述“对象的形状”——它用来定义一个对象有哪些属性、属性是什么类型、方法的方法签名。所以在“定义一个对象的形状”这个场景下两者都能用但在“组合出复杂类型”这个场景下type 几乎是唯一的选择。第三是“实现与继承的语义”。“interface”这个词本身就有“接口”的含义它天然适合被 class 去 implements。而 type 别名虽然也可以用来约束 class 的结构但语义上不如 interface 自然。比如写一个领域模型时定义“动物是一个接口狗是一个实现它的类”用 interface 就非常顺。我的实际使用习惯是能用 interface 描述对象形状时优先用 interface需要联合类型、条件类型、工具类型运算时用 type。面试官问到“你用哪个多”你可以给出这个决策逻辑而不是简单地说“我更喜欢 type”。2.2 高频变形题声明合并、索引签名、属性修饰基础对比答完之后面试官往往还会往下追几个细节最常出现的就是声明合并。除了上面展示的接口字段追加还有一个场景是在全局声明里扩展已有接口。比如在 Vue 3 项目里你可能会给全局的 Window 对象扩展自定义属性declare global { interface Window { __INITIAL_STATE__?: string; } }这其实就是在利用 interface 的声明合并能力。很多候选人知道 interface 能合并但不知道怎么用在真实场景里面试时如果能顺手举一个类似例子会比背概念加分很多。另一个高频点是索引签名。面试题常给一个对象类型要求补充索引签名比如interface StringArray { [index: number]: string; } interface Dictionary { [key: string]: unknown; }这里要注意一个细节当你同时定义索引签名和具体的属性时具体属性的类型必须兼容索引签名类型。比如索引签名是 string你就不能在这个 interface 里放一个 number 类型的属性否则编辑器直接报错。这也是一个常见的面试小陷阱。属性修饰方面只读属性readonly和可选属性?也是基础中的基础。readonly 不只是浅层的它只限制属性本身不能被重新赋值但对象内部嵌套的属性不受保护。比如interface Config { readonly settings: { theme: string }; } const config: Config { settings: { theme: dark } }; config.settings.theme light; // 允许因为 readonly 是浅层的 config.settings { theme: light }; // 报错不能重新赋值这个点很多人一开始会搞混面试中能主动把“readonly 是浅层约束”说出来会显得你是真的写过而不是背过。3. 泛型从会用到会讲3.1 为什么要用泛型一个场景讲透泛型是 TypeScript 面试的“分水岭”大部分答不上来的候选人都是卡在这一块。很多新手对泛型的第一印象是“看不懂”、“很绕”但如果我们不纠缠语法先想清楚“它到底解决什么问题”就很好理解了。看一个最简单的例子。你写了一个获取数组第一个元素的函数function firstElement(arr: number[]): number | undefined { return arr[0]; }这个函数只能处理 number 数组。如果换成 string 数组、对象数组你还得再写一份。这样代码会很冗余而一旦写成 any 就失去了类型保护。那怎么办用泛型function firstElementT(arr: T[]): T | undefined { return arr[0]; } const num firstElement([1, 2, 3]); // T 被推断为 number const str firstElement([a, b]); // T 被推断为 string这里面的 T 就像一个“类型占位符”它不指定固定的类型而是等到函数被调用时由传入的参数自动推断出来。泛型的核心思想就是“把类型参数化”让一个函数、接口或类能够适用于多种类型同时又不丢失类型信息。理解泛型最大的价值在于它把“通用”和“安全”这两件事结合到了一起。如果你不用泛型你就只能在“写死类型”和“any 放飞自我”之间二选一。而泛型让你可以写出既能通用于多种类型、又能在具体使用场景中保有精确类型约束的代码。面试时你可以用一个非常直观的话术来解释“泛型就是给类型也留了一个参数让调用方来决定这个类型参数到底是什么。”能讲到这个层面面试官通常就会觉得你是真懂的。3.2 泛型约束与工具类型实战泛型并不等于“万能的任何类型都可以往里塞”。很多时候你希望某个泛型参数“必须满足某些条件”这时候就需要用到泛型约束Generic Constraints。最常见的写法是用 extends 关键字。比如你想写一个函数来获取任意对象的所有属性值组成的数组但你希望传入的类型一定是一个对象类型function valuesOfT extends object(obj: T): ArrayT[keyof T] { return Object.values(obj) as ArrayT[keyof T]; }这里的T extends object就约束了 T 必须是对象类型。如果你传入一个 number编译器就会报错。extends 在这里不是“继承类”的意思而是一种“类型约束”表示 T 必须满足 object 这个条件的形状。再深入一点泛型约束可以配合 keyof 使用。keyof 是 TypeScript 的索引类型查询操作符它把一个对象类型的所有键取出来组成一个联合类型。比如interface Person { name: string; age: number; } type PersonKeys keyof Person; // name | age有了 keyof你可以实现一个非常经典的函数——安全地从对象中取属性值function getPropertyT, K extends keyof T(obj: T, key: K): T[K] { return obj[key]; } const person: Person { name: Tom, age: 18 }; const name getProperty(person, name); // string getProperty(person, email); // 报错因为 email 不是 Person 的键这个函数的好处是你传入了 Person 类型第二个参数就只能从 name 和 age 中选返回值类型也会自动对应取 name 时返回 string取 age 时返回 number。这个用法在实际项目中非常常见比如处理配置项、实现类型安全的表单字段读取等方向都能用上。3.3 面试答题如何从“会用”到“会讲”面试过程中泛型相关的题一般有两种问法一种是直接问“你用过泛型吗讲讲看”另一种是给你一段代码让你解释或改错。针对第一种建议准备一个“自己实际项目中的泛型封装”案例。比如你可以说项目里曾经封装过一个通用的分页请求函数interface PageResultT { list: T[]; total: number; page: number; pageSize: number; } async function fetchPageT(url: string, params: Recordstring, unknown): PromisePageResultT { const res await fetch(${url}?${new URLSearchParams(params)}); return res.json(); }这样调用时只要告诉它当前列表项的类型它就能返回一个结构完整、类型清晰的分页结果。这种“真实封装”的故事比解释概念有说服力得多。针对第二种改错题最常见的问题是“泛型没有约束导致类型太宽”。比如function getLengthT(arg: T): number { return arg.length; // 报错因为 T 上不一定有 length }正确做法是给 T 加上约束T extends { length: number }。如果面试官问“为什么要加约束”你要能答出“泛型参数在函数内部不具备具体类型的能力必须通过约束来收窄”。还有一个进阶知识点是泛型默认值Generic Defaults。定义一个泛型接口时如果调用方不传类型参数可以使用默认类型兜底interface ContainerT string { value: T; }这个在实际库的 API 设计中用得比较多面试中能提一嘴会显得你对泛型的理解有广度。4. 高级类型与类型编程4.1 条件类型与 inferTypeScript 类型的“运行时”如果面试进入第三轮大概率会碰到条件类型。条件类型听起来高大上其实本质就是“在类型层面写 if 判断”。它的语法长这样type IsStringT T extends string ? true : false; type A IsStringstring; // true type B IsStringnumber; // false这里T extends string不表示“T 是 string 的子类”而是表示“T 是否可以赋值给 string”。如果满足就返回 true否则返回 false。这就是条件类型的基本模式。面试中最经典的题目之一是“实现一个 type 工具把某个类型中的函数属性挑出来”或者“找出数组元素的类型”。这里最关键的是 infer 关键字。infer 的作用是“在条件类型中声明一个待推断的类型变量”让 TypeScript 自己从类型结构中去推断出某个部分。最经典的例子就是内置工具类型 ReturnTypetype MyReturnTypeT extends (...args: any) any T extends (...args: any) infer R ? R : never; type Fn (a: number) string; type Result MyReturnTypeFn; // string这段代码的意思是如果 T 是一个函数类型就把它的返回值类型提取到 R 里返回。infer R 就像在说“我不知道返回值具体是什么类型但你可以从 T 的结构里帮我推断出来”。面试中能手动实现 ReturnType、Parameters 这类内置工具类型是非常大的加分项。还有一道高频题提取数组里的元素类型。比如string[]里的 stringtype ArrayElementT T extends (infer U)[] ? U : never; type A ArrayElementstring[]; // string type B ArrayElement(number | boolean)[]; // number | boolean这个考点考察的是“能不能理解 infer 在条件类型里如何‘拆解’结构”。如果你能现场推导出来面试官基本就能确认你是真正写过类型编程代码的人。4.2 keyof、in 与映射类型的组合玩法映射类型Mapped Type是高级类型环节另一个绕不开的点。它的核心思路是“遍历已有的键生成一个新类型”。最常见的映射类型语法是type ReadonlyT { readonly [P in keyof T]: T[P]; };它把 T 的所有属性枚举出来然后加上 readonly 修饰符。这里的 in 有点像 JavaScript 里的 for...in表示“遍历 keyof T 得到的联合类型中的每一个键”。同理你也可以写一个将所有属性变为可选、变为必选、变为 null 等等的工具类型。面试中遇到映射类型题时有一个容易踩的坑对可选属性和 readonly 属性的“修饰符增删”语法。TypeScript 提供了-和前缀比如把一个类型的可选属性全部变成必选type RequiredT { [P in keyof T]-?: T[P]; };这个-?表示“去掉可选标记”。同理-readonly表示“去掉只读标记”。如果不加符号默认就是“加上修饰符”。这些细节在面试题中经常被用来区分候选人是否真的深入研究过而不是只会背工具类型。映射类型最常见的应用场景就是“基于已有类型派生新类型”。比如页面有一个表单的数据类型 FormState你需要一个“每个字段都只能被读取”的只读版本或者一个“每个字段都可以是 undefined”的编辑版本这时候用映射类型一行就能搞定而手动写一遍又累又容易漏。总的来说映射类型 keyof typeof 组合起来可以完成很多实用的类型变换。比如把 JavaScript 对象的 key 变成一个联合类型再基于它生成一个枚举对象。这类写法在大型项目中经常出现面试时展现出来会很有优势。4.3 内置工具类型的面试问答面试问到高级类型大概率会直接点名几个内置工具类型让你说说它们各自的作用。我把最常考的几个整理成了一张表建议直接背诵并理解其实现原理工具类型作用典型实现PartialT将 T 的所有属性变为可选{ [P in keyof T]?: T[P] }RequiredT将 T 的所有属性变为必选{ [P in keyof T]-?: T[P] }ReadonlyT将 T 的所有属性变为只读{ readonly [P in keyof T]: T[P] }PickT, K从 T 中挑选一组属性{ [P in K]: T[P] }OmitT, K从 T 中排除一组属性PickT, Excludekeyof T, KRecordK, V构建一个键为 K、值为 V 的对象类型{ [P in K]: V }ExcludeT, U从联合类型 T 中排除 UT extends U ? never : TExtractT, U从联合类型 T 中提取 U 中存在的部分T extends U ? T : neverReturnTypeT获取函数 T 的返回类型T extends (...args: any) infer R ? R : anyParametersT获取函数 T 的参数元组类型T extends (...args: infer P) any ? P : never表格右上角那几个工具类型在项目中使用频率最高。比如你从后端拿到一个 User 对象但创建用户时只需要 name 和 email就可以用 Pick 来声明创建表单的类型。而当你需要排除掉 id、createdAt 等字段时就用 Omit。面试官追问时你要能说清楚 Exclude 和 Omit 的关系Omit 内部使用了 Exclude。这能证明你不仅会用名字还看得懂它们内部的联系。另一个常见追问是 ReturnType 和 Parameters 的区别以及它们的实现原理都要能现场推导。能把这十个工具类型脱稿写出来这部分的胜率会大幅度提升。5. 类型推断、断言与兼容性5.1 类型推断规则与上下文推断基础题答完之后面试官经常会出一些“这段代码的类型是什么”的推断题。这主要是考察你对 TypeScript 类型推断规则的掌握程度。TypeScript 的类型推断有个基本原则如果变量有显式类型注解就以注解为准如果没有就根据初始值自动推断。比如let a 1; // 推断为 number const b 1; // 推断为 1这是一个字面量类型 let arr [1, a]; // 推断为 (string | number)[]这里有一个很多人容易忽略的点const 声明的变量默认被推断为字面量类型而 let 声明的变量则被拓宽为基本类型。因为你不能重新给 const 赋值所以 TypeScript 可以更精确地把它推断成 1 而不是 number。而 let 变量可能后续被重新赋值比如从 1 变成 2所以必须放宽成 number。另一种常见推断叫“上下文类型Contextual Typing”。当函数表达式被赋值给一个已知类型的位置时TypeScript 会从左到右把类型“传递”进去让我们不需要写参数类型就能得到类型检查。比如const handler: (event: MouseEvent) void (e) { // e 被自动推断为 MouseEvent };const 声明的对象属性也有特殊的推断规则它会保留属性的“精确字面量状态”。这也是为什么很多人用 as const 来把一个对象变成只读并保留最精确类型的原因。5.2 类型断言的正确姿势与 as const类型断言Type Assertion是面试题里的常客也是实际项目中用得最“危险”的功能之一。它的作用是“告诉 TypeScript我知道这里比你推断的更具体”。语法有两种// 方式一尖括号在 .tsx 文件里会与 JSX 冲突 let value: unknown hello; let len (value as string).length; // 方式二as 语法 let len2 (value as string).length;需要注意的是类型断言不是“类型转换”它不会在运行时做任何操作只是让编译器按你断言的类型来检查。如果你断言错的类型运行时并不会帮你纠正该报错照样报错。比如let value: unknown 123; let len (value as string).length; // 编译通过但运行时 len 是 undefined这种“编译过了但运行崩了”的情况是面试官特别喜欢拿来提问的。一个更好的替代方案是使用类型守卫Type Guardif (typeof value string) { console.log(value.length); }这样既做了运行时校验又实现了类型收窄安全得多。as const 是 TypeScript 3.4 引入的语法它能让一个变量的所有属性都被推断为最精确的字面量类型并且整个对象变成 readonly。比如const config { name: app, version: 1, } as const; // 推断类型是{ readonly name: app; readonly version: 1 }这在一些需要“常量枚举”和“字面量联合类型”的场景中很常用。面试时如果能自然地说出 as const 的用途和限制只能作用于字面量表达式不能让非常量类型也变只读会显得你对新特性很敏感。5.3 结构化类型系统与“鸭子类型”最后聊一个 TypeScript 类型系统的底层哲学结构化类型Structural Typing。面试中常见的描述是“TypeScript 是鸭子类型——如果一个东西长得像鸭子、叫起来像鸭子那它就是鸭子”。这句话翻译成类型系统的语言就是两个类型是否兼容取决于它们的结构是否兼容而不是取决于它们有没有显式地继承自同一个父类。举个例子interface Dog { name: string; } interface Cat { name: string; } let dog: Dog { name: 旺财 }; let cat: Cat dog; // 类型结构相同可以互相赋值Dog 和 Cat 虽然“名称”不同但因为结构相同在 TypeScript 眼中它们就是兼容的。这在很多后端转前端的开发者看来会觉得难以理解毕竟 Java 或 C# 这类语言是典型的“标称类型系统”Nominal Typing两个类即使字段完全一致也不是同一个类型。结构化类型带来了极大的灵活性但也带来了一些问题最常见的是函数参数兼容的坑。比如你有一个函数接收一个{ name: string }类型的参数当你传入一个拥有额外属性的对象字面量时TypeScript 会做“多余属性检查Excess Property Check”直接报错interface Person { name: string; } function greet(person: Person) {} greet({ name: Tom, age: 18 }); // 报错对象字面量只能指定已知属性但如果这个对象不是字面量而是先赋值给了一个变量就不会报错const person { name: Tom, age: 18 }; greet(person); // 可以通过因为 person 结构包含了 greet 所需的 name这个差异在面试题中出现频率非常高背后体现的正是结构化类型与多余属性检查的博弈。讲清楚这一点基本上就可以证明你真的理解 TypeScript 的类型系统了。6. 工程化与配置实战6.1 tsconfig.json 核心配置项面试如果不是纯考理论大概率会问你项目里是怎么配置 TypeScript 的。你不需要把 tsconfig 里几十个选项全背下来但几个核心配置必须心里有数。我推荐直接记住一个“2023 年后主流模板”的配置长什么样{ compilerOptions: { target: ES2020, module: ESNext, moduleResolution: bundler, strict: true, jsx: preserve, esModuleInterop: true, skipLibCheck: true, forceConsistentCasingInFileNames: true, resolveJsonModule: true, isolatedModules: true, noEmit: true }, include: [src/**/*.ts, src/**/*.tsx, src/**/*.vue] }这里逐个说一下关键项target 决定编译到哪个 ECMAScript 版本影响生成 JS 的语法级别module 决定模块系统Vite 项目一般用 ESNextmoduleResolution 决定模块解析策略如果你用的打包器是 Vite 或 webpack建议直接配成 bundlerTS 5.0 之后新增strict 是总开关打开之后会同时启用 noImplicitAny、strictNullChecks 等一系列严格检查这是 TypeScript 最大的卖点建议一律开启。还有一个最近很热的话题baseUrl在 TypeScript 7.0 中即将废弃。我在升级项目依赖时也看到过编译器提示“Option baseurl is deprecated and will stop functioning in typescript 7.0. Specify compilerOption paths to use path mapping without baseurl”。这意味着旧项目中baseUrl: ./src的写法迟早要改。迁移方式也很简单以前依赖 baseUrl 的“快捷路径导入”可以改成直接使用 paths并在 paths 里写完整相对路径。目前 Vite 项目里比较推荐的做法是配合 vite-tsconfig-paths 插件让编译器和打包器都认识这些路径别名逐步减少对 baseUrl 的依赖。6.2 声明文件 .d.ts 的编写面试中还有一种非常实际的问题你引入一个没有类型定义的第三方 JS 库时怎么办答不上来的人会说“直接用 any”但更好的答案是“写一个声明文件”。声明文件通常放在项目的 types 目录里或者和源码放一起文件名以.d.ts结尾。最简单的形式declare module some-untyped-lib { export function doSomething(input: string): number; export const version: string; }如果你的项目里没有 types 配置TypeScript 也会默认加载 src 下所有.d.ts文件。对于全局变量类型的声明可以直接这样写declare global { interface Window { __MY_CUSTOM_FLAG__?: boolean; } }还有一种情况是给图片、CSS 模块等非代码文件声明类型。比如在 Vite 项目里通常会有个env.d.tsdeclare module *.vue { import type { DefineComponent } from vue; const component: DefineComponent{}, {}, any; export default component; }面试时最好能主动说出“声明文件是给 JavaScript 模块补类型说明不需要任何运行时逻辑”这句话会显得你对构建链路有完整的理解。6.3 在 Vue3/React 中的实际应用最后聊一下 TypeScript 在前端框架里的实战考察。如果你面的是 Vue 3 岗位大概率会问组合式 API 中如何给 props 定义类型。正确写法是defineProps{ title: string; count?: number; }();在 Vue 3.3 之后甚至可以直接从外部导入类型import type { Props } from ./types; definePropsProps();如果面 React则会考察函数组件的 Props 类型定义、useState 的泛型推导、useRef 的类型处理等。比如 useRef 有一个经典的坑useRefHTMLDivElement(null)返回的类型是一个可变的 RefObject而useRefHTMLDivElement | null(null)在某些情况下也会有不同的行为。要能分清这些细微差别需要一定的 React TypeScript 的实操经验。还有一个值得说的点是“类型安全和数据请求”结合的场景。我在实际项目里会把 API 函数的返回类型和前端状态类型统一定义这样后端字段变更时前端在编译期就能发现哪些地方需要修改。这虽然不算是纯粹的面试题但如果你能在面试中说出自己“用 TypeScript 规范接口字段、减少联调事故”的真实经历面试官对你的印象一定会加分。7. 面试中几个常见陷阱与答题建议7.1 八股背后的思考方式2023 年之后的面试越来越不喜欢“背题式候选人”。同一个 TypeScript 面试题背过八股的人和真正写过的人回答时的颗粒度是完全不一样的。我特别建议大家准备面试时不要只背结论而是把每个结论背后的“为什么”顺一遍。比如“interface 能声明合并”这个结论你可以继续问自己“为什么 TypeScript 要设计声明合并它对哪些场景有帮助”如果你想不出应用场景可以去看 Express、Vue Router 这类流行库的类型定义你会发现很多都是靠声明合并来扩展的。再比如“泛型能保证类型安全”你可以在自己项目里找一找哪些函数是“不用泛型就得写重复代码”的——列表筛选、分页请求、状态管理模块的 action 定义。把这些真实案例整理成自己的语料面试时随取随用比对着文档念十遍都有效。7.2 避坑常见误区最后整理几个我面试别人时经常遇到的误区希望大家不要踩第一把 any 当成解决问题的万能钥匙。面试官问你对某个类型问题的解决方案时不要开口就是“用 any”这基本等于告诉对方你还没想明白可替代的方案。可以换成“先用 unknown 收窄或者在边界场景临时断言”观感会完全不同。第二混淆类型和值。“interface Person 里的 Person 是一个类型不是一个值”这类基础概念出错的话打击是致命的。面试官可能会出一些判断题比如“typeof 一个 interface 类型可以吗”答案是不行因为 interface 在编译后完全被擦除运行时拿不到它。第三忽略 strictNullChecks 的影响。很多人都知道 strict 模式要开但不一定意识到 strictNullChecks 开启后string和string | null是完全不同的类型。比如let name: string | null null; let length name.length; // 报错需要先判空一旦你习惯在 strict 模式下写代码很多“运行时突然报 undefined”的问题都能在编译期被发现。面试时提到这一点也是加分项。第四不知道“类型编程”和“业务逻辑”之间的度。类型写得太复杂会让团队其他人难以维护这也是一种坏味道。面试时可以透露自己对“过度设计”的警惕说“类型应该以表达业务约束为度不是越花哨越好”这通常会是一个很好的收尾观点。我个人在实际面试中的体会是能从“TypeScript 是 JavaScript 的超集”一直讲到底层类型系统的设计哲学、再到工程配置落地的人和只会背一堆工具类型名字的人差距一眼就能看出来。准备面试题并不可怕关键是别把“背八股”当成目的而是借这个过程把平时没想明白的类型设计问题彻底捋一遍。这套底子打好了不光是面试日常写代码的效率也会提升一大截。
TypeScript面试通关指南：类型系统、泛型与工程实践精讲
1. 面试开局TypeScript 到底解决了什么问题1.1 与 JavaScript 的本质差异别只说“多了类型”现在这个时间点准备前端面试基本绕不过 TypeScript 这道坎。不管是 React 还是 Vue 3简历上写着“熟悉 TypeScript”的人一抓一把但面试官随便往深里问一问能接住的人其实不多。大部分候选人开口就是“TypeScript 是 JavaScript 的超集多了类型系统”这句话没错但只说到这层基本等于没说。面试官想听的是“多了类型之后到底带来了什么改变”。这里要分清两个层面第一它把 JavaScript 从“运行时才能报错”变成了“编译时就能发现大量问题”第二它给开发过程加上了一套“契约体系”让代码的可读性、可维护性和协作效率都上了一个台阶。举个例子你在写一个 getUserInfo 接口的返回处理时JavaScript 里你只能靠文档或者“赌”后端返回的字段来写字段拼错了只能等运行时报 undefined但 TypeScript 可以直接定义一个 UserInfo 接口字段名错了、类型不对、可选属性没判断编译器立刻就会告诉你。这种体验上的差异才是 TypeScript 真正的价值所在。再说一个容易忽略的点TypeScript 不是“运行时的东西”。它的类型检查发生在编译阶段最终产物还是 JavaScript。这就意味着它不会让你的程序跑得更快也不会替代单元测试它的核心价值是“提前暴露低级错误 提升代码表达能力”。面试的时候如果能把这个边界说清楚会显得你是有实战经验的人而不是背了一堆概念。还有一个高频问题——TypeScript 和 JavaScript 在“开发体验”上的区别。TypeScript 最大的红利之一是编辑器提示。你写一个函数调用处能看到参数类型和返回值类型对象结构一目了然重构的时候也可以放心大胆地改。这个对我的日常开发影响特别大尤其在一个大型团队里别人写的代码你接手时类型就是最好的文档。1.2 类型系统里最基础的三个概念any、unknown、never面试官聊完概念之后十有八九会接着问类型系统的基础概念。这里我强烈建议你把 any、unknown、never 这三兄弟彻底搞明白它们几乎成了面试中的必考点而且特别能区分一个人是不是真的用过 TypeScript。先说说 any。它的意思是“放弃类型检查”相当于把一个变量丢进了一个没有规则的世界里。很多刚接触 TypeScript 的朋友喜欢用 any因为这最省事。我见过不少代码库一遇到复杂对象就“any 走天下”最后类型覆盖率低到可怜这等于掏钱买了 TypeScript 的票却一直坐在 JavaScript 的座位上。面试官问你 any 的问题时不要只说“它代表任意类型”要补充一句“它会破坏类型检查应该尽量少用”。如果他能继续问“什么时候适合用 any”你还可以说接入第三方无类型库的临时过渡、一些复杂的动态数据、以及一些实在无法穷举类型的边界场景。注意是“临时”和“过渡”。再说 unknown它是 TypeScript 3.0 引入的安全版 any。你可以给 unknown 赋任何值但你不能直接使用它——使用之前必须做类型收窄。比如let data: unknown fetchData(); // 报错data 类型是 unknown不能直接调用 length console.log(data.length); // 必须先收窄 if (typeof data string) { console.log(data.length); }这个设计非常符合工程直觉一个你完全不确定类型的值你不能从头到尾都不校验就乱用。一个常见的应用场景是处理 JSON.parse 的返回值或者捕获的异常对象。我在实际项目中会把任何“外部输入的不可控数据”标成 unknown然后再用类型守卫和收窄把它“降级”为具体类型这样既能保证安全又不会像 any 那样失去所有保护。最后是 never。它表示一个“永远不可能出现的类型”。最常见的场景是抛出异常的函数返回类型比如function throwError(message: string): never { throw new Error(message); }这个函数永远不会正常返回所以它的返回类型是 never。另一个场景是在穷举检查中使用 never比如你在 switch 语句的 default 分支里把一个变量赋给一个 never 类型如果某天有人给联合类型新增了一个成员而你没有在 switch 里补处理TypeScript 就会报错。这种写法能把“漏分支”的问题在编译期就暴露出来是很多资深开发者的习惯写法。记住一个判断技巧any 是把类型检查彻底关闭unknown 是“我还不知道它是什么但我不会乱用它”never 是“这里根本没有值”。三者搞清楚了面试中的基础类型题基本就能稳住。2. interface 与 type面试官最爱问的对比题2.1 核心区别与实际使用判断“interface 和 type 有什么区别”这个问题在我经历过的面试中出现频率非常高几乎每一次都会被问到。很多准备过面试的人能说出几条结论但说得不够系统。我们来把它彻底拆开。两者最大的区别有三个维度。第一是“声明合并declaration merging”interface 支持同名声明自动合并type 不支持。比如interface User { name: string; } interface User { age: number; } // User 最终同时拥有 name 和 age const user: User { name: Tom, age: 18 };这个特性在很多第三方库的类型扩展里很有用你不需要改动原来的库文件就能给它的接口类型追加字段。type 做不到这一点同名的 type 会直接报错。第二是“类型表达能力的侧重点”。type 别名更适合表示联合类型、交叉类型、元组、以及一些经过运算后得到的新类型。比如type Status success | error | loading; type ID string | number; type Coordinates [number, number]; type UserWithMeta User { createdAt: Date };这些用 interface 就很难优雅地表示。interface 则更擅长描述“对象的形状”——它用来定义一个对象有哪些属性、属性是什么类型、方法的方法签名。所以在“定义一个对象的形状”这个场景下两者都能用但在“组合出复杂类型”这个场景下type 几乎是唯一的选择。第三是“实现与继承的语义”。“interface”这个词本身就有“接口”的含义它天然适合被 class 去 implements。而 type 别名虽然也可以用来约束 class 的结构但语义上不如 interface 自然。比如写一个领域模型时定义“动物是一个接口狗是一个实现它的类”用 interface 就非常顺。我的实际使用习惯是能用 interface 描述对象形状时优先用 interface需要联合类型、条件类型、工具类型运算时用 type。面试官问到“你用哪个多”你可以给出这个决策逻辑而不是简单地说“我更喜欢 type”。2.2 高频变形题声明合并、索引签名、属性修饰基础对比答完之后面试官往往还会往下追几个细节最常出现的就是声明合并。除了上面展示的接口字段追加还有一个场景是在全局声明里扩展已有接口。比如在 Vue 3 项目里你可能会给全局的 Window 对象扩展自定义属性declare global { interface Window { __INITIAL_STATE__?: string; } }这其实就是在利用 interface 的声明合并能力。很多候选人知道 interface 能合并但不知道怎么用在真实场景里面试时如果能顺手举一个类似例子会比背概念加分很多。另一个高频点是索引签名。面试题常给一个对象类型要求补充索引签名比如interface StringArray { [index: number]: string; } interface Dictionary { [key: string]: unknown; }这里要注意一个细节当你同时定义索引签名和具体的属性时具体属性的类型必须兼容索引签名类型。比如索引签名是 string你就不能在这个 interface 里放一个 number 类型的属性否则编辑器直接报错。这也是一个常见的面试小陷阱。属性修饰方面只读属性readonly和可选属性?也是基础中的基础。readonly 不只是浅层的它只限制属性本身不能被重新赋值但对象内部嵌套的属性不受保护。比如interface Config { readonly settings: { theme: string }; } const config: Config { settings: { theme: dark } }; config.settings.theme light; // 允许因为 readonly 是浅层的 config.settings { theme: light }; // 报错不能重新赋值这个点很多人一开始会搞混面试中能主动把“readonly 是浅层约束”说出来会显得你是真的写过而不是背过。3. 泛型从会用到会讲3.1 为什么要用泛型一个场景讲透泛型是 TypeScript 面试的“分水岭”大部分答不上来的候选人都是卡在这一块。很多新手对泛型的第一印象是“看不懂”、“很绕”但如果我们不纠缠语法先想清楚“它到底解决什么问题”就很好理解了。看一个最简单的例子。你写了一个获取数组第一个元素的函数function firstElement(arr: number[]): number | undefined { return arr[0]; }这个函数只能处理 number 数组。如果换成 string 数组、对象数组你还得再写一份。这样代码会很冗余而一旦写成 any 就失去了类型保护。那怎么办用泛型function firstElementT(arr: T[]): T | undefined { return arr[0]; } const num firstElement([1, 2, 3]); // T 被推断为 number const str firstElement([a, b]); // T 被推断为 string这里面的 T 就像一个“类型占位符”它不指定固定的类型而是等到函数被调用时由传入的参数自动推断出来。泛型的核心思想就是“把类型参数化”让一个函数、接口或类能够适用于多种类型同时又不丢失类型信息。理解泛型最大的价值在于它把“通用”和“安全”这两件事结合到了一起。如果你不用泛型你就只能在“写死类型”和“any 放飞自我”之间二选一。而泛型让你可以写出既能通用于多种类型、又能在具体使用场景中保有精确类型约束的代码。面试时你可以用一个非常直观的话术来解释“泛型就是给类型也留了一个参数让调用方来决定这个类型参数到底是什么。”能讲到这个层面面试官通常就会觉得你是真懂的。3.2 泛型约束与工具类型实战泛型并不等于“万能的任何类型都可以往里塞”。很多时候你希望某个泛型参数“必须满足某些条件”这时候就需要用到泛型约束Generic Constraints。最常见的写法是用 extends 关键字。比如你想写一个函数来获取任意对象的所有属性值组成的数组但你希望传入的类型一定是一个对象类型function valuesOfT extends object(obj: T): ArrayT[keyof T] { return Object.values(obj) as ArrayT[keyof T]; }这里的T extends object就约束了 T 必须是对象类型。如果你传入一个 number编译器就会报错。extends 在这里不是“继承类”的意思而是一种“类型约束”表示 T 必须满足 object 这个条件的形状。再深入一点泛型约束可以配合 keyof 使用。keyof 是 TypeScript 的索引类型查询操作符它把一个对象类型的所有键取出来组成一个联合类型。比如interface Person { name: string; age: number; } type PersonKeys keyof Person; // name | age有了 keyof你可以实现一个非常经典的函数——安全地从对象中取属性值function getPropertyT, K extends keyof T(obj: T, key: K): T[K] { return obj[key]; } const person: Person { name: Tom, age: 18 }; const name getProperty(person, name); // string getProperty(person, email); // 报错因为 email 不是 Person 的键这个函数的好处是你传入了 Person 类型第二个参数就只能从 name 和 age 中选返回值类型也会自动对应取 name 时返回 string取 age 时返回 number。这个用法在实际项目中非常常见比如处理配置项、实现类型安全的表单字段读取等方向都能用上。3.3 面试答题如何从“会用”到“会讲”面试过程中泛型相关的题一般有两种问法一种是直接问“你用过泛型吗讲讲看”另一种是给你一段代码让你解释或改错。针对第一种建议准备一个“自己实际项目中的泛型封装”案例。比如你可以说项目里曾经封装过一个通用的分页请求函数interface PageResultT { list: T[]; total: number; page: number; pageSize: number; } async function fetchPageT(url: string, params: Recordstring, unknown): PromisePageResultT { const res await fetch(${url}?${new URLSearchParams(params)}); return res.json(); }这样调用时只要告诉它当前列表项的类型它就能返回一个结构完整、类型清晰的分页结果。这种“真实封装”的故事比解释概念有说服力得多。针对第二种改错题最常见的问题是“泛型没有约束导致类型太宽”。比如function getLengthT(arg: T): number { return arg.length; // 报错因为 T 上不一定有 length }正确做法是给 T 加上约束T extends { length: number }。如果面试官问“为什么要加约束”你要能答出“泛型参数在函数内部不具备具体类型的能力必须通过约束来收窄”。还有一个进阶知识点是泛型默认值Generic Defaults。定义一个泛型接口时如果调用方不传类型参数可以使用默认类型兜底interface ContainerT string { value: T; }这个在实际库的 API 设计中用得比较多面试中能提一嘴会显得你对泛型的理解有广度。4. 高级类型与类型编程4.1 条件类型与 inferTypeScript 类型的“运行时”如果面试进入第三轮大概率会碰到条件类型。条件类型听起来高大上其实本质就是“在类型层面写 if 判断”。它的语法长这样type IsStringT T extends string ? true : false; type A IsStringstring; // true type B IsStringnumber; // false这里T extends string不表示“T 是 string 的子类”而是表示“T 是否可以赋值给 string”。如果满足就返回 true否则返回 false。这就是条件类型的基本模式。面试中最经典的题目之一是“实现一个 type 工具把某个类型中的函数属性挑出来”或者“找出数组元素的类型”。这里最关键的是 infer 关键字。infer 的作用是“在条件类型中声明一个待推断的类型变量”让 TypeScript 自己从类型结构中去推断出某个部分。最经典的例子就是内置工具类型 ReturnTypetype MyReturnTypeT extends (...args: any) any T extends (...args: any) infer R ? R : never; type Fn (a: number) string; type Result MyReturnTypeFn; // string这段代码的意思是如果 T 是一个函数类型就把它的返回值类型提取到 R 里返回。infer R 就像在说“我不知道返回值具体是什么类型但你可以从 T 的结构里帮我推断出来”。面试中能手动实现 ReturnType、Parameters 这类内置工具类型是非常大的加分项。还有一道高频题提取数组里的元素类型。比如string[]里的 stringtype ArrayElementT T extends (infer U)[] ? U : never; type A ArrayElementstring[]; // string type B ArrayElement(number | boolean)[]; // number | boolean这个考点考察的是“能不能理解 infer 在条件类型里如何‘拆解’结构”。如果你能现场推导出来面试官基本就能确认你是真正写过类型编程代码的人。4.2 keyof、in 与映射类型的组合玩法映射类型Mapped Type是高级类型环节另一个绕不开的点。它的核心思路是“遍历已有的键生成一个新类型”。最常见的映射类型语法是type ReadonlyT { readonly [P in keyof T]: T[P]; };它把 T 的所有属性枚举出来然后加上 readonly 修饰符。这里的 in 有点像 JavaScript 里的 for...in表示“遍历 keyof T 得到的联合类型中的每一个键”。同理你也可以写一个将所有属性变为可选、变为必选、变为 null 等等的工具类型。面试中遇到映射类型题时有一个容易踩的坑对可选属性和 readonly 属性的“修饰符增删”语法。TypeScript 提供了-和前缀比如把一个类型的可选属性全部变成必选type RequiredT { [P in keyof T]-?: T[P]; };这个-?表示“去掉可选标记”。同理-readonly表示“去掉只读标记”。如果不加符号默认就是“加上修饰符”。这些细节在面试题中经常被用来区分候选人是否真的深入研究过而不是只会背工具类型。映射类型最常见的应用场景就是“基于已有类型派生新类型”。比如页面有一个表单的数据类型 FormState你需要一个“每个字段都只能被读取”的只读版本或者一个“每个字段都可以是 undefined”的编辑版本这时候用映射类型一行就能搞定而手动写一遍又累又容易漏。总的来说映射类型 keyof typeof 组合起来可以完成很多实用的类型变换。比如把 JavaScript 对象的 key 变成一个联合类型再基于它生成一个枚举对象。这类写法在大型项目中经常出现面试时展现出来会很有优势。4.3 内置工具类型的面试问答面试问到高级类型大概率会直接点名几个内置工具类型让你说说它们各自的作用。我把最常考的几个整理成了一张表建议直接背诵并理解其实现原理工具类型作用典型实现PartialT将 T 的所有属性变为可选{ [P in keyof T]?: T[P] }RequiredT将 T 的所有属性变为必选{ [P in keyof T]-?: T[P] }ReadonlyT将 T 的所有属性变为只读{ readonly [P in keyof T]: T[P] }PickT, K从 T 中挑选一组属性{ [P in K]: T[P] }OmitT, K从 T 中排除一组属性PickT, Excludekeyof T, KRecordK, V构建一个键为 K、值为 V 的对象类型{ [P in K]: V }ExcludeT, U从联合类型 T 中排除 UT extends U ? never : TExtractT, U从联合类型 T 中提取 U 中存在的部分T extends U ? T : neverReturnTypeT获取函数 T 的返回类型T extends (...args: any) infer R ? R : anyParametersT获取函数 T 的参数元组类型T extends (...args: infer P) any ? P : never表格右上角那几个工具类型在项目中使用频率最高。比如你从后端拿到一个 User 对象但创建用户时只需要 name 和 email就可以用 Pick 来声明创建表单的类型。而当你需要排除掉 id、createdAt 等字段时就用 Omit。面试官追问时你要能说清楚 Exclude 和 Omit 的关系Omit 内部使用了 Exclude。这能证明你不仅会用名字还看得懂它们内部的联系。另一个常见追问是 ReturnType 和 Parameters 的区别以及它们的实现原理都要能现场推导。能把这十个工具类型脱稿写出来这部分的胜率会大幅度提升。5. 类型推断、断言与兼容性5.1 类型推断规则与上下文推断基础题答完之后面试官经常会出一些“这段代码的类型是什么”的推断题。这主要是考察你对 TypeScript 类型推断规则的掌握程度。TypeScript 的类型推断有个基本原则如果变量有显式类型注解就以注解为准如果没有就根据初始值自动推断。比如let a 1; // 推断为 number const b 1; // 推断为 1这是一个字面量类型 let arr [1, a]; // 推断为 (string | number)[]这里有一个很多人容易忽略的点const 声明的变量默认被推断为字面量类型而 let 声明的变量则被拓宽为基本类型。因为你不能重新给 const 赋值所以 TypeScript 可以更精确地把它推断成 1 而不是 number。而 let 变量可能后续被重新赋值比如从 1 变成 2所以必须放宽成 number。另一种常见推断叫“上下文类型Contextual Typing”。当函数表达式被赋值给一个已知类型的位置时TypeScript 会从左到右把类型“传递”进去让我们不需要写参数类型就能得到类型检查。比如const handler: (event: MouseEvent) void (e) { // e 被自动推断为 MouseEvent };const 声明的对象属性也有特殊的推断规则它会保留属性的“精确字面量状态”。这也是为什么很多人用 as const 来把一个对象变成只读并保留最精确类型的原因。5.2 类型断言的正确姿势与 as const类型断言Type Assertion是面试题里的常客也是实际项目中用得最“危险”的功能之一。它的作用是“告诉 TypeScript我知道这里比你推断的更具体”。语法有两种// 方式一尖括号在 .tsx 文件里会与 JSX 冲突 let value: unknown hello; let len (value as string).length; // 方式二as 语法 let len2 (value as string).length;需要注意的是类型断言不是“类型转换”它不会在运行时做任何操作只是让编译器按你断言的类型来检查。如果你断言错的类型运行时并不会帮你纠正该报错照样报错。比如let value: unknown 123; let len (value as string).length; // 编译通过但运行时 len 是 undefined这种“编译过了但运行崩了”的情况是面试官特别喜欢拿来提问的。一个更好的替代方案是使用类型守卫Type Guardif (typeof value string) { console.log(value.length); }这样既做了运行时校验又实现了类型收窄安全得多。as const 是 TypeScript 3.4 引入的语法它能让一个变量的所有属性都被推断为最精确的字面量类型并且整个对象变成 readonly。比如const config { name: app, version: 1, } as const; // 推断类型是{ readonly name: app; readonly version: 1 }这在一些需要“常量枚举”和“字面量联合类型”的场景中很常用。面试时如果能自然地说出 as const 的用途和限制只能作用于字面量表达式不能让非常量类型也变只读会显得你对新特性很敏感。5.3 结构化类型系统与“鸭子类型”最后聊一个 TypeScript 类型系统的底层哲学结构化类型Structural Typing。面试中常见的描述是“TypeScript 是鸭子类型——如果一个东西长得像鸭子、叫起来像鸭子那它就是鸭子”。这句话翻译成类型系统的语言就是两个类型是否兼容取决于它们的结构是否兼容而不是取决于它们有没有显式地继承自同一个父类。举个例子interface Dog { name: string; } interface Cat { name: string; } let dog: Dog { name: 旺财 }; let cat: Cat dog; // 类型结构相同可以互相赋值Dog 和 Cat 虽然“名称”不同但因为结构相同在 TypeScript 眼中它们就是兼容的。这在很多后端转前端的开发者看来会觉得难以理解毕竟 Java 或 C# 这类语言是典型的“标称类型系统”Nominal Typing两个类即使字段完全一致也不是同一个类型。结构化类型带来了极大的灵活性但也带来了一些问题最常见的是函数参数兼容的坑。比如你有一个函数接收一个{ name: string }类型的参数当你传入一个拥有额外属性的对象字面量时TypeScript 会做“多余属性检查Excess Property Check”直接报错interface Person { name: string; } function greet(person: Person) {} greet({ name: Tom, age: 18 }); // 报错对象字面量只能指定已知属性但如果这个对象不是字面量而是先赋值给了一个变量就不会报错const person { name: Tom, age: 18 }; greet(person); // 可以通过因为 person 结构包含了 greet 所需的 name这个差异在面试题中出现频率非常高背后体现的正是结构化类型与多余属性检查的博弈。讲清楚这一点基本上就可以证明你真的理解 TypeScript 的类型系统了。6. 工程化与配置实战6.1 tsconfig.json 核心配置项面试如果不是纯考理论大概率会问你项目里是怎么配置 TypeScript 的。你不需要把 tsconfig 里几十个选项全背下来但几个核心配置必须心里有数。我推荐直接记住一个“2023 年后主流模板”的配置长什么样{ compilerOptions: { target: ES2020, module: ESNext, moduleResolution: bundler, strict: true, jsx: preserve, esModuleInterop: true, skipLibCheck: true, forceConsistentCasingInFileNames: true, resolveJsonModule: true, isolatedModules: true, noEmit: true }, include: [src/**/*.ts, src/**/*.tsx, src/**/*.vue] }这里逐个说一下关键项target 决定编译到哪个 ECMAScript 版本影响生成 JS 的语法级别module 决定模块系统Vite 项目一般用 ESNextmoduleResolution 决定模块解析策略如果你用的打包器是 Vite 或 webpack建议直接配成 bundlerTS 5.0 之后新增strict 是总开关打开之后会同时启用 noImplicitAny、strictNullChecks 等一系列严格检查这是 TypeScript 最大的卖点建议一律开启。还有一个最近很热的话题baseUrl在 TypeScript 7.0 中即将废弃。我在升级项目依赖时也看到过编译器提示“Option baseurl is deprecated and will stop functioning in typescript 7.0. Specify compilerOption paths to use path mapping without baseurl”。这意味着旧项目中baseUrl: ./src的写法迟早要改。迁移方式也很简单以前依赖 baseUrl 的“快捷路径导入”可以改成直接使用 paths并在 paths 里写完整相对路径。目前 Vite 项目里比较推荐的做法是配合 vite-tsconfig-paths 插件让编译器和打包器都认识这些路径别名逐步减少对 baseUrl 的依赖。6.2 声明文件 .d.ts 的编写面试中还有一种非常实际的问题你引入一个没有类型定义的第三方 JS 库时怎么办答不上来的人会说“直接用 any”但更好的答案是“写一个声明文件”。声明文件通常放在项目的 types 目录里或者和源码放一起文件名以.d.ts结尾。最简单的形式declare module some-untyped-lib { export function doSomething(input: string): number; export const version: string; }如果你的项目里没有 types 配置TypeScript 也会默认加载 src 下所有.d.ts文件。对于全局变量类型的声明可以直接这样写declare global { interface Window { __MY_CUSTOM_FLAG__?: boolean; } }还有一种情况是给图片、CSS 模块等非代码文件声明类型。比如在 Vite 项目里通常会有个env.d.tsdeclare module *.vue { import type { DefineComponent } from vue; const component: DefineComponent{}, {}, any; export default component; }面试时最好能主动说出“声明文件是给 JavaScript 模块补类型说明不需要任何运行时逻辑”这句话会显得你对构建链路有完整的理解。6.3 在 Vue3/React 中的实际应用最后聊一下 TypeScript 在前端框架里的实战考察。如果你面的是 Vue 3 岗位大概率会问组合式 API 中如何给 props 定义类型。正确写法是defineProps{ title: string; count?: number; }();在 Vue 3.3 之后甚至可以直接从外部导入类型import type { Props } from ./types; definePropsProps();如果面 React则会考察函数组件的 Props 类型定义、useState 的泛型推导、useRef 的类型处理等。比如 useRef 有一个经典的坑useRefHTMLDivElement(null)返回的类型是一个可变的 RefObject而useRefHTMLDivElement | null(null)在某些情况下也会有不同的行为。要能分清这些细微差别需要一定的 React TypeScript 的实操经验。还有一个值得说的点是“类型安全和数据请求”结合的场景。我在实际项目里会把 API 函数的返回类型和前端状态类型统一定义这样后端字段变更时前端在编译期就能发现哪些地方需要修改。这虽然不算是纯粹的面试题但如果你能在面试中说出自己“用 TypeScript 规范接口字段、减少联调事故”的真实经历面试官对你的印象一定会加分。7. 面试中几个常见陷阱与答题建议7.1 八股背后的思考方式2023 年之后的面试越来越不喜欢“背题式候选人”。同一个 TypeScript 面试题背过八股的人和真正写过的人回答时的颗粒度是完全不一样的。我特别建议大家准备面试时不要只背结论而是把每个结论背后的“为什么”顺一遍。比如“interface 能声明合并”这个结论你可以继续问自己“为什么 TypeScript 要设计声明合并它对哪些场景有帮助”如果你想不出应用场景可以去看 Express、Vue Router 这类流行库的类型定义你会发现很多都是靠声明合并来扩展的。再比如“泛型能保证类型安全”你可以在自己项目里找一找哪些函数是“不用泛型就得写重复代码”的——列表筛选、分页请求、状态管理模块的 action 定义。把这些真实案例整理成自己的语料面试时随取随用比对着文档念十遍都有效。7.2 避坑常见误区最后整理几个我面试别人时经常遇到的误区希望大家不要踩第一把 any 当成解决问题的万能钥匙。面试官问你对某个类型问题的解决方案时不要开口就是“用 any”这基本等于告诉对方你还没想明白可替代的方案。可以换成“先用 unknown 收窄或者在边界场景临时断言”观感会完全不同。第二混淆类型和值。“interface Person 里的 Person 是一个类型不是一个值”这类基础概念出错的话打击是致命的。面试官可能会出一些判断题比如“typeof 一个 interface 类型可以吗”答案是不行因为 interface 在编译后完全被擦除运行时拿不到它。第三忽略 strictNullChecks 的影响。很多人都知道 strict 模式要开但不一定意识到 strictNullChecks 开启后string和string | null是完全不同的类型。比如let name: string | null null; let length name.length; // 报错需要先判空一旦你习惯在 strict 模式下写代码很多“运行时突然报 undefined”的问题都能在编译期被发现。面试时提到这一点也是加分项。第四不知道“类型编程”和“业务逻辑”之间的度。类型写得太复杂会让团队其他人难以维护这也是一种坏味道。面试时可以透露自己对“过度设计”的警惕说“类型应该以表达业务约束为度不是越花哨越好”这通常会是一个很好的收尾观点。我个人在实际面试中的体会是能从“TypeScript 是 JavaScript 的超集”一直讲到底层类型系统的设计哲学、再到工程配置落地的人和只会背一堆工具类型名字的人差距一眼就能看出来。准备面试题并不可怕关键是别把“背八股”当成目的而是借这个过程把平时没想明白的类型设计问题彻底捋一遍。这套底子打好了不光是面试日常写代码的效率也会提升一大截。 
