很多 TypeScript 教程习惯把运算符一笔带过觉得它就是 JavaScript 那套东西没什么好讲的。但我在带团队做代码评审时被0 ?? x、a?.b ?? c、~n -(n 1)这一串表达式坑过的次数远比想象中多。尤其是当项目里同时混着 Vue 3、three.js 和一套严格开启的 tsconfig 时运算符不仅决定代码能不能跑还决定类型推导能不能按预期收窄。这篇内容我想把 TypeScript 运算符这件事彻底讲透从值空间到类型空间、从取余符号到优先级事故、从面试题到 TS 7.0 的配置弃用警告一次性整理成一份可以反复翻看的实操笔记。适合刚开始学 TS 的人也适合那些已经在生产环境写 TS 但偶尔会在表达式上犹豫一下的朋友。1. 运算符全景先别背语法把这张表放进工作台1.1 值空间与类型空间一张表而不是一页文档TypeScript 里的运算符其实要分成两个阵营来看。第一阵营是运行时运算符也就是 JavaScript 本身就有的那些它们直接参与代码执行第二阵营是类型层面的“类运算符”比如typeof类型位置、keyof、in、infer、extends它们不产生运行时行为但决定了类型怎么变换。很多人学 TS 运算符只盯着第一阵营结果一碰到泛型条件类型就懵原因就在于没有建立“运算也可以发生在类型空间”这个意识。我先把运行时运算符按用途归一下类这样后面讲细节时大家能对号入座类别代表运算符返回类型倾向常见坑算术运算符 - * / % ** --number但可能返回 string加法重载、取余符号、指数优先级赋值运算符 - * / % **被赋的值与混淆、链式赋值可读性比较运算符 ! !boolean隐式转换、引用比较逻辑运算符 || ! ??操作数本身或 boolean短路语义、falsy 与 nullish 差异位运算符 | ^ ~ number32 位截断、补码规则其他typeof instanceof in delete void new各自不同typeof null、数组 delete 留空洞这张表不是让你背的是让你在工作台旁边贴着的。实际开发中你不需要记住所有运算符的每一条边角规则但你必须知道“某个运算符的返回值类型”和“它到底对什么值做了什么”这两点决定了 TS 类型推导会不会出错。比如in运算符在值空间里检查属性是否存在在类型空间里却用于映射类型遍历同一个单词两种完全不同的语义这就是 TS 特有的“空间切换”。1.2 加号不是加号字符串拼接与数字转型的隐性规则算术运算符里最容易被低估的就是加号因为它在 JS/TS 里被重载成了两件事数字相加和字符串拼接。只要运算符两侧有一个是字符串整个表达式就会变成字符串拼接。1 1是2但1 1直接变成字符串11这可能和你最初的本意毫无关系。我见过不少线上问题出在这个地方。比如从接口里拿到price字段类型是string | number直接total price 10以为在做加法结果返回了10010。TS 的严格模式在类型层面能帮你拦住一部分但当你把值先赋给any或者从表单控件取值时TS 也拦不住。更麻烦的是减号、乘号、除号不会重载5 - 3会得到数字2因为非加法运算符会尝试把字符串转成数字。于是同一个对象加法和减法的表现完全不一致这种不一致非常容易让维护者产生“这个变量到底是 string 还是 number”的困惑。我的建议很简单需要求和时先显式转数字再运算不要依赖隐式转换。Number(a) Number(b)虽然啰嗦但它把意图写死了。另外一元正号value也是快速转数字的方式42会得到42可读性上不如Number(42)直观团队代码规范里最好只留一种。还有null 1会得到1而undefined 1会得到NaN这种稀奇古怪的结果全都来自 ToNumber 转换规则你不需要背全但你要知道“加号面前类型不干净就会出幺蛾子”。一个容易被忽略的角落是**指数运算符的优先级。-2 ** 2在 JS 里直接报语法错误因为一元运算符不能紧贴在指数表达式前必须写成(-2) ** 2或-(2 ** 2)。而2 ** 3 ** 2是右结合的结果是512不是64。这种规则对新手极不友好所以我强烈建议涉及指数运算时永远用括号把底数和指数包清楚不要跟优先级较劲。2. 最容易让老手都翻车的三个区域相等、取余、逻辑短路2.1 相等比较 的问题不只是类型转换很多教程说“永远用别用”这句话方向没错但没讲透。真正的问题不只是类型转换而是它会做一整套你很难快速心算的 ToPrimitive 转换。null undefined是true0 是true\t 0也是true。你在代码评审里看到这些还得临时去查规范才知道行为这对维护者来说就是纯粹的阅读负担。TS 的严格模式加上 ESLint 的eqeqeq规则基本能挡住大部分误用但有一个例外在很多团队里还在用判断一个值是不是null或undefined时有人图省事写value null。这个写法本身能同时判断两种空值行为上是可靠的但 lint 通常不允许而且可读性确实不好。我自己的做法是写成value null || value undefined或者干脆用??的语义去处理默认值把判断这件事交给空值合并运算符。相等比较还有一个被忽略的坑对引用类型只比较引用地址不比较内容。{a: 1} {a: 1}永远是false。这在对象状态比较时非常容易出问题。比如在 Vue 的 computed 里依赖一个对象每次请求回来都新生成一个对象内容一样但引用不同computed 就会频繁重算。要比较内容就得自己写递归对比或者用现成的工具函数千万不要直接。顺带说一个面试常考的细节NaN NaN是false判断 NaN 要用Number.isNaN()。另外Object.is(0, -0)是false而0 -0是true。这些边角规则不会天天用但你一旦在金额计算或状态判重时遇到会很困惑。2.2 取余和位运算被 32 位截断支配的恐惧%在中文里经常被叫“取模”严格说它是“取余”不是“取模”。区别在负数场景JS 的%结果符号跟被除数一致。-5 % 3得到-2而不是数学里通常定义的模运算结果1。如果你要做真正的正数取模比如处理环形数组索引或者循环动画帧号得自己写((a % m) m) % m。我为什么单独提这个因为在 three.js 机房可视化这类项目里循环动画和时间帧计算特别多。坐标、角度、进度值来回取余一旦遇到负数动画就会突然跳变。比如粒子系统的循环偏移量进度到了负数区间一个%就能让整个轨迹乱掉。遇到这种需求不要相信原生%直接封装一个mod工具函数内部做正数转换团队所有成员统一调用。位运算符在 JS/TS 里更隐蔽。JS 的位运算会先把操作数转成 32 位有符号整数再进行运算。这意味着2147483648 | 0的结果是-2147483648而不是2147483648。你写0xffffffff | 0得到的也是-1。这是无数人对位运算产生心理阴影的根源——按直觉运算结果却溢出成了负数。位运算的实用场景主要是性能敏感代码、权限位标记、标志位合并。比如用const FLAG_A 1; const FLAG_B 2;做权限组合时permission FLAG_A判断是否含 AFLAG_A | FLAG_B做合并这套写法在底层库和状态码设计里很常见。但要记住所有运算都被锁在 32 位范围内超过就翻车。用 0可以把结果转成无符号 32 位整数返回4294967295而不是-1。关于~按位非有个公式~n -(n 1)。~5是-6。老代码里有人用~index判断数组索引是否存在if (~arr.indexOf(x))因为-1取反得到0是 falsy。这个写法虽然能跑但现在没人推荐了直接用includes更清晰。至于用n 1判断奇偶对负数也可靠因为二进制补码的最低位仍然能正确表达奇偶性这比n % 2 ! 0在负数和浮点场景下更稳定。2.3 逻辑运算的短路默认值、条件渲染与 ?? 的边界和||的短路语义说白了就是“计算到一半就能确定结果时右侧表达式就不用再算了”。false anything直接返回falsetrue || anything直接返回true。这个机制本身不难难的是返回值不是布尔值。JS 的逻辑运算符返回的是操作数本身不是强制转换后的布尔值。所以0 || default返回defaulthello 123返回123。这个行为在业务代码里最常见的坑就是默认值处理。你写count || 0本意是“如果 count 没值就用 0”但count是合法数字0时||会把0当作 falsy 丢掉结果还是0没区别可当你写name || 匿名如果name是空字符串它也被丢掉了。空字符串在很多业务场景里是合法值比如用户确实不想填昵称。这时候你应该用空值合并运算符??它只在左侧是null或undefined时取右侧默认值。还有一个前端特别容易出问题的地方是条件渲染。在 Vue 模板或者 JSX 里新手常写{count span有数据/span}。当count是0时表达式返回0页面上就会渲染出一个裸的0整个 UI 多出一个数字。正确写法是{count 0 span有数据/span}或{count ? span有数据/span : null}。这个问题的本质就是你忘记了返回的是原值而不是布尔值。??还有一个严格限制不能直接和或||混合使用而不加括号。a ?? b || c这种写法是语法错误因为规范明确禁止 nullish 合并与逻辑或、逻辑与无括号混用目的是避免语义歧义。遇到这种需求必须写成(a ?? b) || c或a ?? (b || c)把优先级明明白白写出来。这个规则在 TS 里会被编译器直接拦下所以你不可能等运行时报错但理解它为什么存在很重要。3. 优先级、结合性与括号纪律一行表达式引发的线上事故3.1 优先级快速记忆先把分水岭画出来运算符优先级不用全背但分水岭要清楚。我记优先级的方式是把它分成几大块从高到低大约是这样括号、成员访问、函数调用、可选链一元运算符、 --、!、~、typeof、 -指数**乘除取余* / %加减 -移位 比较 in instanceof相等 ! !位运算 ^ |逻辑运算 ||空值合并??三元?:赋值逗号这个顺序不需要死记。你只需要记住几件关键的事赋值优先级极低所以a b c是右结合的三元运算符优先级也很低所以cond ? a : b || c实际是cond ? a : (b || c)比较运算符优先级高于相等低于加减所以a b c没问题但a b c就会非常绕。遇到这种组合不要再想“优先级表是啥”直接加括号。另一个必须记住的现象是链式比较的“假象”。1 2 3在 JS 里是合法的结果是true因为它先算1 2得到true然后true 3true转成数字11 3成立。而3 2 1结果是false因为true 1等价于1 1不成立。看到没这不是数学里的连续不等式是按左结合逐步计算的。想表达连续区间必须写1 2 2 3或者用括号隔离。3.2 一个来自 three.js 机房的案例乘除优先级偷走了我的移动量我在做基于 Vue 3 three.js TypeScript 的机房可视化项目时遇到过特别典型的一例。需求是让相机以阻尼方式平滑追踪目标设备的位置代码看起来很简单const damping 0.05; camera.position.y target.y - camera.position.y * damping;我本意是“当前位置 (目标位置 - 当前位置) * 阻尼”也就是让相机每次朝目标方向移动一小段。但上面这个写法实际执行的是(target.y) - (camera.position.y * damping)因为乘除优先级高于加减。相机的位置会变成一个完全错误的偏移量而且数值变化很小动画看起来没有明显报错只是相机永远停在错误的高度上。正确写法是camera.position.y (target.y - camera.position.y) * damping;加一对括号就行了。但问题在于如果不把括号当作纪律来执行这种 bug 很难在 code review 里一眼发现。因为表达式不长变量名也合理只有当你盯着优先级表逐段拆解时才会惊觉。从那以后我在任何涉及“移动量、差值计算、混合比例”的表达式里都强制加括号而不是靠脑子里那点优先级记忆。这条经验对 three.js 这类坐标密集型项目尤其重要因为坐标计算经常是a (b - a) * t这种 lerp 公式天然就是加减乘除混杂不加括号几乎必出事。还有一个 Three.js 场景里的细节%在帧动画里常用来做循环比如frame % totalFrames。如果frame因为某种原因变成负数取余结果也是负数索引直接越界或反向播放。这也是我前面提到要封装正数模函数的原因。在可视化项目里运算符不是考点是每帧都在跑的物理规则错一个符号就是一次肉眼可见的视觉故障。3.3 括号纪律我要求团队只在四种情况下不加括号踩过几次坑之后我在团队规范里定了一条原则表达式一律优先加括号用可读性换确定性。具体来说只有四种情况允许不加括号纯赋值语句比如const total price * count单个方法调用链比如list.filter(x x.active).map(x x.id)条件表达式的分支体很短比如const status isOk ? ok : fail右侧是简单字面量或明确分组变量的情况比如const next current 1。其余场景尤其是混用了逻辑、比较、三元、可选链和空值合并的表达式统一加括号。比如const value (a ?? b) c就不会有人产生误解。括号不改变 TS 的类型推导也不影响性能它纯粹是降低认知负担。你永远不要把“这段代码只有我看得懂”当作不加括号的理由因为三个月后的你也是“别人”。4. TypeScript 的运算符另一半可选链、非空断言与类型空间里的运算4.1 可选链与非空断言一个在运行时一个在编译期?.可选链是 JavaScript 原生语法但它对 TS 的类型检查特别重要。user?.profile?.name在user或profile为空时返回undefined不会抛错。TS 能从这个表达式推导出整个链路中每一步都可能为undefined所以你在继续使用结果时类型系统会强制你处理为空的情况。这种编译期提示非常有用能在运行前就把空值问题暴露出来。!非空断言则是 TypeScript 独有的写法它完全存在于编译期运行时没有任何行为。element!.textContent的意思是“你别管类型系统怎么说我确信这里不是 null”。如果你错了运行时会照样抛错类型系统帮不了你。所以我对非空断言的态度是能用类型守卫推导的就别用!必须在 DOM 查询或第三方库边界使用时要确保你的“确信”有理由。可选链和非空断言经常被放在一起说但语义完全相反?.是运行时保护!是编译期断言。一个典型的组合是const first data?.items?.[0] ?? {};这里data?.items和items?.[0]是运行时短路保护?? {}是对最终空值兜底。而如果你写data!.items[0]那就是告诉 TypeScript “data 一定存在别检查了”如果实际 data 是 null程序直接炸。选择哪个取决于你对自己数据的确定性有多强。4.2 类型系统里像运算符的那些关键字typeof、keyof、in、infer、extends这一节对很多 TS 使用者来说是知识盲区。我前面说了typeof在值空间是运算符返回字符串但它还有另一个身份在类型位置使用typeof value可以取出值对应的类型。这是从实际变量反推类型的常用手段const config { url: , retry: 3, timeout: 1000 }; type Config typeof config; // Config { url: string; retry: number; timeout: number }keyof则可以看作“取对象类型属性名”的运算type K keyof Config得到url | retry | timeout。它与索引访问T[K]配合就能在类型空间实现“映射”和“变换”本质上这就是类型层面的一种运算。K extends keyof T ? ... : ...则是条件类型里的判断逻辑infer U则是从结构里提取类型变量。这些“类运算符”平时写业务代码可能用不到但一旦你要封装一个类型安全的请求函数、一个根据配置自动推导 action 类型的 store或者处理事件回调的参数类型它们就成了支撑整个类型推导的地基。你可以把它们理解为“类型空间里的函数式编程”keyof是取键集合T[K]是索引运算extends是判断infer是解构提取。理解了运算符思想再看高级类型就顺了。4.3 运算符作为类型守卫typeof、in、instanceof 的窄化TS 的类型窄化依赖运算符这是运算符在类型系统里最实用的场景。typeof value string之后TS 在这个分支里会把value收窄为stringvalue instanceof Date之后收窄为Datekey in obj之后联名类型会按哪个分支包含该属性进行窄化。写联合类型的处理逻辑时这些运算符就是你的分支开关。function format(input: string | number | Date): string { if (typeof input string) return input.trim(); if (input instanceof Date) return input.toISOString(); return input.toFixed(2); }这里typeof、instanceof都参与了窄化。要注意typeof能安全识别的类型有限对数组、对象、null 都会返回object所以要判断数组不能靠typeof只能Array.isArray()。in检查的是属性是否在对象或原型链上它和Object.hasOwn()不同前者会包含继承属性后者只查自身。还有一点值得提醒非空断言不会做窄化只是消除报错真正的窄化必须依赖运行时检查。在 strict 模式开启的项目里input!这类写法只会让编译通过不解决运行时风险。所以我把类型守卫用的运算符当成“安全边界”把非空断言当成“临时开关”能不用就不用。5. 升级 TypeScript 7.0 前这些配置警告正在悄悄逼近5.1 baseUrl 与 moduleResolution两个弃用警告的来龙去脉最近我把几个项目升级依赖时编译窗口里开始出现同一类警告大意是baseUrl选项已弃用并且会在 TypeScript 7.0 中停止运行请指定compilerOptions.paths同时moduleResolutionnode10也已弃用建议切换到node16、nodenext或bundler。第一次看到这个警告时很多人的反应是“我 tsconfig 里没写 baseUrl”但查一下就会发现可能通过扩展的共享配置引入了它。baseUrl最早是为了让模块导入可以写绝对路径前缀比如baseUrl: .配paths: { /*: [src/*] }然后import utils from /utils。这个设计在当时很实用但随着 Node 原生 ESM 和打包器的解析策略逐渐统一baseUrl 的语义与现代模块解析越来越难协调。它会让编译器在解析裸路径时依赖一个隐含在 tsconfig 里的根路径这在 monorepo 或多包环境下很容易产生歧义。moduleResolution: node10的问题类似。这个值以前叫node对应的是 Node 老版本 CommonJS 时代的解析算法它不支持exports字段、不支持 ESM 的import解析。TypeScript 为了兼容老项目把这种旧解析方式重命名为node10并开始弃用。现在新项目的正确方向是明确告诉编译器“我用的是哪种现代模块系统”不能再让它猜老规则。5.2 vue-tsc 与 electron 打包场景里的实测现象我手头一个实际项目是 Vue 3 Vite TypeScript 5.3.3打包 Electron 时用vue-tsc做类型检查版本锁在^1.8.27。原本这一切相安无事直到我尝试把 TypeScript 升级到较新版本后vue-tsc开始报警告因为vue-tsc的版本和 TS 编译器版本需要同步匹配不同步就可能在解析.vue文件时出现类型位置错乱。更值得警惕的是vue-tsc --noEmit在 CI 或 electron-builder 的打包流程里只要报错就会直接终止构建。也就是说TS 的弃用警告如果只停留在“警告”级别构建还能过但你一旦手动去升级 TS 或 vue-tsc新编译器可能会把原来宽松的类型问题全部暴露出来构建就会挂。这个因果链和运算符看起来没有直接关系但它背后全是“TS 版本变化对现有代码的冲击”处理不好一个无害的警告升级会成为打包事故。还有一个容易被忽略的地方Electron 的主进程和渲染进程对模块解析的要求不同。主进程更接近 Node 环境如果 tsconfig 统一使用moduleResolution: bundler主进程里依赖某些 Node 内置模块或require用法时可能反而解析不到。这不是说 bundler 不好而是说迁移配置时要按构建链路分别验证不要一个配置改到底。5.3 迁移步骤让 tsconfig 摆脱 deprecated 状态如果你在终端里已经看到了 baseUrl 或 node10 的弃用警告可以按下面这套流程处理。我建议不要直接忽略因为 TS 7.0 一旦发布警告会变成硬错误到时再迁移就很被动。先看一眼当前配置大致是什么样。以最常见的 Vite 项目为例可能是这样{ compilerOptions: { module: ESNext, moduleResolution: node10, baseUrl: ., paths: { /*: [src/*] } } }第一步删掉baseUrl把paths里的路径改成相对 tsconfig 的路径。TS 现在支持不依赖 baseUrl 的 paths写./src/*就能解析。第二步把moduleResolution换成bundler。这个值专门给 Vite、webpack 这类打包器用能正确解析exports字段、import别名等现代语法。如果项目是纯 Node 服务就换成node16或nodenext同时module也要配套调整。改完之后的理想配置{ compilerOptions: { module: ESNext, moduleResolution: bundler, paths: { /*: [./src/*] } } }第三步跑npx tsc --noEmit或npx vue-tsc --noEmit全量检查。如果出现解析失败的导入多半是某个库依赖了旧的 node10 解析行为逐个看报错信息修。打包链路的验证也不要省跑一次vite build再跑一次electron-builder确保两个进程的解析都正常。整个过程可能花你半小时但它能让你在 TS 7.0 真正到来前睡得安稳。我在迁移过程中最大的体会是TS 的配置项不是摆设每个弃用警告背后都是生态向现代模块标准迁移的必然结果早点跟上比晚点补课轻松。6. 面试里反复出现的运算符陷阱你能答对但未必答全6.1 五道题先自测能全对算我输我每年都会用一组运算符题筛选候选人题面不长但特别能反映对语言本质的理解。你先别看答案自己在心里跑一遍// 题 1 console.log(0 || default); console.log(0 ?? default); // 题 2 console.log(5 3); console.log(5 - 3); // 题 3 console.log(2 ** 3 ** 2); // 题 4 console.log({ a: 1 } { a: 1 }); // 题 5 console.log(-5 % 3); console.log(1 2 3); console.log(3 2 1);题 1 考的是||与??的语义差异答案是default和0。||把 0 当成 falsy??只把 null/undefined 当成空值。题 2 考加法重载与非加法的隐式转换答案是53和2。加号一见字符串立刻拼接减号会尝试把字符串转数字。题 3 考指数右结合答案是512因为先算3 ** 2得到 9再算2 ** 9。题 4 考引用比较答案是false。两个对象字面量即使内容相同也是不同引用。题 5 考取余符号和链式比较。-5 % 3是-2因为结果符号随被除数1 2 3是true3 2 1是false原因我在前面讲优先级时已经拆解过了。6.2 一道题的标准答法不只是报答案很多候选人能报出正确答案但追问“为什么”就卡壳。我把面试时最想听到的回答方式总结成三步先说答案再用运算符语义解释最后落到实际项目。拿题 1 举例第一步直接说输出不犹豫。第二步解释||返回第一个真值操作数0是 falsy所以返回右侧default。??只在左侧为 null/undefined 时返回右侧0不是空值所以返回0。第三步连接实际场景如果接口返回的默认配置里有一个数字值是 0用??才能保留这个合法值用||会把它替换成默认值。这样回答既能展示你“知道结果”也能展示你“懂得原理”还能证明你有“工程意识”。面试官最怕的就是候选人背了一堆规则但写业务代码时完全不知道怎么选。6.3 这些题在真实项目里对应的写法面试题不是孤立知识点每道题都能在真实代码里找到影子。题 1 对应表单默认值、接口兜底题 2 对应金额拼接和数字转型题 4 对应对象状态比较与 computed 重算题 5 对应动画循环、索引取余和连续区间判断。举个实际例子我刚说的 three.js 机房项目里有一段设备柜体闪烁动画逻辑const shouldBlink frame % 3 0 alarmLevel 0;如果frame可能为负数这个表达式就可能一直不为 true如果alarmLevel用||兜底它的合法值 0 就可能被吞掉。把一道面试题放到真实场景里你才会明白运算符不是用来考人的而是用来精确表达业务逻辑的。面试时你能从一道题延伸到这种生产细节基本就过关了。最后再分享一个我坚持很久的收尾动作。每次发版前我会花两分钟扫一遍 git diff 里所有改动过的表达式重点看有没有?.、??、、三元运算符和取余混合的行。有歧义就加括号能拆行就拆行。这个动作遇到过太多次了看着人畜无害的表达式可能就是你上线后线上告警的源头。你也值得把这个习惯加进自己的发布检查清单里。