TypeScript与ES6实战笔记：从深拷贝、Map到类型系统与工程化避坑

1. 从“自用”到“贴出来”这本笔记记录的起点先说个实话我电脑里躺着十几份命名格式是“XX学习笔记自用”的文档有的写着写着就烂尾了有的纯粹变成了一个收藏夹搬运工真正派上用场的少。但TypeScript和ES6这份不一样它是我断断续续折腾了大半年、走过不少弯路之后才沉淀下来的东西。最近清理本地笔记时翻出来越看越觉得很多内容不该只躺在我的硬盘里索性整理成博文贴出来。为什么标题要强调“自用”因为这份笔记的定位从一开始就不是写给新手看的教程而是我给自己留的查漏补缺手册项目里踩过的类型报错、ES6特性在真实场景里怎么用、配置项莫名其妙弹出来的弃用警告、面试前翻哪几页最管用。所以你会发现这份笔记的行文和我平时写的技术文章不太一样它更像是一个人坐在你旁边翻着他那本皱巴巴的笔记本跟你说“这个地方我当时卡了很久你直接照抄就行”。这篇内容适合谁看我总结下来有三类人第一类是刚接触TypeScript被类型系统绕得头晕想找个“过来人的手记”当参照的人第二类是写过一些ES6但总觉得基础不牢尤其是对深拷贝、Map这类高频考点还停留在“大概会用”这个层面的开发者第三类是正在准备typescript面试需要快速过一遍重点概念和踩坑记录的求职者。如果你属于其中任何一类这篇笔记大概率能让你少走几个弯路。有一点需要先说明这篇博文不是我临时凭空写的它建立在真实的开发经历之上。笔记里提到的每一个知识点、每一段报错信息、每一处工程配置都是我在实际项目中碰过、查过、修过的东西。我会按自己的学习顺序来讲——先从ES6的语法体验说起再深入TypeScript的类型体操然后聊到工程化链路里的配置问题最后站在面试视角做一轮反刍——这样读起来会更像一条真实的学习轨迹而不是一份干燥的API目录。2. ES6留给我的两组核心遗产深拷贝与MapES6的东西太多了箭头函数、模板字符串、解构赋值、Promise、async/await每个单拎出来都能写一篇。但说句实在话这些语法层面的东西只要写过两个项目基本就能上手真正让我觉得“这玩意儿值得深入研究”的只有两组深拷贝和Map。这两组碰到的坑最多面试被问得也最频繁而且它们都不是单纯的语法点背后牵扯出的是JavaScript对象模型、引用传递、数据结构选型这些底层认知。2.1 深拷贝为什么JSON大法不是万能药一说到深拷贝很多人第一反应是JSON.parse(JSON.stringify(obj))。这个方法在90%的场景下确实好用但剩下的10%恰恰是最容易出事故的地方。我在项目里就撞过好几次南墙最典型的就是Date对象被序列化成字符串、undefined和Symbol属性直接被丢掉、函数被过滤掉、RegExp变成空对象。还有更隐蔽的循环引用的对象会直接抛错Converting circular structure to JSON当时线上一个接口返回的数据里带着一个环形引用我这边一拷贝直接白屏排查了半天才找到元凶。所以后来我在笔记里给自己立了条规矩能用结构化克隆structuredClone就用它这是现代浏览器和Node 17原生提供的深拷贝方案支持循环引用、Date、RegExp、Map、Set这些类型唯一的限制是函数的拷贝不支持会抛DataCloneError。但面试里手写深拷贝是躲不掉的考点而且实际项目里有时也得自己实现比如兼任node环境或浏览器兼容性限制时。我的手写版本经历了三个迭代阶段这里直接分享最终版本的核心思路function deepClone(target, map new WeakMap()) { if (target null || typeof target ! object) { return target; } if (map.has(target)) { return map.get(target); } const clone Array.isArray(target) ? [] : {}; map.set(target, clone); if (target instanceof Date) return new Date(target.getTime()); if (target instanceof RegExp) return new RegExp(target.source, target.flags); for (const key of Reflect.ownKeys(target)) { clone[key] deepClone(target[key], map); } return clone; }这个版本的亮点在两点一是用WeakMap缓存已经克隆过的对象天然解决循环引用问题二是用Reflect.ownKeys拿到包括Symbol在内的所有自有属性。写到这里我就忍不住要提一句Map了因为WeakMap本身就是ES6中的Map家族成员如果你不懂Map这个深拷贝版本你就看不明白。2.2 Map不止是多了一种键值对容器Map对我来说最大的认知冲击在于它的键可以是任意类型。普通对象Object的键只能是字符串或者Symbol但Map可以用函数、对象、NaN甚至undefined作为键。这有什么实际意义我举两个场景。第一个是缓存场景。我有一次要给一组状态对象做计算结果缓存如果用Object你得给每个对象手动拼一个字符串key丑陋且容易碰撞用Map的话直接把状态对象本身当作key查缓存就是一次map.get(stateObj)的事干净利落。第二个是深拷贝场景里的循环引用检测。我在自己实现深拷贝时第一版用的是{}做缓存表结果发现当key不是字符串时全部会被转成[object Object]两个不同对象直接就冲突了。后来换成了WeakMap才彻底解决——WeakMap对key的引用是弱引用不会阻止垃圾回收这一点在做递归拷贝时尤其重要因为你不想因为一个缓存表把所有被拷贝对象全部常驻内存。除了Map本身我还要提一下Map和数组的互转这在处理接口数据时极其常用const map new Map([[name, 张三], [age, 18]]); const arr [...map]; // [[name, 张三], [age, 18]] const obj Object.fromEntries(map); // { name: 张三, age: 18 }这三个转换我都实测过其中最容易被忽略的是Object.fromEntries(map)它能把一个Map直接铺成普通对象非常适合在传给后端或者塞进URL参数时用。反过来Object.entries(obj)也能把普通对象转成二维数组再喂给new Map()形成一个闭环。项目做多了之后你会发现八成以上的数据转换需求在这几个API之间就能解决根本用不着什么工具库。2.3 迭代器与for...of为什么遍历的顺序有讲究既然提到了Map就绕不开它的遍历特性。Map是有序的它按照插入顺序排列键值对而for...of天然支持迭代器协议。这个特性的实际价值在于当你需要维护一个“有顺序的字典”时Map是远比Object优秀的选择。我在一个活动配置模块里就遇到过这种需求要让一组规则按配置顺序依次执行用Object的话不同浏览器对字符串键的枚举顺序可能不一致用Map则完全没问题。for...of配合迭代器的另一个好处是可以用break、continue和return来中断或跳出循环这一点forEach做不到——forEach里你中断循环只能用异常去模拟相当痛苦。所以我在笔记里给自己的建议是新代码里遍历数组、Set、Map一律默认用for...of只有需要索引值的时候才用for...in实际上for...in主要用在普通对象上或者Array.prototype.forEach。3. TypeScript类型系统的实战修行从基础约束到泛型绞肉机ES6部分在我这里算是热身真正让我花掉大把时间的是TypeScript的类型系统。说实话一开始我对TS是有点抗拒的——写惯了JavaScript的灵活觉得类型标注纯属加戏。但等到项目规模上去、接口联调天天出低级错误之后我才意识到类型系统不是约束而是安全网它把运行时才能暴露的错误提前到了编译期。3.1 type与interface到底该用哪个这个问题我纠结了很久网上答案也五花八门。我自己最终形成的判断标准是定义对象的结构形状、声明类的实现契约时用interface定义联合类型、交叉类型、工具类型、映射类型这些“计算出来的类型”时用type。例如一个接口的响应体我更习惯用interface来定义因为它可以被多次合并声明这是type做不到的同名type会直接报错。但一个人的身份可能是“老师”或“学生”这种联合类型只能用type来表达interface Teacher { teach: () void } interface Student { study: () void } type Person Teacher | Student;另外在React的props定义中社区主流倾向是用interface还是type其实并没有绝对标准但Vue3的defineProps泛型写法里更频繁出现的是type。我的经验是在一个项目里保持统一比追求“最佳实践”更重要否则代码review时每个文件都有不同的风格维护成本会直线上升。3.2 泛型用过才知道它是“类型界的函数”泛型这个抽象概念我琢磨了很久才真正开窍。我的理解方式是普通函数是对值做抽象泛型是对类型做抽象。就好比你写一个add(a, b)函数它不关心a和b具体是数字还是字符串只要支持加号运算就能跑泛型则是让类型也能被当作参数传给“类型函数”。最简单的例子就是数组的map方法ArrayT.mapU(callback)它接收一个T类型的数组通过callback把每个元素变成U类型返回U类型的数组。用泛型思维理解之后很多高级TS用法就顺理成章了。function firstElementT(arr: T[]): T | undefined { return arr.length 0 ? arr[0] : undefined; }这个函数没参数类型包袱传string[]返回的候选类型就是string传number[]返回的候选类型就是number这就是泛型最直白的应用。但实际项目中光会这个还远远不够更常用的是泛型约束比如你想让一个函数只能操作带有length属性的类型就得用extends来限定function longestT extends { length: number }(a: T, b: T): T { return a.length b.length ? a : b; }我见过不少初学者写出function longestT(a: T, b: T): T然后一直报TS2339属性length不存在原因就是没有加泛型约束。这个坑我一开始也踩过后来总结出来的经验是当你的泛型代码里报“属性不存在”这类错误时第一反应不是换个写法而是想想自己是不是漏了extends约束。3.3 条件类型与infer类型体操的深水区如果你翻过TS的工具类型源码会发现很多高级类型都建立在条件类型T extends U ? X : Y之上配合infer关键字可以做类型推断。说实话这块内容除非你在写通用库或者工具函数否则平时业务代码用到的频率并不高但面试的时候问的人却不少因为在面官眼里“能不能读懂复杂类型”很能反映一个人的TS水平。我来拆解一个非常经典的条件类型例子获取函数返回值的类型——这个其实TS自带了ReturnTypeT工具类型但它的内部原理值得看一遍type MyReturnTypeT extends (...args: any) any T extends (...args: any) infer R ? R : never;关键就在infer R它告诉TS“这里有一个待推断的类型变量R你能推断出来就用它”。我刚开始完全看不懂这个语法后来用了一个很笨的办法把infer理解成“从结构里抽取类型”。比如(...args: any) infer R就是从“一个函数类型”中把返回值那部分抽取出来命名为R。条件类型在配合keyof、typeof、索引访问类型的时候能爆发出极强的表达能力。比如你想写一个工具类型取出对象里所有值为函数的键名type FunctionKeysT { [K in keyof T]: T[K] extends (...args: any) any ? K : never }[keyof T];这段代码里用了映射类型把T的每个属性K遍历一遍判断值的类型是否为函数是则保留K否则赋值为never最后通过索引访问[keyof T]把所有never过滤掉剩下的键名就是你要的结果。它看起来像魔术但其实就是TS里的“数组filter”的思路——过滤的本质在于把不符合条件的类型变成never然后让索引访问自动忽略它。我在笔记里给这段内容标了两个星号意思是面试前必看。不是因为面试官一定会考这个语法而是能把这层逻辑讲明白说明你对TS的类型运算不再是“背API”级别而是真的理解了它的运作方式。3.4 never、unknown与any类型世界的三个极端这组类型我单独列了一页因为太多人把any当万能钥匙把unknown当any的别名把never当“不存在的类型”敷衍过去。实际使用中这三者的边界非常重要。any是关闭类型检查你用any就是在告诉TS“你别管我了我什么类型都行”危险性最大。unknown是安全版的any你无法直接使用unknown类型的值必须先通过类型守卫或断言收窄之后才可操作好处是强迫你写安全的代码。never是所有类型的子类型代表“永远不可能有值的类型”。比如一个函数总是抛出异常它的返回值类型天然就是never。我给自己的实践准则是能不写any就不写any遇到不确定的类型优先用unknown等运行时判断完再收窄。实在不行写个显式的as any并加注释说明原因——这总比类型错误一片红然后一把梭全是any要强得多。4. TypeScript 5.x配置项的弃用风波与工程链路的连锁反应笔记写到TS类型知识之后紧接着就是一大段工程化相关的记录。原因是某一天我升级项目里的TypeScript版本控制台突然冒出一堆黄色的弃用警告。最醒目的两条是“选项‘baseurl’已弃用并将停止在TypeScript 7.0中运行。指定compilerOptions...”和“选项‘moduleresolutionnode10’已弃用并将停止在TypeScript 7.0中运行”。当时我整个人是懵的因为这两行配置在几乎所有我见过的项目里都存在。4.1 baseUrl和moduleResolutionnode10为什么被宣判“死刑”先来拆一下背景。很多老项目在tsconfig.json里都会这样写{ compilerOptions: { baseUrl: ., paths: { /*: [src/*] }, moduleResolution: node10 } }baseUrl的作用是让模块解析在相对于baseUrl的路径上查找paths配合它做路径别名比如让/components指向src/components。这套方案在早期确实解决问题但它的缺陷也很明显baseUrl会让模块解析变得不透明尤其是当项目里同时存在相对路径和baseUrl相关的非相对路径时解析顺序容易让人摸不着头脑。TypeScript官方后来推荐的做法是路径别名完全通过paths配合相对路径来定义不再依赖baseUrl作为解析根。至于moduleResolution: node10这个名字本身就有历史包袱——它是老旧的Node.js模块解析策略对应的实际是Node.js的CommonJS时代。现在Node.js本身都支持ESM了工具链和包管理器也都跟着演进再用node10的解析规则去适配modern JavaScript生态就明显滞后了。新项目里强烈建议改成moduleResolution: bundler这是TS 5.0引入的新取值专门面向vite、webpack这类打包器场景。它理解package.json里的exports、imports这些字段能正确处理ESM风格下的模块解析比node10那套老黄历要适配得多。4.2 修完tsconfig之后vue-tsc和electron打包的连锁反应这是我这篇笔记里最有含金量的一部分因为我修配置的历程并不是只改一个tsconfig.json就结束的。我还在一个React Native相关的side project里遇到过类似情况但更典型的是Vue3 TypeScript项目的完整链条。先说vue-tsc。Vue3项目通常用vue-tsc做类型检查和构建前的类型校验它的作用和tsc类似但额外支持.vue文件里的script langts块。我升级到vue-tsc: ^1.8.27搭配typescript: ^5.3.3组合之后遇到的问题特别典型vue-tsc的版本要和typescript的主版本对齐否则会出现一些匪夷所思的报错比如明明类型没问题却报“找不到模块”或者“类型不兼容”。尤其是当我把moduleResolution改成bundler之后有些第三方库的类型入口用的是exports字段如果vue-tsc的版本过旧它根本看不懂这种新语法于是全线飘红。解决这个问题的标准路径很清晰把typescript和vue-tsc都升到兼容版本检查vue-tsc的release notes里写的peerDependencies要求。我在笔记里记了一个关键教训不要混着用全局typescript和一些全局tools一个项目内部统一用项目本地依赖的TS版本。再说electron打包。Electron应用打包时经常会在package.json里看到这样的devDependencies{ scripts: { build: vue-tsc --noEmit vite build, pack: electron-builder } }如果vue-tsc在build阶段因为类型问题挂了electron-builder根本走不到打包环节。但electron打包还有自己的另一层坑主进程代码如果是TS写的一般用单独一个tsconfig.node.json来编译它的moduleResolution和renderer侧可能完全不同。有次我在打包后主进程里报“__dirname未定义”排查半天发现是我在tsconfig.node.json里也顺手改了moduleResolution导致主进程的CommonJS语义被破坏__dirname直接消失。后来就把主进程和渲染进程的tsconfig彻底分开一个保持node语义一个用bundler再也没出这种幺蛾子。4.3 关于compilerOptions该怎么组织我的模板绕了这么大一圈我把目前项目里比较稳的tsconfig配置整理成了模板直接贴在这里供参考注意注释很关键{ compilerOptions: { target: ES2020, module: ESNext, moduleResolution: bundler, strict: true, jsx: preserve, skipLibCheck: true, esModuleInterop: true, allowSyntheticDefaultImports: true, resolveJsonModule: true, isolatedModules: true, paths: { /*: [./src/*] } } }特别说明一下我把原来习惯写的baseUrl去掉了只用相对路径的paths来定义别名。strict这个开关我永远都是打开的因为TS的类型检查价值主要体现在strict模式下如果关掉strict不如直接用JavaScript。skipLibCheck建议开着能显著缩短类型检查时间代价是跳过对.d.ts文件的类型校验——对于大多数应用项目来说这个代价是完全可以接受的。5. 把自用笔记翻成面试考点回顾与补漏笔记的最后一段是我在准备typescript面试的时候陆续补进去的。你会发现很多知识点在前面已经讲过但同一件事换个问法之后答法还真不一定一样。这段内容与其说是面试攻略不如说是我站在“理论检验”的视角重新逼自己把这些特性讲清楚的一次练习。5.1 面试高频type与interface、Map与Object、深拷贝与循环引用这三个问题几乎每一个我都被问到过。面试官问type和interface的区别时他真正想听的是你“对于建模工具的选择是否有自己的判断”不是单纯背诵“interface可以被extendstype可以定义联合类型”。我的回答思路是先从语法层面的差异展开是否能合并声明、是否能描述联合类型然后落到实际项目——我拿到一个接口文档时优先会用什么处理一个复杂的模板类型计算时又会用什么最后总结自己的统一规范。Map与Object的问题现在出镜率也很高。这个问题的背后其实是在考察数据结构意识你什么情况下会用Map而不是Object你是否了解对象原型链带来的风险比如对象可以继承原型属性你用Object做字典时得小心__proto__这类键以及迭代顺序和性能差异。我的回答一般会从“Map的键可以是任意类型”和“Map天然有序”两个角度切入然后举一个缓存或者深拷贝里实际用WeakMap的例子把前文的经验直接搬过来用。深拷贝手写更是老生常谈。我建议面试前把深拷贝的版本从浅到深背一遍第一版JSON大法说明你会用但知道局限第二版递归WeakMap解决循环引用和基本复杂类型第三版加上Reflect.ownKeys处理Symbol提升完备性最后补充一下structuredClone它解决什么问题、什么情况下不能用。能把这么一条演进链路上来面试官基本上就会给你过了。5.2 面试中的现场编码泛型工具类型与类型守卫除了问答题面试里还经常有现场coding。我遇到的两次TS现场coding题目都集中在两类第一类是让我手写一个通用工具类型比如PartialT、PickT, K或ReadonlyT。这类题的底层逻辑就是映射类型和索引访问类型平时我把keyof和in记熟之后基本都能写出来。第二类是让我实现类型守卫。比如给一个联合类型type Animal Dog | Cat其中Dog有bark方法、Cat有meow方法写一个函数判断入参到底是哪种。这里考察的要点是in操作符的使用function isDog(animal: Animal): animal is Dog { return (animal as Dog).bark ! undefined; } // 或者 function isCat(animal: Animal): animal is Cat { return meow in animal; }用in操作符的写法更加简介而且TS对in操作符做类型守卫的支持比传统的as更加稳定和可读。我在写业务代码时也更倾向于用in或者可选属性判别而不是老是as一把梭。现场coding时的心态也很重要。建议先在白板上写一个小例子跑通思路再扩展到完整实现。面试官看重的不是你对API的背诵熟练度而是你遇到类型问题时如何分析和拆解——在这一点上平时那些踩坑记录反而成了最宝贵的素材。5.3 编码规范与可维护性TS项目里最容易忽略的隐形红线既然笔记定位是自用工程手册这块内容我必须记上一笔。typescript编码规范是很容易被忽略、但对代码库长期健康影响非常大的话题。首先明确禁止随意使用any。如果后端的某个接口字段确实不确定我会优先把类型声明为unknown然后在使用处做收窄。其次泛型命名不能随便T、U、V在业务代码里你应该让泛型具备语义比如TEntity或者TResponse不然过三个月连自己都看不懂。再有模块导出的设计尽量清晰一个文件默认只对外暴露一个核心类或函数其余的用具名导出这样类型推断和tree-shaking都会更友好。我还给自己定了一条硬性规范每个关键函数必须写返回类型而不是依赖TS自动推断。毕竟自动推断在简单的变量赋值场景很贴心但一旦复杂函数的返回链路出现变化隐式推断的类型往往会和预期出入很大。显式标注返回值还有一个好处——你自己写的时候就会被迫思考这个函数到底返回了什么、语义是什么这对代码质量本身就是一种提纯。6. 说点笔记之外的事这些经验是怎么沉淀下来的写到这这篇笔记的核心内容基本就梳理完了。但我想多说几句关于“记笔记”这件事本身——因为这半年我最大的收获其实不在TypeScript或者ES6的知识点而在一套自己能长期坚持的学习方式。最开始我写“自用笔记”是非常随性的项目里遇到什么坑就往上记什么完全没有体系。后来发现知识点太散今天记一个Map的用法明天记一个泛型约束翻起来跟翻垃圾桶一样痛苦。大概在第三个月的时候我给自己定了一个框架每个知识点至少包含三部分——是什么、为什么、在什么场景下用。是不是用这套框架复盘过的知识在面试时和写代码时的调用速度差别真的很大。另外我强烈建议在笔记里专门留一节叫“待深挖”每次遇到模棱两可的概念先扔进去过一两周再回头看。很多当时死活想不通的问题在写过几个项目之后再回来反而一眼就能看穿。比如当初让我浑身难受的infer后来在自己写一个参数序列化工具时突然就懂了因为那个场景里我必须提取出函数的参数类型infer就直接成了我的工具。知识这种东西未必要在真正需要之前就完全理解但要确保它始终留在你的认知地图里等到实际需求出现的时候伸手就能摸到它。这篇笔记后续我还会继续更新计划补的内容包括TypeScript装饰器在NestJS和Vue3里的两种风格差异、ES2023以后出现的新特性数组的toSorted、findLast这些、以及更深入的泛型进阶——把类型体操玩到连UnionToIntersection这种都能自己手写。如果你也在学TypeScript和ES6的路上希望这篇笔记能像一本“过来人避坑地图”一样让你少走几段我走过的弯路。