Zum Hauptinhalt springen
Pro Plan15 minutesExperte

Stack-Trace-Analyse

JavaScript-Fehler mithilfe von Stack-Traces mit Source-Map-Unterstützung verstehen und debuggen. Lernen Sie Stack-Trace-Analyse in diesem Fehler-Tracking-Leitfaden.

stack-tracedebuggingsource-mapserrorsanalysis
Zuletzt aktualisiert:

Meistern Sie die Stack-Trace-Analyse, um JavaScript-Fehler in Ihrer Anwendung schnell zu identifizieren und zu beheben.

Zenovay Fehler-Dashboard zeigt Fehler, die Sie öffnen können um die Stack-Trace anzuzeigen.
Öffnen Sie einen beliebigen Fehler im Reiter Fehler, um seine gruppierten Vorkommen und Stack-Trace zu sehen.

Stack-Traces verstehen

Aufbau eines Stack-Traces

TypeError: Cannot read property 'email' of undefined
    at getUserEmail (user-service.js:45:12)    ← Fehlerposition
    at validateForm (form-handler.js:123:8)    ← Von hier aufgerufen
    at HTMLFormElement.<anonymous> (form.js:67:5) ← Event-Handler
    at HTMLFormElement.dispatch (jquery.min.js:3:10456)
    at HTMLFormElement.v.handle (jquery.min.js:3:8765)

Komponenten eines Stack-Frames

Jede Zeile enthält:

KomponenteBeispielBeschreibung
FunktiongetUserEmailFunktionsname
Dateiuser-service.jsQuelldatei
Zeile45Zeilennummer
Spalte12Spaltenposition

Leserichtung

Lesen Sie Stack-Traces von oben nach unten:

  1. Oberster Frame: Wo der Fehler aufgetreten ist
  2. Mittlere Frames: Aufrufkette
  3. Untere Frames: Einstiegspunkt

Stack-Traces in Zenovay anzeigen

Error Tracking ist eine Pro-Funktion. Sobald es für eine Website aktiviert ist, werden erfasste Fehler nach Fingerprint gruppiert und auf der Registerkarte Fehler des Website-Dashboards angezeigt (/domains/{your-site}?tab=errors).

Um es zu aktivieren, öffnen Sie die Einstellungen der Website, gehen Sie zum Abschnitt Erweitert und aktivieren Sie Error Tracking unter Feature-Flags.

Die Fehlerdetailansicht

Öffnen Sie eine Fehlergruppe auf der Registerkarte „Fehler", um ihre jüngsten Vorkommnisse anzuzeigen. Für jeden Fehler können Sie überprüfen:

  • Der Fehlertyp und die Meldung
  • Die Seiten-URL, auf der es passiert ist
  • Aufschlüsselungen nach Browser, Betriebssystem und Gerät
  • Die Breadcrumbs (Benutzeraktionen vor dem Fehler), die dazu führten
  • Der Stack-Trace, dargestellt als erweiterbare Liste von Frames

Der Stack-Trace ist standardmäßig zusammengeklappt. Erweitern Sie ihn, um jeden Frame anzuzeigen als:

at getUserById (user-service.js:45:12)
at handleGetUser (api-handler.js:78:5)
at <anonymous> (router.js:23:3)

Lange Traces werden auf die ersten Frames gekürzt, mit einem Indikator „weitere Frames" für den Rest. Der Funktionsname, die Datei, die Zeile und die Spalte werden für jeden Frame angezeigt, um Sie direkt zum relevanten Code in Ihrem Editor zu führen.

Source Maps

Source Maps ermöglichen es Zenovay, minifizierte Production-Stack-Traces in Ihre Original-Quelldatei, Zeile und Spalte umzuwandeln.

Ohne Source Maps

Minifizierter Code erzeugt kryptische Traces:

