这样的标题其实很容易被很多 TS 拥护者怼的，就好像 Vue 和 React 两大战线的拥护一样。 我这里说的「好用」，其实已经承认 TypeScript 至少是有用的，至于好不好用只是我的个人客观评价。

而且 TS 是 JS 的超集，听名字就挺高大上的。之所以学习并使用 TS，也是因为它确实最近很火，火到什么地步呢： 你几乎在网络中找不到反对的声音，很多组件、插件都推出了 TS 版本或者天然兼容 TS。 所以客观来说，TS 必然是前端发展趋势。

其实熟悉更多语言的开发者都会发现一个规律：JS、Java 都在慢慢向 C 语言靠拢。 但即便如此，我依旧认为：TypeScript 并没有想象的那么好用。

相信很多开发工作，至少一半以上的项目都处在敏捷开发模式中。 不知道大家有没有发现：我们在解决 TS 类型、校验问题的时间，往往大于业务逻辑开发本身。

---

一、第三方插件引入，额外适配类型成本

我们引用第三方插件时，JS 阶段直接查看文档 API 即可； TS 虽然编辑器类型提示很香，但因为加了强类型校验，必须额外寻找、导入对应类型声明，否则直接爆红报错。

示例对比：

javascript复制
// JS 版本
import { createSlice } from "@reduxjs/toolkit";
// …………
export const systemSlice = createSlice({
  name: "system",
  initialState,
  reducers: {
    setUserInfo: (state, action) => {
      state.userInfo = action.payload;
    }
  }
});

typescript复制
// TS 版本
import { createSlice, PayloadAction } from "@reduxjs/toolkit";

export const systemSlice = createSlice({
  name: "system",
  initialState,
  reducers: {
    setUserInfo: (state, action: PayloadAction) => {
      state.userInfo = action.payload;
    }
  }
});

初期为了快速开发，很多人会直接用 any 暴力解决； 但有代码洁癖的开发者，会主动查阅插件是否自带类型定义。 部分小众插件无原生 TS 类型，还需要手动通过 declare module "xxxx" 声明模块才能消除报错。

---

二、代码量成倍增加，类型定义冗余繁琐

一份 JS 只需 100 多行的业务代码，改用 TS 往往要写到 200 多行。 多出的代码基本都是类型声明、接口定义，算不上无效冗余，但会大幅降低代码阅读、评审体验。

日常开发中，为了精简业务代码，通常会把大量类型抽离到单独类型文件中管理。

typescript复制
// 需单独定义类型，量大时需拆分独立 ts 类型文件
interface propsInterface {
  visible: boolean;
  onCancel: { (): void };
  onOK: { (): void };
  info: any;
}

// 函数组件使用类型约束
export default ({ visible, info, onCancel, onOK }: propsInterface) => {
  // 业务逻辑...
}

---

三、后端返回数据不可控，被迫滥用 any

前后端分离项目中，后端接口返回格式时常不稳定、字段不固定、兼容历史参数。 严格约束结构会频繁报错，为了项目正常迭代，只能被迫使用 any 兜底，违背 TS 强类型初衷。

typescript复制
axios.get("/admin/country-code").then((res: any) => {
  // 数据处理逻辑
});

个人开发习惯上，本身非常排斥在 TS 中大量使用 any，但业务场景下往往身不由己。

---

四、需求频繁变更，类型需要同步维护

敏捷开发下，需求调整、接口字段增减、业务逻辑修改都是家常便饭。 使用 JS 只需要改业务逻辑即可； 使用 TS 时，修改、新增、删除字段/参数，都需要同步修改对应接口、类型、枚举。

即便关闭严格校验不影响编译运行，但编辑器全局爆红、波浪线报错，开发体验极差。

---

五、深层嵌套类型，编写与维护成本极高

面对复杂嵌套对象、多层级表单、树形结构、级联数据等场景， 深度类型定义编写极其繁琐，需要逐层约束每一个字段、子项、可选参数，稍有遗漏就会校验失败。

---

六、语法兼容偶有异常，常用简写频繁报错

TS 虽是 JS 超集，但部分 JS 原生简写语法，在 TS 严格模式下会莫名爆红报错。

javascript复制
// JS 原生优雅简写：可选链调用
a?.change()

TS 中部分低版本/严格场景下，可选链语法识别异常，只能改用冗余写法兼容：

typescript复制
// TS 规避报错的保守写法
a && a.change && a.change()

---

综上： 在用 TS 开发项目时，会持续花费大量时间处理类型报错、类型适配、类型维护； 尤其团队或个人对 TS 语法不熟悉的前提下，开发效率会明显下降。 所以在项目技术选型阶段，是否引入 TS，需要结合项目实际场景综合考量。

---