Wann könnte man BigInt in JavaScript benötigen?

JavaScript verarbeitet die meisten Zahlen problemlos – bis es das nicht mehr tut. Wenn Sie jemals eine große ID von einer API abgerufen haben und festgestellt haben, dass sie leicht verändert zurückkam, oder wenn Sie versucht haben, präzise Arithmetik mit einer sehr großen Ganzzahl durchzuführen und ein subtil falsches Ergebnis erhalten haben, sind Sie bereits auf das Problem gestoßen, das BigInt löst.

Die Grenze, die JavaScript-Zahlen nicht überschreiten können

Alle JavaScript-Zahlen verwenden das IEEE 754 Double-Precision-Gleitkommaformat. Das gibt Ihnen einen sicheren Ganzzahlbereich von −(2⁵³ − 1) bis 2⁵³ − 1, dargestellt durch Number.MIN_SAFE_INTEGER und Number.MAX_SAFE_INTEGER.

Jenseits dieser Grenze verlieren Ganzzahlen stillschweigend an Präzision:

console.log(9007199254740991 + 1)  // 9007199254740992 ✅
console.log(9007199254740991 + 2)  // 9007199254740992 ❌ (falsch)

// Das ist das Präzisionsproblem in Aktion:
9007199254740992 === 9007199254740993 // true — sie sind für JavaScript identisch

Es wird kein Fehler ausgelöst. Der Wert ist einfach falsch. Das ist das Präzisionslimitproblem, für dessen Lösung BigInt entwickelt wurde.

Was BigInt tatsächlich ist

BigInt ist ein in JavaScript eingebauter primitiver Typ, der in ES2020 eingeführt wurde und Ganzzahlen beliebiger Größe darstellen kann, nur begrenzt durch den verfügbaren Speicher. Sie erstellen einen BigInt, indem Sie n an ein Ganzzahl-Literal anhängen oder den BigInt()-Konstruktor verwenden:

const big = 9007199254740993n                 // Literal-Syntax
const alsoBig = BigInt("9007199254740993")    // Konstruktor mit String

9007199254740992n === 9007199254740993n        // false ✅ — korrekt

Eine wichtige Einschränkung: BigInt ist nur für Ganzzahlen. Es kann keine Dezimal- oder Bruchwerte darstellen. 1.5n löst einen SyntaxError aus.

Wann man BigInt in JavaScript verwenden sollte

Die meisten Frontend-Codes benötigen niemals BigInt. Aber einige reale Szenarien erfordern es tatsächlich.

Große IDs aus externen Systemen. Twitters Snowflake-ID-System und ähnliche verteilte ID-Schemata erzeugen 64-Bit-Ganzzahlen, die Number.MAX_SAFE_INTEGER überschreiten. Wenn eine REST-API eine solche als JSON-Zahl zurückgibt, wird JavaScript sie stillschweigend verfälschen. Das Parsen als String und die Konvertierung zu BigInt bewahrt den Wert exakt.

// Eine 64-Bit-ID, die als String von einer API empfangen wurde
const userId = BigInt("922337203685477580")

64-Bit-Ganzzahlen aus WebAssembly. WebAssemblys i64-Typ wird direkt auf BigInt in JavaScript abgebildet. Wenn Ihr Wasm-Modul 64-Bit-Ganzzahlen zurückgibt oder akzeptiert, benötigen Sie BigInt, um sie korrekt zu verarbeiten.

Exakte Ganzzahlarithmetik, bei der die Präzision niemals abrutschen darf. Bestimmte Blockchain-Transaktionswerte, große Zähler oder hochpräzise Zeitstempelarithmetik (z. B. Nanosekunden seit Epoch) können den sicheren Ganzzahlbereich überschreiten. BigInt hält jede Ziffer exakt.

Wichtige Einschränkungen, die Sie kennen sollten

Bevor Sie zu BigInt greifen, sollten Sie seine Einschränkungen verstehen:

Sie können BigInt und Number nicht in arithmetischen Operationen mischen. Dies löst einen TypeError aus. Eine explizite Konvertierung ist erforderlich:

const big = 10n
const num = 5

big + num            // ❌ TypeError
big + BigInt(num)    // ✅ 15n
Number(big) + num    // ✅ 15 (verliert aber BigInt-Präzision bei großen Werten)

Die Math-API funktioniert nicht mit BigInt. Math.max(), Math.sqrt() und jede andere Math-Methode lösen einen Fehler aus, wenn ihnen ein BigInt übergeben wird. Wenn Sie diese Operationen benötigen, müssen Sie konvertieren – und den Präzisionskompromiss akzeptieren.

JSON-Serialisierung schlägt standardmäßig fehl. JSON.stringify() löst einen TypeError bei BigInt-Werten aus. Sie benötigen einen benutzerdefinierten Replacer oder eine toJSON()-Methode zur Behandlung der Serialisierung:

BigInt.prototype.toJSON = function () {
  return this.toString()
}

JSON.stringify({ id: 922337203685477580n }) // '{"id":"922337203685477580"}'

Beachten Sie, dass dies den Wert in einen String in der JSON-Ausgabe konvertiert, den das empfangende System entsprechend verarbeiten muss. Außerdem wird das Modifizieren eines eingebauten Prototyps wie BigInt.prototype im Produktionscode generell nicht empfohlen. Eine benutzerdefinierte replacer-Funktion, die an JSON.stringify() übergeben wird, ist eine sicherere Alternative:

const data = { id: 922337203685477580n }

JSON.stringify(data, (key, value) =>
  typeof value === "bigint" ? value.toString() : value
) // '{"id":"922337203685477580"}'

Fazit

BigInt vs. Number in JavaScript ist eigentlich kein Wettbewerb – sie dienen unterschiedlichen Zwecken. Verwenden Sie Number für alles, was es gut verarbeitet, und das ist das meiste. Greifen Sie speziell zu BigInt, wenn Sie mit Ganzzahlen arbeiten, die 2⁵³ − 1 überschreiten können und bei denen Korrektheit nicht verhandelbar ist. Das ist eine enge, aber wichtige Kategorie, und BigInt behandelt sie genau richtig.

Häufig gestellte Fragen (FAQs)

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.