In TypeScript, what object type does the built-in `Record<K, V>` utility produce, and how does its mapped-type definition explain the difference between `Record<string, number>` and `Record<'a' | 'b', number>`?

## Record is a type alias, not compiler magic `Record` is written in TypeScript's own standard library (`lib.es5.d.ts`) as a single mapped type: ```ts type Record<K extends keyof any, T> = { [P in K]: T; }; ``` Everything about its behaviour falls out of that one line. `keyof any` is the set of legal property key types — `string | number | symbol` — so the constraint on `K` just says "whatever you pass must be usable as a key". `T` is unconstrained: values can be primitives, objects, functions, unions, anything. The body `{ [P in K]: T }` is a **mapped type**. Read it as a loop: for each member `P` of the key type `K`, declare a property named `P` whose type is `T`. That is why people describe `Record` as "keys of type K, values of type V" — the loop assigns the same value type to every generated key. ## The two modes, and why they differ The interesting behaviour is that the *same* utility produces two very different-feeling types depending on how open `K` is. **Open key type.** `Record<string, number>` loops over `string`, which is not a finite set of names, so the compiler produces an index signature instead of named properties: ```ts type Scores = Record<string, number>; // { [x: string]: number } const s: Scores = {}; // fine — no key is required s.anything = 1; // fine — any string key is allowed const n: number = s.whatever; // compiles, even though the key is absent ``` Nothing is required and nothing is forbidden. `Record<number, T>` behaves the same way with a numeric index signature, and `Record<symbol, T>` with a symbol one. **Closed key type.** A union of string literals *is* a finite set, so the loop produces one named property per member: ```ts type Flags = Record<'read' | 'write', boolean>; // { read: boolean; write: boolean } const ok: Flags = { read: true, write: false }; const missing: Flags = { read: true }; // Error: Property 'write' is missing const extra: Flags = { read: true, write: false, exec: true }; // Error: Object literal may only specify known properties ('exec' does not exist) ``` Each generated property is **required** — the mapped type adds no `?` modifier. If you want the partial version, wrap it: `Partial<Record<'read' | 'write', boolean>>` makes every entry optional. The same applies to enums, which are also finite key sets: `Record<Color, string>` demands an entry for every member of `Color`. ## Reading a value out For a literal-keyed `Record`, property access is ordinary property access: `flags.read` is `boolean`, and misspelling the key is a compile error because no such property exists. For a string-keyed `Record`, `scores[k]` is typed `number` under default settings even when the key is absent at runtime — the index signature is a promise the checker takes at face value. That gap is the single most important thing to know about `Record<string, T>`, and it is what pushes people to model absent entries explicitly with a `| undefined` value type. ## Two small typing details that surprise people `keyof Record<string, T>` is `string | number`, not just `string` — a numeric key is usable against a string index signature, so both are reported. And `Object.keys(rec)` is typed `string[]` by the standard library regardless of how narrow the `Record` key type is, so iterating a `Record<'a' | 'b', number>` does not hand you `('a' | 'b')[]` for free; you have to assert or write a helper if you want the narrow key type. ## It is erased `Record` is part of the type layer only. Compiling ```ts type Flags = Record<'read' | 'write', boolean>; const f: Flags = { read: true, write: false }; ``` emits just the object literal. There is no runtime construct that validates the keys, no check that the values are booleans, and nothing to import. If the data comes from JSON or a network response, the `Record` annotation asserts a shape that only a runtime validation step can actually guarantee. ## When to reach for it Use `Record` when the value type is uniform and the keys are the interesting part: a lookup table from a status to a label, a map from a feature key to a handler, a bag of headers. When different keys need different value types, `Record` is the wrong tool — that is an interface or a discriminated shape, because forcing one value type across heterogeneous fields means widening it to a union and losing the precision at every read site.