本文解析为何在 `in keyof item[k]` 这类嵌套映射类型中，`keyof` 会意外引入 `string`/`number` 原始类型的原型方法（如 `charat`、`tofixed`），并给出语义清晰、类型安全的替代写法。
在 TypeScript 的高级类型编程中，keyof 是一个强大而易被误解的工具。它本意是提取对象类型（object type）的可索引键名联合，例如：
type Point = { x: number; y: number };
type Keys = keyof Point; // "x" | "y"但当 keyof 被错误地应用于非对象类型（如字面量联合类型 ItemType、Owner 或 Value）时，TypeScript 会将其“升格”为对应原始类型的完整键集合——即 keyof string 或 keyof number，而这正是问题根源。
以原问题为例：
type ItemType = 'itemTypeA' | 'itemTypeB';
type Owner = 'ownerA' | 'ownerB';
type Value = 1 | 2;
type Item = {
type: ItemType;
owner: Owner;
value: Value;
};
// ❌ 错误：keyof Item[K] 对于 K="type" 即 keyof ItemType
// 由于 ItemType 是字符串字面量联合，TypeScript 将其视为 string 的子类型，
// 因此 keyof ItemType 等价于 keyof string → 所有 string 原型方法键：
// "toString" | "charAt" | "charCodeAt" | "indexOf" | ...（共数十个）
type AnotherType = {
[K in keyof Item]: null | {
[M in keyof Item[K]]: number; // ← 问题在此！
};
};此时 Item["type"] 是 'itemTypeA' | 'itemTypeB'，属于 string 子类型；keyof Item["type"] 并非你期望的 "itemTypeA" | "itemTypeB"，而是 string 的所有可枚举属性键（包括继承自 String.prototype 的方法）。同理，keyof Value（即 keyof (1 | 2)）等价于 keyof number，会引入 toFixed、toPrecision 等方法名，导致类型宽泛且无法赋值。
✅ 正确做法是：直接遍历 Item[K] 本身，因为该类型已是所需的键字面量联合（ItemType、Owner、Value），无需再取其 keyof：
使用 Scrapfly SDK（scrapfly-sdk）在 TypeScript 或 JavaScript 中进行网页抓取，用于用户请求抓取 URL、绕过反爬虫防护、渲染页面等场景。
type AnotherType = {
[K in keyof Item]: null | {
[M in Item[K]]: number; // ✅ 直接用 Item[K] —— 它本身就是键集合
};
};这样，TypeScript 将精确推导为：
- K = "type" → M in ItemType → "itemTypeA" | "itemTypeB"
- K = "owner" → M in Owner → "ownerA" | "ownerB"
- K = "value" → 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;
};✅ 赋值成功：
const v: AnotherType = {
type: { itemTypeA: 0, itemTypeB: 1 },
owner: { ownerA: 0, ownerB: 1 },
value: null,
};⚠️ 关键注意事项：
- keyof T 仅对对象类型有意义；对原始类型（string、number、boolean）或其字面量联合使用 keyof，会退化为该原始类型的完整原型键集合。
- 映射类型中 in T 的 T 应为键类型集合（如字面量联合），而非“键的键”；若 T 已是 ItemType，则 in ItemType 正确，in keyof ItemType 错误。
- 可借助 --noImplicitAny 和类型检查器提示（如 VS Code 悬停查看 keyof Item["type"] 展开结果）提前发现此类误用。
总结：keyof 不是万能的“取所有可能属性名”的黑盒操作；它的行为严格依赖于操作数的类型分类。在设计嵌套映射类型时，始终问自己：“这里需要的是 键本身，还是 键的键？”——绝大多数场景下，你需要的是前者。
