本文解析为何在嵌套映射类型中对联合字面量类型（如 `’a’ | ‘b’` 或 `1 | 2`）误用 `keyof t[k]` 会意外引入 `String`/`number` 原型方法（如 `charat`、`tofixed`），并给出语义清晰、类型安全的替代写法。
在 typescript 类型编程中，keyof 是一个强大而易被误解的操作符。它本意是提取对象类型所有可索引的键名（即字符串或数字字面量组成的联合类型），例如：
type Point = { x: number; y: number }; type Keys = keyof Point; // "x" | "y"然而，当 keyof 被错误地用于非对象类型（如字面量联合类型 ItemType、Owner 或 Value）时，问题便悄然浮现。
回顾原始代码中的关键片段：
type ItemType = 'itemTypeA' | 'itemTypeB'; type Owner = 'ownerA' | 'ownerB'; type Value = 1 | 2; type Item = { type: ItemType; owner: Owner; value: Value; }; type AnotherType = { [K in keyof Item]: null | { [M in keyof Item[K]]: number; // ⚠️ 问题根源在此 }; };表面看，Item[K] 会依次取到 ItemType、Owner、Value —— 这些都是字面量联合类型（literal union types），而非对象类型。但 keyof ItemType 并不会返回 ‘itemTypeA’ | ‘itemTypeB’，而是触发 TypeScript 的“隐式提升”行为：它将字面量类型（如 ‘itemTypeA’）视为其基础类型（string）的实例，并进而计算 keyof string，即 string 原型上所有可枚举属性名（如 “charAt”、”charCodeAt”、”Length”、”toString” 等）。同理，keyof 1 等价于 keyof number，会引入 “toFixed”、”toPrecision” 等方法名。
这正是编译器报错的原因：
Type ‘{ itemTypeA: number; itemTypeB: number; }’ is not assignable to type ‘{ [x: number]: number; toString: number; charAt: number; … }’
因为目标类型被错误扩展为包含大量无关方法键，导致赋值不兼容。
✅ 正确解法非常简洁：直接遍历字面量联合类型本身，而非对其取 keyof：
type AnotherType = { [K in keyof Item]: null | { [M in Item[K]]: number; // ✅ 正确：M 直接取 ItemType、Owner、Value 的成员 }; };此时：
- M in ItemType → ‘itemTypeA’ | ‘itemTypeB’
- M in Owner → ‘ownerA’ | ‘ownerB’
- M in Value → 1 | 2
最终 AnotherType 精确等价于：
type AnotherType = { type: { itemTypeA: number; itemTypeB: number } | null; owner: { ownerA: number; ownerB: number } | null; value: { 1: number; 2: number } | null; };完全符合预期，且类型安全、零冗余。
? 关键原则总结：
- keyof T 仅适用于对象类型（Object types），用于提取其显式定义的键；
- 对字面量联合类型（如 ‘a’ | ‘b’、1 | 2）或基础类型（string、number）使用 keyof 是逻辑错误，它不会返回你期望的字面量，而是返回该类型的原型键集合；
- 映射类型中若 T[K] 已是键集合（如枚举式联合），应直接 in T[K]，而非 in keyof T[K]；
- 可借助 TypeScript Playground 的“Jump to definition”或 hover 提示验证 Item[K] 和 keyof Item[K] 的实际展开结果，避免隐式类型提升陷阱。
通过这一修正，你不仅能消除编译错误，更能写出更语义明确、可维护性更强的类型定义。