我曾是那个无论什么项目都坚持使用 TypeScript 的开发者。后端？用 TypeScript。前端？用 TypeScript。甚至一个五分钟就能写完的自动重命名文件的脚本？没错，也要用 TypeScript。这似乎很合理——毕竟静态类型能让一切更可靠，不是吗？
然而，事实并非总是如此。
经过多年强迫自己在所有项目中使用 TypeScript 后，我终于承认了一个事实：对于小型项目，TypeScript 带来的麻烦远大于它的价值。如果我要快速搭建一个 MVP（最小可行产品）、个人项目或简单的 API，TypeScript 已不再是我的默认选择。以下是原因。
1. 配置成本不值得投入
实话实说——TypeScript 需要大量配置：
- 编写
tsconfig.json - 确保依赖项兼容 TypeScript
- 安装和配置类型定义（
@types/xxx） - 调整构建流程
是的，我知道像 Vite、Next.js 或 Nuxt 这样的现代框架通过零配置模板简化了流程。但如果你从零开始搭建项目或未使用完整框架，这些配置依然存在——对于快速原型或脚本来说，这些阻碍完全没必要。
对于大型项目，这种配置是值得的。但对于一个小型项目（比如快速搭建的 API 或周末副业），为什么要花 20 分钟折腾配置，而不是直接写代码？
一个简单的 JavaScript 文件直接就能跑：
// index.js
console.log("你好，世界！");
而用 TypeScript，即使是最基础的代码也要多写几行：
const message: string = "你好，世界！";
console.log(message);
当然，你不需要显式声明 string 类型——TypeScript 会自动推断。但这个小例子让我意识到：即使是最简单的脚本，一旦引入 TypeScript，就会变得冗长和正式。当我想快速打印一条消息或调用 API 时，这种额外的抽象层更像是阻碍而非帮助。
而这还是在没配置构建流程的情况下。
2. TypeScript 会减缓实验速度
JavaScript 最大的优势之一就是它的灵活性。想要快速搭建一个概念验证？没问题。但使用 TypeScript 时，这种灵活性就消失了。
假设我正在尝试使用一个新的 API。在 JavaScript 中，我只需获取一些数据然后继续下一步操作：
fetch("https://api.example.com/data")
.then(res => res.json())
.then(data => console.log(data))
.catch(err => console.error(err));
而在 TypeScript 中呢？现在我需要定义类型：
interface ApiResponse {
id: number;
name: string;
email: string;
}
fetch("https://api.example.com/data")
.then(res => res.json())
.then((data: ApiResponse) => console.log(data))
.catch(err => console.error(err));
当然，TypeScript 允许你使用 any 类型，或者逐步引入类型。但这样做首先就违背了使用 TypeScript 的初衷，不是吗？我的观点是 —— 当我处于实验模式时，我根本不想考虑类型的问题。我想要快速得到反馈，不想有任何阻碍。
的确，这样做更安全 —— 但如果我只是在尝试一些新东西，为什么在我还不知道这个 API 是否有用之前就要编写额外的代码呢？
3. TypeScript 的优势在小项目中并不明显
我承认——TypeScript 能预防 Bug。但对于小型项目，这真的重要吗？
大多数情况下，TypeScript 在小项目中预防的“Bug”都是些我一眼就能发现的问题。
比如：
const age = "30";
console.log(age * 2); // 输出 NaN
TypeScript 会提示错误。但这种问题会让我夜不能寐吗？不会。如果整个应用只有 500 行代码，我完全不需要编译器保护——直接看代码就行。
4. 额外的构建步骤令人厌烦
用 JavaScript 可以直接运行脚本：
node script.js
而 TypeScript 需要先编译：
tsc script.ts && node script.js
对于大型项目？没问题。但如果只是写个快速工具脚本，这一步足以打断思路。
是的，你可以用 ts-node 跳过手动编译，但这又引入了额外复杂性。
5. 并非所有依赖库都兼容 TypeScript
你是否遇到过安装第三方包后立即报 TypeScript 错误的情况？
类型“SomeModule”上不存在属性“xyz”。
然后你去 GitHub 仓库一看，发现这个包根本不支持 TypeScript。现在你有三个选择：
- 找
@types/xxx类型定义（如果存在）。 - 自己写类型定义（太麻烦）。
- 用
any假装 TypeScript 不存在。
如果是大项目，我会花时间解决。但如果是小项目，这纯粹是自找麻烦。
何时仍应使用 TypeScript？
我并非否定 TypeScript——它依然适合某些场景：
✅ 大型应用（尤其多人协作时）
✅ 需要长期维护的项目
✅ 模块间依赖严格契约的代码库
但对于：
❌ 副业项目
❌ 快速脚本
❌ MVP 和原型开发
我坚持用 JavaScript。没有编译器的束缚，开发更快速、更简单、更快乐。
TypeScript 是工具，不是信仰
有些开发者将 TypeScript 视为 2025 年唯一正确的 JavaScript 写法。但事实并非如此。TypeScript 在合适的场景下非常强大，但强行用于所有项目？只会徒增烦恼。
如果你热爱 TypeScript，请在它真正有用的地方使用。但如果你的项目很小，而 TypeScript 的麻烦超过它的价值……或许它确实不值得。
你的看法如何？仍在所有项目中使用 TypeScript，还是学会了取舍？欢迎在评论区交流！
