写过一段时间TypeScript的人，大概都见过T[K]这种写法。它叫索引访问类型（Indexed Access Type），作用是从一个对象类型中按照key取出对应的属性类型。写法本身很简单，但一旦和泛型、映射类型、条件类型组合起来，报错信息就开始变得难以理解，比如“Type 'string' is not assignable to type 'T[K]'”。这类问题的根源，多半出在类型兼容性约束在索引访问类型内部的传播规则上。
索引访问类型的基本求值规则
先看最基础的场景。假设有下面这个类型：
interface Person {
name: string;
age: number;
address: { city: string };
}
type NameType = Person["name"]; // string
type AddressCity = Person["address"]["city"]; // string
type AllValues = Person[keyof Person]; // string | number | { city: string }当key是具体的字面量时，TypeScript会直接把对应的属性类型取出来，这一步没有任何歧义。而当key是keyof Person这种联合类型时，结果会变成所有属性类型的联合。这个规则很重要：联合的key产生联合的值类型。
真正容易出问题的是key是未解出的泛型。比如：
function get<K extends keyof Person>(p: Person, k: K): Person[K] {
return p[k]; // 报错：不能将 Person[K] 赋给 Person[K]
}看起来返回值类型和表达式类型完全一样，为什么还报错？因为编译器此时无法确定K的具体值，它只能把p[k]推断为一个占位的延迟求值类型，而这个占位类型在可赋值性检查上和声明处的Person[K]并不总能画等号。这是TypeScript设计上的保守选择：与其放行可能在实例化后出错的代码，不如先拦下来。解决办法通常是显式断言或改写结构：
function get<K extends keyof Person>(p: Person, k: K): Person[K] {
return p[k] as Person[K];
}约束如何在泛型链路中传播
理解上面的现象，需要知道TypeScript对T[K]的处理分两种模式：一种是T和K都是具体类型时立即求值；另一种是任一操作数是泛型时进入延迟求值（deferred），只记录结构，等泛型被实例化后再计算。
延迟求值期间，编译器会维护一条约束链。假设有这样一层嵌套：
function pick<T, K extends keyof T>(obj: T, key: K): T[K] {
return obj[key];
}
function nested<T, K extends keyof T>(obj: T, key: K) {
return pick(obj, key); // 返回类型 T[K]
}外层的K extends keyof T这个约束会沿着调用传播到内层pick函数的K参数上，因此内层的返回类型能正确解出为T[K]而不是unknown。这就是约束传播的正向效果：只要约束信息完整，索引访问类型可以在多层泛型之间稳定传递。
反过来，约束信息一旦丢失，传播就会断裂。一个典型例子是联合类型参与时的行为差异：
type A = { a: string };
type B = { b: number };
type AB = A & B;
type ABa = AB["a"]; // string，交叉类型可以直接索引
type Union = A | B;
type UnionKeys = keyof Union; // 交集，此处为 never对联合类型做keyof得到的是各成员key的交集而非并集，这和直觉相反，很多约束传播的报错正是从这里开始的。如果需要并集，要借助分布式辅助类型，例如KeysOfUnion<T> = T extends T ? keyof T : never。
映射类型与索引访问组合时的兼容性陷阱
映射类型经常和索引访问搭配，比如把一个对象的所有属性变成可选。这里有一个非常经典的兼容性问题：
type Partialized<T> = {
[K in keyof T]?: T[K];
};
interface Config {
host: string;
port: number;
}
function merge<T>(base: T, patch: Partialized<T>): T {
return { ...base, ...patch }; // 报错
}报错原因在于：Partialized<T>在T未实例化时是延迟求值的，展开运算的结果类型无法证明等于T。编译器不知道patch里哪些属性存在、哪些是undefined，所以保守地拒绝。这个例子说明，索引访问类型的约束传播在映射类型内部是逐key进行的，但向外整体赋值时，联合中混入的undefined会破坏可赋值性。常见的修复思路是引入可赋值性检查辅助类型，或对patch做非空过滤后再合并。
另一个陷阱出现在as子句上。当你写obj[key] as T[K]时，断言能通过的前提是两个类型存在重叠。如果约束传播链中某一环把K收窄成了never（比如前面提到的联合类型keyof问题），断言本身也会失败，提示两个类型完全无关联。
条件类型分发对约束的影响
条件类型在泛型位置会做分配律分发，这会改写索引访问类型的求值路径：
type ValueOf<T> = T extends Record<infer K, any> ? T[K] : never;
type R1 = ValueOf<{ a: 1; b: 2 }>; // 1 | 2这里T虽然是具体的对象类型，但条件类型内部的infer K捕获了key的联合，T[K]随后按联合求值。如果传入的是泛型，比如：
function values<T extends Record<string, any>>(obj: T): ValueOf<T>[] {
return Object.values(obj); // 类型不匹配，需要断言
}由于ValueOf<T>延迟求值，而Object.values返回的是更宽泛的类型，两者的兼容性检查无法自动通过。理解这一点的意义在于：任何让索引访问类型保持延迟状态的写法，都会让后续的兼容性检查退化为保守模式。要么通过重载或断言给编译器明确的信号，要么用内置工具类型让求值尽早落地。
实践建议与排查思路
总结几条可操作的经验。第一，遇到X不能赋值给T[K]这类报错时，先检查K的约束是否完整，K必须extends keyof T，否则约束链断裂，类型会退化。第二，尽量让索引访问在具体类型上求值，比如在函数签名内部先把泛型收窄成字面量联合再取值。第三，映射类型加索引访问的组合要警惕undefined混入联合，必要时用-?修饰符剔除可选性：
type NonNullableProps<T> = {
[K in keyof T]-?: T[K];
};第四，条件类型中使用[T] extends [X]的元组包裹可以阻止分发，当你希望保持约束链整体求值而不是逐成员分发时，这个小技巧经常能解决看似无解的兼容性报错。掌握这些规则后，再去读TypeScript标准库中Pick、Omit等工具类型的实现，会有完全不同的理解深度。
TypeScript索引访问类型类型兼容性修改时间：2026-09-16 05:21:49