TypeError: a is not a function
    at e (main.abc123.js:1:34567)
    at t.handleClick (main.abc123.js:1:45678)
    at Object.onClick (main.abc123.js:1:56789)

Mit Source Maps

Derselbe Fehler, lesbar:

TypeError: processPayment is not a function
    at handleCheckout (checkout.tsx:89:12)
    at CheckoutButton.handleClick (CheckoutButton.tsx:45:8)
    at onClick (form-events.ts:23:5)

Source Maps generieren

Der erste Schritt besteht darin, Source Maps während Ihres Builds zu generieren. Verwenden Sie versteckte Source Maps in Production, damit die .map-Dateien erstellt, aber nicht referenziert werden (oder nicht aus Ihrem öffentlichen Bundle bereitgestellt werden).

Webpack – versteckte Source Maps generieren:

// webpack.config.js
module.exports = {
  devtool: 'hidden-source-map',
  // Source Maps werden generiert, aber nicht in der Ausgabe referenziert
};

Vite – versteckte Source Maps generieren:

// vite.config.js
export default {
  build: {
    sourcemap: 'hidden'
  }
};

Rollup – versteckte Source Maps generieren:

// rollup.config.js
export default {
  output: {
    sourcemap: 'hidden'
  }
};

Versehen Sie jeden Build mit einer Release-Version (siehe Release-Korrelation unten), damit Source Maps und Fehler gegen die gleiche Bereitstellung abgestimmt werden.

Häufige Muster analysieren

Zugriff auf undefinierte Eigenschaften

TypeError: Cannot read property 'name' of undefined
    at renderUser (user-card.js:23:15)

Analyse:

  • Das in Zeile 23 erwartete Objekt ist undefined
  • Überprüfen Sie den Datenfluss zu renderUser
  • Wahrscheinlich fehlt eine Null-Prüfung

Lösungsmuster:

// Vorher
const name = user.name;

// Nachher
const name = user?.name ?? 'Unknown';

Funktion nicht definiert

ReferenceError: processPayment is not defined
    at handleSubmit (checkout.js:45:5)

Analyse:

  • Funktion aufgerufen, aber nicht im Gültigkeitsbereich
  • Überprüfen Sie Imports/Exports
  • Verifizieren Sie die Ladereihenfolge der Module

Typfehler

TypeError: users.map is not a function
    at renderUserList (list.js:12:20)

Analyse:

  • users ist kein Array
  • Überprüfen Sie das API-Antwortformat
  • Verifizieren Sie Datentypannahmen

Erweiterte Analyse

Asynchrone Stack-Traces

Modernes JavaScript enthält asynchronen Kontext:

Error: API request failed
    at fetchUser (api.js:34:11)
    at async loadUserData (user-loader.js:56:18)
    at async initApp (app.js:12:5)

Cross-Origin-Frames

Drittanbieter-Skripte zeigen eingeschränkte Informationen:

