unknown vs any in TypeScript: Was wählen im Jahr 2025?

Einleitung: Warum dieses Thema Stack Overflow sprengte?

\n

Wenn Sie jemals in TypeScript programmiert haben, sind Sie sicherlich auf das Dilemma gestoßen: unknown oder any? Die Frage, die tausende Aufrufe auf Stack Overflow gesammelt hat, verliert auch im Jahr 2025 nicht an Aktualität. Es scheint, dass beide Typen alles speichern können – worin liegt also der Unterschied?

\n\n

Stellen Sie sich vor, Sie bauen ein Haus. any ist eine Tür, die für alle weit offen steht, einschließlich Einbrecher. unknown ist eine Tür mit Schloss und Türspion: Sie überprüfen zuerst, wer kommt, und lassen ihn dann erst herein. In diesem Artikel werden wir verstehen, warum unknown zum goldenen Sicherheitsstandard in TypeScript geworden ist und any das Übel ist, das manchmal gerechtfertigt ist.

\n\n

Wir werden nicht einfach die Dokumentation nacherzählen. Wir zeigen reale Anwendungsfälle aus der Praxis von 2025, analysieren die Best Practices und geben einen klaren Entscheidungsalgorithmus. Los geht's!

\n\n

Was ist any und warum haben alle Angst davor?

\n\n

any ist der "flexibelste" Typ in TypeScript. Er sagt dem Compiler buchstäblich: "Schalte das Typsystem aus, ich weiß, was ich tue". Das klingt nach einer Superkraft, ist aber in Wirklichkeit eine Zeitbombe.

\n\n

Beispiel: Wie any Typen zerstört

\n

function processUser(user: any) {\n    console.log(user.name.toUpperCase()); // Fehler zur Laufzeit, wenn user null ist\n}\n\nprocessUser(null); // TypeError: Cannot read property 'toUpperCase' of null

\n\n

Der TypeScript-Compiler wird Sie nicht einmal warnen! any deaktiviert alle Prüfungen, und der Fehler tritt erst in der Produktion auf. Im Jahr 2025, wenn Projekte komplexer werden, ist dieser Ansatz ein Weg ins Chaos.

\n\n

Wann ist any dennoch nützlich?

\n

\n
• Migration von JavaScript: Wenn Sie ein altes Projekt umschreiben, ist any eine temporäre Krücke.
\n
• Dynamische Daten: Zum Beispiel Antworten von externen APIs, deren Struktur sich ändert.
\n
• Tests: In Mocks ist es manchmal einfacher, any zu verwenden, als komplexe Typen zu beschreiben.
\n

\n\n

Aber denken Sie daran: any ist wie eine Kreditkarte mit unbegrenztem Limit. Bequem, bis die Rechnung kommt.

\n\n

Unknown: Strenger Wächter am Eingang

\n\n

unknown wurde in TypeScript 3.0 als sichere Alternative zu any eingeführt. Es kann ebenfalls jeden Wert enthalten, verbietet aber die Arbeit damit ohne explizite Prüfung. Es ist ein Typ-Container, der eine Verifizierung erfordert.

\n\n

Beispiel: unknown in Aktion

\n

function processUser(user: unknown) {\n    // Kompilierungsfehler! Eigenschaft 'name' existiert nicht auf Typ 'unknown'\n    // console.log(user.name.toUpperCase()); \n    \n    // Prüfung erforderlich\n    if (user && typeof user === 'object' && 'name' in user) {\n        const typedUser = user as { name: string };\n        console.log(typedUser.name.toUpperCase()); // Alles ok\n    }\n}\n\nprocessUser({ name: "Alice" }); // ALICE\nprocessUser(null); // Nichts stürzt ab

\n\n

Haben Sie den Unterschied bemerkt? unknown lässt Sie nicht ins eigene Bein schießen. Sie müssen den Typ vor der Verwendung überprüfen. Das ist sichere Typisierung.

\n\n

Vergleich any vs unknown in einer Tabelle

\n\n

Um das Material zu festigen, schauen wir uns die wichtigsten Unterschiede an:

\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Kriterium	any	unknown
Zuweisung eines beliebigen Wertes	✅ Ja	✅ Ja
Zugriff auf Eigenschaften ohne Prüfung	✅ Ja	❌ Nein
Zuweisung zu einem anderen Typ	✅ Zu jedem	❌ Nur any oder unknown
Schutz vor Laufzeitfehlern	❌ Nein	✅ Ja (erfordert Prüfung)

\n\n

Wie Sie sehen, gewinnt unknown