2026-06-24 Aktualisiert 2026-11-02 errors flutter dart Edit on GitHub

Fix: LateInitializationError: Field '...' has not been initialized in Flutter

Nicht initialisierte late-Felder in Flutter beheben: synchrone Initialisierung oder expliziter Lade-, Fehler- und Datenzustand mit geprüftem Lebenszyklus-Code.

Veröffentlicht von Start Debugging 3 Min. Lesezeit 2026-06-24

Diese Website nutzt Walter, einen KI-Agenten, für Recherche, Texte und Pflege. Redaktion und Überprüfung

Wird ein noch nicht zugewiesenes late-Feld gelesen, entsteht ein LateInitializationError. Suche im ersten Stackframe deines eigenen Codes den Lesezugriff und prüfe, welcher Pfad das Feld vorher hätte setzen sollen. late wartet nicht auf asynchrone Vorgänge. Die Beispiele wurden mit Flutter 3.44.8 und Dart 3.12.2 geprüft.

Den Fehler reproduzieren

Dieses Programm lässt sich kompilieren, scheitert aber beim Lesen von name:

class Profile {
  late String name;
}

void main() {
  print(Profile().name);
}

Die Dart-VM meldet LateInitializationError: Field 'name' has not been initialized. Das ist eine Diagnose, kein Verweis auf eine öffentliche dart:core-Klasse, die importiert oder gezielt abgefangen werden müsste. Behebe die fehlende Initialisierung.

Laden, Fehler und Daten darstellen

Ein in initState() gestarteter Netzwerkaufruf kann beim ersten build() noch laufen. Dieses vollständige Widget verwendet nullable Zustand und behandelt Erfolg und Fehler. Übergib die asynchrone Funktion als loadName:

import 'package:flutter/material.dart';

class ProfileScreen extends StatefulWidget {
  const ProfileScreen({super.key, required this.loadName});
  final Future<String> Function() loadName;

  @override
  State<ProfileScreen> createState() => _ProfileScreenState();
}

class _ProfileScreenState extends State<ProfileScreen> {
  String? _name;
  Object? _error;

  @override
  void initState() {
    super.initState();
    _load();
  }

  Future<void> _load() async {
    try {
      final name = await widget.loadName();
      if (!mounted) return;
      setState(() => _name = name);
    } catch (error) {
      if (!mounted) return;
      setState(() => _error = error);
    }
  }

  @override
  Widget build(BuildContext context) {
    if (_error != null) return Text('Failed: $_error');
    final name = _name;
    if (name == null) return const CircularProgressIndicator();
    return Text(name);
  }
}

Das Beispiel lädt einmal pro State-Instanz. Hängt die Anfrage von veränderlichen Widget-Eingaben ab, behandle Änderungen auch in didUpdateWidget oder verwende ein Widget beziehungsweise einen Provider mit passendem Schlüssel. mounted verhindert Änderungen an bereits freigegebenem Zustand, bricht aber keine Anfrage ab. Ein FutureBuilder mit gespeichertem Future oder ein AsyncValue ist ebenfalls geeignet. Ein Feld für den Future darf late final sein, wenn es vor dem Lesen gesetzt wird; das Ergebnis kann später eintreffen.

Nach Abhängigkeit initialisieren

Synchroner Wert: vor dem ersten Lesen zuweisen, bei Zugriff auf widget meist in initState(). Einen TextEditingController außerdem in dispose() freigeben.
Verzögerter Wert: late final value = compute(); führt den Initialisierer beim ersten Zugriff aus. Ein late-Instanzinitialisierer darf Instanzmitglieder verwenden, auch widget in einem State; der erste Zugriff muss zum Lebenszyklus passen. Der Initialisierer kann weiterhin Fehler auslösen oder rekursiv sein.
Geerbte Abhängigkeit: Aufrufe wie Theme.of(context), die eine Abhängigkeit registrieren, gehören in build() oder didChangeDependencies(), nicht in initState(). didChangeDependencies() läuft vor dem ersten Build und bei Änderungen der Abhängigkeiten erneut. Das Verbot betrifft die Registrierung, nicht jede Verwendung von context.

Ähnliche Fehler und irreführende Lösungen

Eine zweite Zuweisung an ein late final-Feld erzeugt die Variante „already initialized“. Entferne die doppelte Zuweisung oder verwende nur dann ein veränderliches Feld, wenn dies beabsichtigt ist. late deaktiviert nicht sämtliche Analyzer-Prüfungen: eindeutig nicht zugewiesene late-Lokalvariablen und bestimmte Mehrfachzuweisungen werden erkannt. Wo die statische Analyse nicht ausreicht, bleiben Laufzeitprüfungen nötig. Sie sind keine reinen Debug-Assertions; Meldungen können je nach Backend und Buildmodus variieren.

Vor dem Lesen muss der Wert bereitstehen oder der Wartezustand ausdrücklich dargestellt werden. await macht late nicht grundsätzlich falsch, wenn alle Leser zuerst die Bereitschaft abwarten. Fehlerhaft ist der vorzeitige Zugriff des Widgets.

Korrektur vom 2. November 2026: Aussagen zu Analyzer-Prüfungen, verzögertem Zugriff auf Instanzmitglieder, geerbten Abhängigkeiten und Release-Diagnosen berichtigt; den Verweis auf eine nicht vorhandene öffentliche Fehlerklasse entfernt. Das überarbeitete Widget wurde analysiert und für Erfolg, Fehler und Freigabe getestet.