聊 TypeScript 的对象类型，其实是很多前端从 JS 转 TS 之后第一个觉得“别扭”的地方。我们平时写对象字面量，{ name: 'Tom', age: 18 }，看起来理所当然，但到了 TS 里，要给一个对象写出“类型”，就牵扯到type、interface、索引签名、映射类型、继承这些语法规则。这篇内容算是对象类型语法的一个完整梳理，适合两类人：一类是刚入门 TS，想把对象相关语法一次性吃透的；另一类是准备面试、需要快速把对象类型相关的概念和坑点理清楚的。我会从底层语法逐步讲到设计取舍，配合代码示例，尽量还原我在真实项目里写过的用法和踩过的坑。目标很简单：看完之后，你对“对象类型”这几个字的理解，不再只是interface加个花括号。
1. 先理解对象类型的本质：它描述的是一张形状蓝图
1.1 为什么对象类型是 TS 学习的分水岭
很多从 JS 转 TS 的人，第一眼看到interface User { name: string }会觉得这不就是“给对象加了个类型”嘛，没什么特别的。但真正开始写复杂业务之后，才会发现对象类型远不止一个花括号那么简单。它包含了属性修饰符、函数签名、索引约束、类型组合、映射变换等一系列规则。可以说，对象类型是 TS 类型系统里信息密度最高的一块，也是面试中几乎必考的一块。理解了对象类型，等于理解了 TS 的核心思维方式：静态地描述数据的形状。
在 TS 的类型系统里，对象类型描述的是“值应该长成什么样”，而不是“这个值来自哪个类”。这就是所谓的结构化类型系统（structural typing）。只要你传入的对象在形状上匹配，类型检查就会通过，不管它是不是通过某个特定构造函数创建的。这也是 JS 开发者最容易接受的模型：JS 本来就没有严格的类层级，我们更关心“这个对象里有哪些字段、这些字段是什么类型”。
1.2 对象类型在工程里的两种角色
在实际项目里，对象类型通常承担两种角色。第一种是数据容器的描述，比如接口返回的userInfo、表单提交的loginForm，这类类型主要约束数据字段的完整性和类型正确性；第二种是“契约”的描述，比如某个函数要求传入的对象必须包含特定方法，或者组件props必须满足某些条件。这两种角色对应的语法偏好也不同：描述数据字段时，我们更常用interface或者type别名，注重可读性和扩展性；描述契约时，我们可能会加上readonly、可选属性、索引签名等细节，让类型的约束力更强。
理解这两个角色，就能理解为什么对象类型的语法这么多：每个语法糖背后，其实都是不同场景的诉求。比如readonly是为了保护数据不被意外修改，?是为了表达“这个字段可能没有”，索引签名是为了应对真正的动态对象，映射类型则是为了从已有形状批量派生新形状。后续内容都会围绕这些诉求展开。
2. 对象类型基础语法：三种写法和两个高频修饰符
2.1 三种声明方式：内联、type、interface
先看最简单的写法。第一种是在变量声明处直接写内联类型，适合一次性使用的小对象：
const user: { name: string; age: number } = { name: 'Tom', age: 18 };第二种是用type起一个类型别名，适合复用性较强的形状：
type User = { name: string; age: number; };第三种是用interface声明接口：
interface User { name: string; age: number; }这三种方式在日常代码里都很常见。从语法规则上讲，type和interface在本例中几乎没有区别，都能描述对象形状，也都能被赋值给变量。区别藏在更复杂的场景里：interface有声明合并能力、可以被extends继承；type则可以通过交叉类型、联合类型、条件类型组合出更复杂的类型。后面我会专门用一章来对比，这里先记住结论：能描述对象形状的语法不止一种，选型取决于是否需要继承、是否需要组合、是否需要声明合并。
内联类型最容易被忽略的坑是：它会把结构“焊死”。如果你在一个函数参数里写了{ name: string }，那么外部声明的变量只要形状匹配都可以传入，但如果你直接传入对象字面量并且字面量里多了一个多余属性，就会触发多余属性检查（excess property check）。这个行为经常让人困惑，后文会详细解释。
2.2 可选属性：?的语义和隐式 undefined
给属性加上?表示这个属性是可选的，例如：
interface User { name: string; age?: number; }这里age?的含义是：age可以不存在，也可以存在并且值是number。但要注意，它并不等同于age: number | undefined。两者的区别在细节上：显式声明age: number | undefined，那么属性必须存在，只是值可能是undefined；而age?: number允许属性整个被省略。在开启strictNullChecks的情况下，读取age时它的类型会被推断为number | undefined，所以访问前需要做存在性判断。
还有一个容易被忽略的点：可选属性在运行时的表现。TS 的类型系统不会替你补上缺失的属性，const u: User = { name: 'Tom' }编译后就是原样输出，u.age在运行时就是undefined。也就是说，类型层面的“可选”只是静态约束，运行时仍需按 JS 的实际情况处理。这一点在面试里经常被问，很多人背了“可选属性可以省略”就以为万事大吉，结果一到运行时数据里没有这个字段时，代码直接抛错。
2.3 只读属性：readonly的边界和写操作限制
readonly修饰符用来标记属性不可被重新赋值：
interface Config { readonly server: string; readonly port: number; } const config: Config = { server: 'example.com', port: 443 }; config.server = 'other.com'; // 报错：Cannot assign to 'server' because it is a read-only property需要注意的点有三个。第一，readonly只作用于当前属性的直接赋值，它不会递归地将嵌套子对象变成只读。如果你有这样的类型：
interface Setting { readonly theme: { color: string; }; }那么setting.theme = somethingElse会报错，但setting.theme.color = '#fff'是合法的。要想深层只读，需要使用as const或者递归的映射类型，比如DeepReadonly<T>。第二，readonly不是完全不能绕过，比如在构造函数里、或者通过类型断言，依然可以修改。所以它更多是一种“约定性保护”，而不是运行时冻结。第三，如果两个对象类型结构相同，一个属性是只读的，另一个不是，它们之间赋值时到底兼容不兼容？
interface ReadonlyA { readonly x: number; } interface MutableA { x: number; } let ra: ReadonlyA = { x: 1 }; let ma: MutableA = { x: 2 }; ra = ma; // 可以 ma = ra; // 报错这个结果初看很奇怪。实际上 TS 允许把可变对象赋值给只读类型，因为只读不会让读取变得不安全；但反过来把只读对象赋值给可变类型时，因为接收方可能会尝试修改属性，而源对象在声明上不允许，所以会报错。这种“单行线”规则在组件传参时经常遇到，尤其是当子组件声明的 props 属性带 readonly、而父组件传入可变对象时。
3. 函数属性、索引签名和对象字面量的边界行为
3.1 函数属性的三种写法：属性、方法、重载
对象类型里也能描述方法，而且有至少三种写法，这在很多教程里都不会细讲。
interface Api { // 写法一：函数属性 getUser: (id: number) => string; // 写法二：方法简写 getPost(id: number): string; // 写法三：带属性函数（可以同时有调用签名和属性） log: { (msg: string): void; version: string; }; }写法一和写法二在多数场景下可以互换，但在严格模式下有一个重要区别：方法简写（getPost(id: number): string）在函数参数是双向协变时（bivariance）会被宽松处理，而函数属性写法（getUser: (id: number) => string）在strictFunctionTypes下对参数做逆变检查。简单说，方法简写更容易兼容，函数属性检查更严格。官方更推荐在接口里使用方法简写来描述类的实例方法，在描述普通回调函数时使用函数属性。
还有一个细节：函数属性还能携带自己的属性，比如上面的log写法，这在描述“可调用且带元信息的函数对象”（例如某些库的ajax函数同时带ajax.get）时很有用。这种语法来自 TS 的对象类型扩展能力，本质上是把函数类型和对象结构的规则融合在一起。
3.2 索引签名：动态对象的类型钥匙
当我们处理真正动态的对象时，属性名并不是固定的，而是从某些规则里产生。比如缓存对象、字典表、事件映射表。这时需要索引签名：
interface StringMap { [key: string]: number; } const scores: StringMap = { math: 95, english: 88, };索引签名规定：所有字符串属性的值都必须是number。这里有三个容易被坑的地方。第一，数字索引和字符串索引要兼容。JS 中对象键会被强制转成字符串，所以如果定义了[key: string]: number，不能再定义[key: number]: string，因为两者冲突；相反，如果定义了[key: number]: string，字符串索引也必须接受对应的字符串类型，因为数字键在访问时会转成字符串。第二，索引签名会影响interface里其他具体属性。如果类型里声明了一个实名字段，它的类型必须和索引签名字段类型兼容：
// 正确 interface Mixed { [key: string]: number | string; id: string; score: number; } // 报错：Property 'id' of type 'string' is not assignable to 'number' index type interface Wrong { [key: string]: number; id: string; }第三，索引签名会让对象字面量的多余属性检查失效一部分。一旦类型声明了索引签名，TS 就不会再像普通对象类型那样严格提醒“这个 Key 不在类型里”，因为任何字符串 Key 都可能被接受。这意味着你可能会在编译阶段漏掉一些拼写错误，只能靠运行时或 lint 兜底。
3.3 对象字面量的新鲜度检查、解构和展开
TS 对“直接把对象字面量赋给类型”的场景有一项额外检查：新鲜度检查（freshness）。如果变量是通过字面量方式直接传入，TS 会检查字面量里是否有多余属性，而不只是形状是否匹配：
interface User { name: string; age: number; } function printUser(u: User) {} printUser({ name: 'Tom', age: 18, grade: 3 }); // 报错：grade 不在 User 类型中 const user = { name: 'Tom', age: 18, grade: 3 }; printUser(user); // 不报错：user 不是新鲜字面量，形状匹配即可这个规则的意图很明确：直接传入字面量时，多出来的属性大概率是写错了，所以提前提醒你；但当你把对象先存进变量再去传递时，TS 会静默地进行结构化类型比较，不再做多余属性检查。这个差异在重构代码时尤其容易踩坑：把字面量提取成变量之后，某些拼写错误就从编译报错变成了运行时问题。
解构和展开是 JS 里常用的对象操作，TS 对它们的类型推断也有一套规则。解构时，TS 会根据对象的类型推导出每个变量的类型；展开运算符会把多个对象的类型“合并”成新的对象类型，但同名属性会以后面的对象类型为准。有时展开复杂对象后，你会丢失原有接口的引用关系，所以如果用起来不舒服，可以考虑先定义类型再展开。
4. 对象类型的组合玩法：interface 继承和交叉类型
4.1 interface extends 的继承规则：单继承和多继承
interface支持继承，这是面试里高频追问的点。基本语法是：
interface Animal { name: string; } interface Dog extends Animal { breed: string; }Dog类型会同时包含name和breed两个字段。interface还可以一次继承多个接口：
interface Swimmer { swim(): void; } interface Runner { run(): void; } interface Athlete extends Swimmer, Runner { sport: string; }多个接口继承时，如果其中有同名字段，那么新接口里的同名字段类型必须同时是父接口字段类型的子类型，实际上要求它们在一个类型层级上是兼容的。如果多个父接口的同名字段类型完全不兼容，比如一个规定id: string、另一个规定id: number，那么extends会直接报错，这是和交叉类型（&）不一样的地方。
继承如果层级比较深，会带来一些使用上的负担：你看到Dog类型，但不知道它到底继承了多少属性和方法，命名冲突也会随着层级增加而变得复杂。我个人的经验是：接口继承适合表达“自然的层级关系”，比如动物->狗->导盲犬；如果只是想把几个通用字段拼起来，优先考虑用交叉类型或者组合型写法，而不是为了“看起来面向对象”硬拉继承链。
4.2 交叉类型&与 interface extends 的核心区别
交叉类型写法是用A & B把两个对象类型“合起来”：
type Combined = Animal & Swimmer;它和interface extends的区别在于两点。第一，交叉类型可以作用在任意类型上，包括联合类型、映射类型、甚至函数类型；interface extends只能继承对象类型。第二，遇到同名字段时，交叉类型会把字段类型做交集运算而得到更严格的类型。举个例子：
interface A { id: string; value: number; } interface B { id: number; value: string; } type C = A & B;此时C的id类型会被认为是string & number，也就是never；value同理，也是never。这种结果往往不是你想要的，而且很隐蔽。相比之下，interface extends不允许这样明显的冲突，在编译阶段就会报错。
在做组合时，我的建议是：如果目标是生成一个完全新的对象类型，优先用interface extends或者把字段直接写在新的类型里，好读也好维护；如果目标是把多个独立维度（比如“可展示”“可点击”“有样式”）组合成一个临时结构，交叉类型会更灵活。注意：交叉类型并不会物理上合并运行时对象，它只是类型层面的交集，这一点在实现代码时不要误以为Object.assign会自动发生。
4.3 implements 和对象类型的现实约束
implements用于类实现接口：
interface Printer { print(content: string): void; } class ConsolePrinter implements Printer { print(content: string) { console.log(content); } }一个常见的误区是：对象字面量不能使用implements。implements只能跟类搭配，对象只能用as断言或者直接使用类型标注。另一个误区是implements只需要类提供同名同类型成员即可，并不要求成员完全来自类的直接定义；私有字段、静态字段并不在接口检查范围里。所以接口更像一份“外部公开约定”，而不是对类内部实现的约束。
如果配合readonly和可选属性，implements会产生一些很实际的约束：比如类里必须显式声明只读属性，然后在构造函数里初始化；可选属性在实现时仍然要声明，否则 TS 不会自动帮你补全。很多初学者写implements时报错，往往不是因为方法没实现，而是属性类型和接口不完全兼容，尤其是number | undefined和number这类细小的差异。
5. 映射对象类型：从已有对象类型批量生成新类型
5.1 核心语法：in keyof 的批量推导
映射类型（Mapped Types）是对象类型语法里最具生产力和“高级感”的一部分。它的核心语法是在类型层面遍历已有对象类型的键，并生成新的对象：
type Readonly<T> = { readonly [P in keyof T]: T[P]; };这里的keyof T会拿到T的所有键组成的联合类型，[P in keyof T]表示遍历这个联合类型里的每个键，而T[P]表示取原类型中对应属性的类型。来看一个实际使用案例：
interface User { name: string; age: number; } type PartialUser = { [P in keyof User]?: User[P]; }; // 等价于 { name?: string; age?: number }这种类型变换在业务里非常实用，比如你有一个完整的实体类型，需要把其中所有字段变成可选的，以适配编辑页面的草稿状态；或者把所有字段变成只读，以表达数据层只读快照。映射类型之所以叫“映射”，是因为它就像数组的map：输入类型、产出新类型，原类型本身不会被修改。
keyof和索引访问类型是理解映射类型的两个基石。如果你在面试中被问到映射类型，最快的方法是直接手写一个Partial<T>或者Pick<T, K>的实现，比背定义有用很多。
5.2 修饰符增减：-?和-readonly的魔力
除了遍历键，映射类型还能修改属性修饰符。标准的内置工具Required<T>就是把所有可选属性变成必选：
type Required<T> = { [P in keyof T]-?: T[P]; };注意这里用的是-?，表示去除可选性。同理，-readonly表示去除只读修饰：
type Mutable<T> = { -readonly [P in keyof T]: T[P]; };默认情况下，映射类型会保留原属性身上的readonly和?修饰，因为它在in遍历时沿用了原有修饰符。如果你想强制加上或者强制去掉，就需要显式用+和-。+可以省略不写，也就是readonly和?默认就是+语义。这个概念看起来简单，但实际业务中很常用。比如编辑用户时，你想把id保留为只读，其他字段变成可修改：
type Editable<T, K extends keyof T> = { readonly [P in keyof T]: T[P]; } & { -readonly [P in K]: T[P]; };这里通过交叉组合，实现了“原本只读的字段，只有指定键可写”的效果。不过要注意，这样写出来的id会同时出现在两个交叉成员里，最终可编辑性取决于你如何使用和赋值，实际用起来要多测试几次才能确保类型约束符合预期。
5.3 从对象类型派生子类型的常用工具：Partial、Required、Pick、Record
TS 内置了多个基于映射类型的实用工具，工程里几乎天天用。挑几个重要的来说：
Partial<T>：把T的所有属性变为可选，适合做局部更新场景。Required<T>：把T的所有可选属性变为必选，适合在数据处理完成后再使用。Readonly<T>：把T的所有属性设为只读，适合作为全局配置的类型。Pick<T, K extends keyof T>：从T中选取部分属性生成新类型，适合接口返回精简视图。Record<K, T>：用一个键联合类型构造一个对象类型，所有值都是T，适合创建映射表。
看一个实际使用Pick和Record的例子：
interface User { id: number; name: string; email: string; phone: string; } type PublicUser = Pick<User, 'name' | 'email'>; type Role = 'admin' | 'editor' | 'viewer'; type RolePermissions = Record<Role, string[]>;Record的底层其实就是映射类型，可以把它理解为{ [P in Role]: string[] }。在某些企业内部后台系统里，经常会用Record来描述菜单权限、操作权限和用户角色之间的映射关系，改起来非常直观。需要注意的是，Record的键集合如果是个空联合类型，生成的对象类型是{}，访问任何键都会报错，这在泛型推导时偶尔会遇到。
6. 常见问题与排查经验：面试和工程里的高频坑
6.1 面试高频：interface 和 type 到底怎么选
这个问题几乎是 TypeScript 面试的必问题，但回答时最容易陷入“背区别列表”的模式。我更建议用一个统一的思路来回答：首先说明两者都能描述对象类型，语法上在大多数场景等价；然后指出关键差异——interface支持声明合并，能通过extends继承，适合定义公开 API 和可扩展的数据契约；type支持联合、交叉、映射、条件等更复杂的类型组合，适合表达计算出来的类型和复杂结构。最后结合实际项目给结论：对外接口、组件props、类实现的契约优先用interface；需要做工具类型、联合类型、映射类型时用type。这个回答既覆盖了知识点，又体现了工程判断。
如果是现场手写，可以补充一个细节：interface可以多次声明同名接口，TS 会自动合并属性；type不允许声明重名。这个声明合并机制在库开发中经常用到，比如为全局对象扩展属性时，通常会写：
interface Window { __customFlag?: string; }这比用类型断言更安全，也是interface不可替代的场景之一。
6.2 对象字面量推断与as const：类型拓宽的坑
一个隐性但高频的坑是类型拓宽（widening）。比如：
const config = { mode: 'dark' };mode被推断为string，而不是字面量类型'dark'。如果某个接口要求mode: 'dark' | 'light'，直接把这个config传进去会报错，因为string范围太大了。解决办法有两种：一是显式标注类型：
const config: { mode: 'dark' | 'light' } = { mode: 'dark' };二是使用as const：
const config = { mode: 'dark' } as const;as const会把所有属性都推断成 readonly 字面量类型，用起来更省事，但也意味着不能随意修改属性。我在实际写业务时，对于“配置项、常量对象、枚举映射表”这类只读数据，基本都会用as const；对于需要后续修改状态的对象，则优先显式标注类型。如果不去主动控制拓宽，等到传参报错时再回头补，往往已经埋下了不少运行时隐患。
6.3 泛型约束里的对象类型：extends object和keyof的边界
写泛型函数时，我们经常需要约束“传入参数是一个对象”。初学者第一反应是写T extends object，但这其实是一个容易出问题的约束，因为object类型不包含原始类型（string、number、boolean都不在object里），而null和undefined在严格模式下也不能赋值给object。如果你的函数要求接受任意非原始值，T extends object是有效的，但如果想接受普通对象字面量，用T extends Record<string, any>会更贴合直觉。
keyof和泛型约束的组合是另一个高频面试点：
function getValue<T, K extends keyof T>(obj: T, key: K): T[K] { return obj[key]; }这里K extends keyof T保证了传入的键必须是T中实际存在的键。如果你在项目里封装过表格组件的列配置、表单字段联动配置，这种写法一天到晚都会用到。需要特别注意的是：keyof对interface和类型别名结果相同，但如果对象类型有索引签名，keyof会把索引签名的键类型也包含进来，比如keyof StringMap会得到string | number，这在某些场景下会让泛型约束失效。
6.4 排查思路：对象类型报错时怎么快速定位
面对对象类型报错，我的排查顺序通常是三层。第一层看“形状是否匹配”：最直接的错误是对象里缺少了必选属性，或者属性类型不一致，比如string给了number，这类报错信息通常很明确，照着报错修改即可。第二层看“修饰符问题”：是不是把readonly属性当成可变属性去写了？是不是把可选属性?和显式联合| undefined混用了？这些报错也容易认出来，因为它们会非常强调 readonly、optional 等关键词。第三层是“映射类型和泛型推导问题”：报错往往出现在函数内部，而不是在对象字面量赋值处，这时我会先简化类型参数，把映射类型展开，看看展开后的目标类型到底长什么样子。
还有一个很实用的调试小技巧：在类型报错的位置，用as const或者临时显式标注一个unknown中间变量，把数据“隔离”出来，再分步观察哪里开始不兼容。很多复杂报错其实是多层类型组合导致的可读性灾难，和实际逻辑无关；拆开一层一层排查，比在报错文本里死磕效率高很多。
7. 我实际项目中总结的几条对象类型写法和优化经验
每个项目写完一轮，多多少少会沉淀出一些属于自己的编码偏好。我在业务代码里最常遇到的对象类型相关经验，大概有这么几条。一是能用组合解决的问题，尽量不堆继承层级；接口继承超过三层，代码阅读成本会急剧上升，尤其是多人协作时，别人要看完整字段往往要顺着继承链翻好几次。二是区分“数据模型”和“接口契约”：从后端接口拿来的原始数据，我倾向于为它单独定义类型，而不是直接拿前端组件的 props 类型去套，因为接口字段可能有缺省、兼容性问题，前端展示字段则相对固定。三是对待可选属性要有洁癖，能必选就必选，能显式undefined就显式写，尽量不要大面积使用?，否则代码里到处都要做空值判断，类型保护的价值会大打折扣。
另一个让我印象很深的场景是表格组件封装。我们曾经为了支持动态列配置，写了一个类似于通过keyof T和Pick<T, K>来自动生成列配置类型的通用组件：
type ColumnBase<T> = { key: keyof T; title: string; render?: (value: T[keyof T], record: T) => JSX.Element; };这里key: keyof T配合value: T[keyof T]时，其实不能保证每个key对应的value类型是精确匹配的，因为keyof T是联合类型，函数内部接收的是联合类型中的任意一种。更精确的写法需要把列配置构造成泛型数组，并用一个as const或具体泛型约束去表达“每一列的值就是该键对应的值类型”。这类类型层面的“精确匹配”是最容易让人头疼的地方，一旦拐过这个弯，很多表格、表单、权限映射组件都能做到类型安全。
还有一次在报表项目里，我们需要把后端返回的大量字段映射到一个筛选器中，字段的可选性非常复杂。当时我直接手写了一套基于映射类型和条件类型的工具：
type Filterable<T> = { [K in keyof T as T[K] extends string ? K : never]?: string; };通过as重映射键，把值不为string的字段直接从新类型里剔除，这样筛选器类型就只会包含那些字符串字段。这种类型层面的“动态剔除”写起来虽然有点绕，但带来的收益非常大：后续如果后端新增或删减字段，只要原始类型更新，筛选器类型也会跟着自动更新，不需要人肉维护。映射类型中的as重映射语法从 TS 4.1 开始支持，用于处理这类需求非常顺手。
最后再提一下和对象类型相关的调试工具。在 VsCode 里鼠标悬停在变量上可以看推导类型，但遇到复杂的条件类型和映射类型时，推导结果经常以很长的展开形式展示，看起来十分劝退。我习惯用type Expand<T> = { [K in keyof T]: T[K] }这种“展开”类型，把复杂类型“压平”之后再鼠标悬停，看到的就简洁多了。这个小技巧在我排查那些由泛型推导出来的对象类型时，几乎每次都用得上。对象类型的语法规则确实很多，但大部分业务的诉求其实非常朴素：希望能把对象数据的形状说清楚，能安全地被复用和扩展。把这些基础规则掌握好，再复杂的类型报错也不会把你难住。
