TypeScript 对象、Record 字典、类与抽象类

TypeScript 不只给变量加类型，也能描述对象结构、字典映射和面向对象模型。

对象类型

const user: { name: string; age: number } = {
  name: "Alice",
  age: 25,
};

复杂对象通常会提取成 type 或 interface。

interface User {
  name: string;
  age: number;
}

Record 字典

Record<K, V> 用来表示键值映射。

const userAges: Record<string, number> = {
  Alice: 25,
  Bob: 30,
};

也可以限制 key 的范围。

type UserName = "Alice" | "Bob" | "Carol";
 
const scores: Record<UserName, number> = {
  Alice: 90,
  Bob: 88,
  Carol: 95,
};

索引签名

interface ScoreMap {
  [key: string]: number;
}

索引签名适合动态 key，但要注意它允许任何字符串 key。

类

class Person {
  constructor(
    public name: string,
    private age: number,
  ) {}
 
  greet() {
    return `Hello, ${this.name}`;
  }
}

常见访问修饰符：

public：外部可访问
private：只在类内部可访问
protected：类内部和子类可访问

继承与重写

class Student extends Person {
  override greet() {
    return `Student: ${this.name}`;
  }
}

抽象类

抽象类不能直接实例化，通常用来定义一组子类必须实现的能力。

abstract class Animal {
  abstract speak(): string;
}
 
class Dog extends Animal {
  speak() {
    return "woof";
  }
}

抽象类适合有共享实现和强约束的场景。

延伸理解

复习这篇时，不要只记住名词，要把重点放在 对象类型、Record 字典、索引签名、类、继承、override 和抽象类。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。

TypeScript 的价值是把运行时不确定性尽量前移到开发阶段，但它不能替代运行时校验。
类型设计应优先描述业务约束，而不是为了炫技使用复杂泛型。
遇到第三方输入、JSON、表单和 API 响应时，要结合类型收窄或 schema 校验。

在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。

实践检查清单

明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
最后用一句话总结取舍：它牺牲了什么，换来了什么。

自测问题

这个主题解决的核心问题是什么？
如果不用当前方案，还有哪些替代方案？代价是什么？
最容易出错的边界条件在哪里？
如何在代码、测试或监控中验证它真的可靠？

项目化应用场景

可以把这类知识放到一个前后端共享类型的项目里理解：API 返回 JSON，前端先用 schema 做运行时校验，再把校验后的数据交给 TypeScript 类型系统。类型可以帮助编辑器提示和编译期检查，但不能保证网络返回一定正确。好的类型设计应该表达业务约束，例如角色、状态、权限、请求参数和响应结构，而不是所有地方都写成 string 或 any。

常见误区：

把 TypeScript 类型当成运行时校验。
为了省事使用 any，导致错误延后到线上。
泛型过度复杂，让调用者难以理解。

目录