Error: Script error.
    at <anonymous> (https://third-party.com/widget.js:1:1)

Lösung: Fügen Sie CORS-Header zu Drittanbieter-Skripten hinzu:

<script src="https://third-party.com/widget.js" crossorigin="anonymous"></script>

Minifizierter Drittanbieter-Code

Für Bibliotheken ohne Source Maps:

  • Identifizieren Sie die Bibliothek anhand des URL-Musters
  • Prüfen Sie die Bibliotheksversion
  • Suchen Sie nach bekannten Problemen
  • Ziehen Sie Alternativen in Betracht

Debugging-Workflow

Schritt 1: Fehlerposition identifizieren

  1. Schauen Sie sich den obersten Stack-Frame an
  2. Notieren Sie Datei, Zeile und Spalte
  3. Verstehen Sie, was der Code tut

Schritt 2: Aufrufpfad nachverfolgen

  1. Folgen Sie den Frames im Stack nach unten
  2. Identifizieren Sie den Datenfluss
  3. Finden Sie, woher fehlerhafte Daten stammen

Schritt 3: Kontext prüfen

  1. Sehen Sie sich die Häufigkeit der Fehlerauftritte im Zeitverlauf auf der Registerkarte „Fehler" an
  2. Prüfen Sie betroffene Browser/Geräte in der Aufschlüsselung
  3. Lesen Sie die Breadcrumbs, die zum Fehler führten

Schritt 4: Reproduzieren

  1. Verwenden Sie Session Replay (falls auf Ihrem Plan verfügbar)
  2. Prüfen Sie Benutzeraktionen vor dem Fehler
  3. Testen Sie mit demselben Browser/denselben Bedingungen

Schritt 5: Beheben und verifizieren

  1. Implementieren Sie die Lösung
  2. Deployen Sie die neue Version
  3. Markieren Sie die Fehlergruppe in der Fehlerdetailansicht als behoben
  4. Überwachen Sie auf Regressionen

Fehler-Status verwalten

In der Fehlerdetailansicht können Sie den Status einer Gruppe ändern, um Ihre Liste konzentriert zu halten:

  • Ungelöst – benötigt Aufmerksamkeit (Standard)
  • In Bearbeitung – jemand arbeitet daran
  • Behoben – behoben und verifiziert
  • Ignoriert – bekannt und absichtlich nicht bearbeitet

Status-Änderungen erfordern Redakteur-Zugriff auf den Arbeitsbereich und werden im Audit-Log des Arbeitsbereichs aufgezeichnet.

Release-Korrelation

Wenn Sie Ihr Tracking mit einer Release kennzeichnen, zeichnet jeder erfasste Fehler die Release auf, aus der er stammt, damit Sie erkennen können, welche Bereitstellung ein Problem eingeführt hat.

Releases kennzeichnen

Legen Sie einen Release-Wert in Ihrem Build fest, damit der Tracker mit jedem Event darüber berichtet. Der Basis-Snippet sieht wie folgt aus:

<script
  defer
  data-tracking-code="YOUR_TRACKING_CODE"
  src="https://api.zenovay.com/z.js"
></script>

Kombinieren Sie dies mit den zugehörigen Source Maps aus Ihrem Build (gekennzeichnet mit der gleichen Release), damit Production-Traces gegen die richtige Version symbolisiert werden.

Best Practices

Source-Map-Verwaltung

  • Verwenden Sie versteckte Source Maps in Production
  • Halten Sie Source Maps nach Release organisiert
  • Kennzeichnen Sie jeden Build mit der Release-Version, die Ihrer Bereitstellung entspricht

Stack-Trace-Qualität

  • Verwenden Sie aussagekräftige Funktionsnamen
  • Vermeiden Sie anonyme Funktionen
  • Halten Sie Aufrufstapel angemessen tief
  • Fügen Sie bei Bedarf Fehlerkontext hinzu

Debugging-Effizienz

  • Beginnen Sie mit den am meisten betroffenen Fehlern
  • Verwenden Sie Status (in Bearbeitung, behoben, ignoriert), um die Liste zu konzentrieren
  • Dokumentieren Sie Erkenntnisse
  • Teilen Sie diese mit Ihrem Team

Fehlerbehebung

Fehlende Source Maps

Prüfen Sie:

  • Source Maps wurden für diese Release generiert
  • Die Release-Version stimmt mit dem überein, was der Tracker berichtet
  • Dateinamen stimmen mit Ihren bereitgestellten Bundles überein

Unvollständige Stack-Traces

Ursachen:

  • Asynchroner Code nicht korrekt nachverfolgt
  • Fehler aus eval() oder dynamischem Code
  • Browser-Einschränkungen

„Script error"-Meldungen

Lösungen:

  • CORS-Header hinzufügen
  • Das crossorigin-Attribut verwenden
  • Drittanbieter-Skripte selbst hosten

Nächste Schritte

War dieser Artikel hilfreich?