TypeScript 是带类型检查的 JavaScript 增强版，所有合法 JS 代码都合法，但通过编译时检查提前拦截空值等错误；优先用 interface 定义可扩展业务对象，unknown 替代 any 保障安全，类型是需持续维护的活契约。
TypeScript 不是 JavaScript 的替代品，而是它的“带类型说明书的增强版”——所有合法的 JavaScript 代码都是合法的 TypeScript 代码，但 TypeScript 多了一层编译时类型检查，把大量运行时才暴露的问题提前拦在写完代码的那一刻。
为什么 tsc 编译能提前发现 80% 的低级错误？
JavaScript 运行时才报错：
function getUserAge(user) {
return user.profile.age + 1; // 如果 user 没有 profile，或 profile 没有 age → TypeError: Cannot read property 'age' of undefined
}TypeScript 在写完就标红：
interface User {
profile?: { age: number };
}
function getUserAge(user: User): number {
return user.profile.age + 1; // ❌ 编译报错：Object is possibly 'undefined'
}- 类型检查发生在保存文件瞬间（配合 VS Code），不等你点“运行”
- 错误不是靠测试用例触发，而是靠结构定义自动推导
-
user.profile?.age或if (user.profile)才能过编译 —— 强制你面对空值场景
any 是最危险的“快捷键”，unknown 才是安全起点
很多团队初期为了“快速迁移”，大量用 any：
function parseData(json: string): any {
return JSON.parse(json);
}
const data = parseData('{"id": 1}');
data.toFixed(); // ❌ 不报错（但运行时崩溃）
正确做法是用 unknown + 类型守卫：
function parseData(json: string): unknown {
return JSON.parse(json);
}
const data = parseData('{"id": 1}');
if (typeof data === 'object' && data !== null && 'id' in data) {
console.log((data as { id: number }).id); // ✅ 安全访问
}
-
any：关掉所有类型检查，IDE 补全失效，等于退化成 JS -
unknown：强制你做判断，编译器全程盯着你“是否已确认类型” - 真实项目中，把
any当作技术债标记，每次 review 都要问：“这里能不能换成具体接口或联合类型？”
接口（interface）比类型别名（type）更适合业务对象
当你定义用户、订单、配置项这类有明确结构和扩展需求的实体时：
interface User {
id: string;
name: string;
}
// 后续可单独扩展，无需修改原定义
interface User {
permissions: string[];
}
// 最终 User 自动合并为 { id: string; name: string; permissions: string[] }
而 type 不支持声明合并，更适合描述“形态”：
type Status = 'pending' | 'success' | 'error'; type ApiResponse= { data: T } | { error: string };
- 接口可被类
implements、被其他接口extends，工程扩展性更强 - 类型别名适合联合、泛型、映射等高级组合，但不能被继承或实现
- 混用没问题，但别把
type User = { ... }当成接口用——它无法被后续扩展
TypeScript 的真正优势不在语法多酷，而在它把“人脑里想的结构”变成编译器能验证的契约。最容易被忽略的一点是：类型不是写完就扔的文档，而是要随着逻辑演进持续维护的活契约——比如 API 响应字段变了，只改 JS 层代码？不行；必须同步更新接口定义，否则下一个人调用时，类型提示还在骗他。
