TypeScript和JavaScript的区别

大白话 TypeScript 和 JavaScript 的区别是什么？
前端小伙伴们，有没有被\”类型BUG\”搞到抓头发过？比如把number传给需要string的函数，运行时直接报错；或者接手老项目，变量类型全靠猜，改一行代码崩三个功能……今天咱们就聊聊前端开发的\”类型保护神\”——TypeScript（简称TS）和它的\”原生大哥\”JavaScript（简称JS），用最接地气的话讲清核心区别，看完这篇，你不仅能选对工具，还能和面试官唠明白背后的逻辑～
一、写JS时的\”挠头瞬间\”
先讲个我上周踩的坑：给客户做数据可视化大屏，有个函数需要接收number类型的value计算百分比。结果前端传了\”100\”（字符串），后端直接用value / total计算，页面当场报NaN错误。最后花了2小时排查，发现是类型没对齐！
类似的场景还有：
调用组件时传错props类型（比如boolean传成string），页面渲染异常；
重构代码时改了变量类型，没通知其他同事，导致别人的代码报错；
看老项目代码，变量user可能是object也可能是null，每次访问都得加?.，生怕undefined。
这些问题的根源，都是JS的\”动态类型\”特性——变量类型运行时才确定，缺少编译期检查，容易埋雷。而TS的出现，就是来给JS加一道\”类型保险\”的～
二、从\”类型管理\”看本质区别
要搞懂TS和JS的区别，得先明白它们的\”类型管理哲学\”——JS是\”自由派\”（运行时类型随意变），TS是\”规则派\”（编译时约束类型，运行时和JS一样）。
1. 第一大区别：类型系统（动态 vs 静态）
JavaScript：动态类型语言（Dynamically Typed）。变量类型在运行时确定，可随时改变：
let a = 123; // 初始是number
a = \”abc\”; // 运行时可以变成string（不会报错）
TypeScript：静态类型语言（Statically Typed）。变量类型在编译时确定，不可随意改变（除非显式类型断言）：
let a: number = 123; // 声明为number类型
a = \”abc\”; // 编译报错：不能将类型\”string\”分配给类型\”number\”
2. 第二大区别：类型检查时机（运行时 vs 编译时）
JavaScript：类型检查在运行时进行。比如调用函数时传错类型，程序会在运行到那一行时崩溃：
function add(a, b) {
return a + b;
}
add(\”1\”, 2); // 运行时返回\”12\”（字符串拼接），可能不是预期的3
TypeScript：类型检查在编译时进行（通过TS编译器tsc）。传错类型时，编译器会直接报错，避免运行时崩溃：
function add(a: number, b: number): number {
return a + b;
}
add(\”1\”, 2); // 编译报错：参数\”1\”的类型\”string\”不可分配给\”number\”类型的参数
3. 第三大区别：类型扩展能力（基础 vs 高级）
JavaScript：只有基础类型（string/number/boolean等）和对象，无法自定义复杂类型。
TypeScript：扩展了丰富的类型系统，支持：
接口（Interface）：定义对象的结构；
泛型（Generic）：创建可复用的类型组件；
联合类型（Union）：变量可以是多种类型之一；
类型别名（Type Alias）：给复杂类型起别名；
枚举（Enum）：定义命名常量集合。
4. 第四大区别：工具支持（弱 vs 强）
JavaScript：IDE（如VS Code）只能通过推断提供有限的自动补全，复杂对象的属性提示容易出错。
TypeScript：编译器会分析类型信息，IDE能提供精准的自动补全、类型提示和错误警告，大幅提升开发效率。
三、代码示例：对比出真知
示例1：变量类型约束
// JavaScript：变量类型随意变（运行时可能出问题）
let age = 25; // 初始是number
age = \”二十五\”; // 运行时没问题，但后续用age做数学运算会报错
// TypeScript：变量类型固定（编译时检查）
let age: number = 25; // 声明为number类型
age = \”二十五\”; // 编译报错：不能将\”string\”分配给\”number\”
示例2：函数参数类型检查
// JavaScript：参数类型错误，运行时可能返回意外结果
function formatName(user) {
return `${user.firstName} ${user.lastName}`;
}
const user = { firstName: \”张\”, lastName: 3 }; // lastName是number
console.log(formatName(user)); // 输出：\”张 3\”（字符串拼接，可能不是预期的\”张三\”）
// TypeScript：定义接口约束user结构（编译时检查）
interface User {
firstName: string;
lastName: string; // 必须是string类型
}
function formatName(user: User): string {
return `${user.firstName} ${user.lastName}`;
}
const user = { firstName: \”张\”, lastName: 3 }; // lastName是number
formatName(user); // 编译报错：属性\”lastName\”的类型\”number\”不可分配给类型\”string\”
示例3：复杂类型支持（联合类型）
// JavaScript：无法约束参数是string或number，只能运行时判断
function printId(id) {
if (typeof id === \”string\”) {
console.log(id.toUpperCase()); // 字符串转大写
} else {
console.log(id); // 数字直接打印
}
}
printId(\”abc\”); // 正常
printId(123); // 正常
printId(true); // 运行时不报错，但逻辑错误（预期是string/number）
// TypeScript：用联合类型约束参数（编译时检查）
function printId(id: string | number) { // id可以是string或number
if (typeof id === \”string\”) {
console.log(id.toUpperCase());
} else {
console.log(id);
}
}
printId(\”abc\”); // 正常
printId(123); // 正常
printId(true); // 编译报错：参数\”true\”的类型\”boolean\”不可分配给\”string | number\”
示例4：IDE智能提示对比
// TypeScript：IDE能根据类型提供精准提示
interface Product {
name: string;
price: number;
inStock: boolean;
}
const product: Product = {
name: \”笔记本\”,
price: 4999,
inStock: true
};
product. // 输入\”.\”后，IDE会提示name、price、inStock三个属性
// JavaScript：IDE只能推断类型（如果没有JSDoc）
const product = {
name: \”笔记本\”,
price: 4999,
inStock: true
};
product. // 输入\”.\”后，IDE能提示属性（但如果product结构被修改，提示可能不准）
四、一张表总结核心区别

