低估了 typescript 的难度

any 解决一切问题

这个所谓的类型体操在我看起来就是炫技。技巧用得越多，后人（包括自己）在半年后再来看代码就跟看天书一样

js 和 ts 完全是烂出了两个极端

想给自己上强度就是这样的，
作为用 ts 写业务的后端，我每个项目都配好非常严格的 eslint ，然后写死编码风格 guideline 。基本上就是拿 ts 当 golang 和 java 来写。敢在项目里玩类型体操基本上 pr 我都是直接打回去，这样一套组合拳下去，至少项目代码是个人都能看懂了。也减少了成员作妖的几率

类型体操的话，如果你是自己维护一个 library ，让别人用，我觉得还可以

写业务，就别用类型体操了，不好维护，也没必要

正常开发中，都是把 TS 当高级一点的注释来写的，基本没什么难度。
哪有在业务里玩类型体操的？

typescript 上限极高，有点自知之明。

遇到难定义的类型，交给 gpt 比较省事

ts 能这么花里胡哨也不一定说你都得会，能用个 20 种都很 ok 了，我看了这个 repo 的很多类型例子，一大半以上奇奇怪怪的类型都是没事找事，纯为了恶心自己而恶心自己，随便找个例子

稍微复杂一点的 ts 类型，我写不出来，也看不懂。尽量用简单的，不行就加点儿注释。

使用 ts ，对自己是个提升。让自己多一种编程思想何尝不是大受益。
后续面对复杂的大项目，ts 不是得心应手。团队开发、风险控制等等

还好吧，问问 gpt 就好了，以前没 gpt 要 google 才真烧脑

实际业务代码里不会有这么复杂的类型体操

别别别，业务代码真别用复杂体操。

TypeScript 你区分清楚哪些是 type ，哪些是 js 的代码就很阿弥佗佛了！日常用起来基本不会有什么问题。最低标准是一个逻辑单元对外的要有类型，对内实在没办法的地方就用 any 与 as 。没必要追求处处都要类型自洽。

进阶一点，知道 narrowing 、一些类型自动推导的逻辑即可。

类型体操，即便是写 lib 也不是太推荐用复杂的类型体操。太多次的变换、跳转，让用 lib 的人查起来也是很费力。

后端仔表示：强类型 洒洒水啦

类型体操无所谓，关键这玩意只能编译时骗骗自己。。

我觉得 TS 适合做组件类的用，通用组件类用了 TS ，用起来顺心顺手。
但是业务代码用 TS 收益很低，有些复杂的内容，写起来恶心，维护起来更恶心（例如 9 楼那种），关键对代码的正向作用又很有限

感谢各位大佬。说的都很有道理。这下终于不纠结了~