五、面试题回答方法
正常回答（结构化）：
“TypeScript与JavaScript的核心区别体现在以下几点：
类型系统：JS是动态类型（运行时确定类型），TS是静态类型（编译时确定类型）；
类型检查：JS的类型错误在运行时暴露，TS通过编译器在编译时检查；
类型扩展：TS支持接口、泛型、联合类型等高级类型，JS仅支持基础类型；
工具支持：TS的IDE支持更强大（精准补全、类型提示），JS依赖推断；
目标定位：JS是脚本语言，TS是JS的超集（最终编译为JS），更适合大型项目。”
大白话回答（接地气）：
“JS就像‘自由市场’——摆摊卖水果，今天卖苹果，明天可以改卖香蕉，没人管（变量类型随意变）。但坏处是，买水果的人可能拿到烂苹果（运行时类型错误）。
TS就像‘超市货架’——每个货架标得清清楚楚（苹果区、香蕉区），摆错位置会被理货员（编译器）拦住（编译报错）。虽然摆货时要按规则来（学类型系统），但顾客（开发者）拿东西更放心（类型安全），找东西也更快（IDE智能提示）。”
六、总结：3个选择原则+2个避坑指南
3个选择原则：
小项目/快速迭代：用JS——语法简单，上手快，无需额外编译步骤；
大项目/长期维护：用TS——类型明确，重构安全，团队协作更高效；
混合项目：用TS逐步迁移——可以给JS文件加// @ts-check，逐步添加类型注解。
2个避坑指南：
别为了用TS而用TS：小型项目（如简单的H5页面）用TS会增加编译和学习成本，可能得不偿失；
别忽略类型断言的风险：TS的as断言（value as Type）会跳过类型检查，滥用可能导致运行时错误。
错误示例：
const num: number = \”123\” as number; // 强制断言为number（实际是string）
console.log(num + 1); // 运行时输出\”1231\”（字符串拼接），不是预期的124
七、扩展思考：4个高频问题解答
问题1：TS会完全替代JS吗？
解答：不会！TS是JS的超集（所有JS代码都是合法的TS代码），最终会编译为JS运行。它更像是JS的“增强工具”，而不是替代品。对于小型项目或需要快速迭代的场景，JS仍然是更简单的选择。
问题2：TS的学习曲线难吗？
解答：基础用法不难！掌握number/string/boolean等基础类型，以及interface的使用，就能应对80%的场景。高级特性（如泛型、条件类型）可以在实际项目中逐步学习。
3. 如何将JS项目迁移到TS？
解答：分三步：
初始化TS配置：运行tsc –init生成tsconfig.json，配置allowJs: true（允许JS文件）；
逐步添加类型：从关键模块（如组件props、函数参数）开始，给变量添加类型注解；
解决编译错误：用// @ts-ignore临时忽略无法解决的错误（后续再修复），逐步完善类型。
4. TS会影响运行性能吗？
解答：不会！TS代码最终会编译为JS（和手动写的JS几乎一样），运行时没有额外性能开销。编译器会移除所有类型注解，只保留JS代码。
结尾：选对工具，代码更丝滑
TS和JS没有绝对的好坏，关键是根据项目需求选对工具。记住：
小项目要快——用JS；
大项目要稳——用TS；
长期维护要爽——用TS。
下次写代码时，再也不用纠结选TS还是JS啦～如果这篇文章帮你理清了思路，记得点个赞，咱们下期，不见不散！

原文链接：https://blog.csdn.net/qq_37212162/article/details/148458876