> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2026/w03-lessons-from-advanced-troubleshooting.md).

# W03-Erfahrungen mit anspruchsvoller Fehlerdiagnose

Bei einem Webpack-Geisterproblem, das uns fast drei Jahre beschäftigte, gab es vergangene Woche einen großen Fortschritt. Das ist eine Gelegenheit, Besonderheiten schwieriger Frontend-Probleme und meine Erfahrungen damit zusammenzufassen.

***

#### Schwierige, ungewöhnliche Probleme lassen sich danach unterscheiden, ob der Code fehlerhaft ist

* Die erste Gruppe enthält verborgene Entwurfsfehler im Code. Logische Schwächen werden nur unter besonderen Bedingungen sichtbar, etwa bei falschen Annahmen über Asynchronität, Nebenläufigkeit oder Zustand, auf schwachen Geräten oder bei bestimmter Ausführungsreihenfolge. Am häufigsten begegnen mir zeitliche Race Conditions. Dazu später ein Beispiel.
* Bei der zweiten Gruppe liegt die Ursache oft nicht im Code selbst. Die Wahrheit muss in einem System voller Unsicherheit gesucht werden. Genau darin liegt das Anspruchsvolle an Frontend-Diagnosen: nicht nur korrekten Code schreiben, sondern die Welt verstehen, in der er läuft. Man kann diese Welt eine unsichere Laufzeitumgebung nennen. Ihre Unsicherheit macht Beobachtung und Reproduktion oft schwierig.

***

#### Die unsichere Laufzeitumgebung

Das ist eine technische Annahme: Außer dem Code ist nichts verlässlich. Sie soll uns zu defensivem Vorgehen bringen.

Schon mit dem Build beginnt diese Umgebung.

> Build, menschliche Auswahl → Container, stark angepasst → Betriebssystem und Hardware, stark fragmentiert → Nutzer und physischer Kontext, unkontrollierbar.

**1. Build: Unterschiede in Infrastruktur und erzeugten Artefakten**

Abweichende Polyfills, Laufzeitbibliotheken und Buildkonfigurationen können dazu führen, dass neue Syntax in alten Umgebungen sofort scheitert oder doppelte beziehungsweise falsche Injektionen Fehler erzeugen.

> Beim Monatszahlungsprodukt gab es nach dem Wechsel von Webpack zu Rspack auf schwachen Geräten ungewöhnliche Ausführungsreihenfolgen von Promise und thenable. Das Buildwerkzeug selbst muss keinen Bug haben. Unterschiede im Runtime-Verhalten der erzeugten Artefakte können das Problem auslösen. Webpack besitzt eine komplexe Runtime, die das Laden von Modulen mit Promise und thenable koordiniert.
>
> Im Händler-Checkout unter Kua Lyu schlug einmal set cookie fehl. Ursache war die Ausführungsreihenfolge zwischen verschiedenen Clientthreads.

**2. Container: Unterschiede zwischen Host-App und WebView-Engine**

WebViews unterscheiden sich bei JavaScript, CSS, Sicherheit und Schnittstellen. Die Hülle kann APIs injizieren oder einschränken. Dieselbe H5-Anwendung verhält sich deshalb in verschiedenen Containern unterschiedlich.

> Typisch sind iOS-Interceptor. Container fangen Netzwerkanfragen und Navigation ab. Fehlerhafte oder doppelte Interceptor können Probleme erzeugen. In Huixiao führte fehlgeschlagenes set cookie etwa zu ungültigen Tokens. In der Händler-App des Lieferdienstes hatten wir Probleme mit Offline-Paketen.
>
> Dort wurde außerdem ein Hook injiziert, der bei fehlendem knb.js selbst Version 1.9.1 nachlud. Unter Android konnte dadurch das Abonnieren von appear gelegentlich gelingen, ohne dass der Callback ausgeführt wurde.

**3. Betriebssystem und Hardware: fragmentierte Systeme und Geräte**

Hersteller-ROMs, Gerätetypen, Auflösungen und Systemversionen können spezifische Abstürze, Layoutfehler oder Performanceprobleme verursachen.

> In der iOS-Händler-App rief ein einzelner Nutzer yoda ungewöhnlich oft auf. Erst im folgenden Jahr, als wir ein anderes Problem lösten, konnten wir beide Fälle zusammenführen. Ursache war zu wenig verfügbarer Speicher auf schwachen Geräten. Nach einer Speicherwarnung rief die WebView wegen des Mechanismus zum Aufrechterhalten des Betriebs wiederholt reload auf. Dadurch erschien derselbe Nutzer in kurzer Zeit immer wieder auf der Seite.

**4. Nutzer und physischer Kontext: reale Nutzungsbedingungen**

Unterschiedliche Nutzungsweisen, schwache Netze, niedriger Akkustand und knapper Speicher erzeugen unkontrollierbare Variablen und Randfälle. Weil sie sich kaum wiederholen lassen, sind sie schwer zu untersuchen. Oft ergeben erst Messlogs zusammen mit aufgezeichneten Nutzeraktionen brauchbare Hinweise.

> Bei externen Zahlungen verursachte ein doppelt gestartetes WeChat Zahlungsfehler. Manche Nutzer betreiben mit System- oder Drittanbieterfunktionen zwei Instanzen derselben App auf einem Telefon. Das kann die Annahme einer einzigen App-Instanz oder die IPC-Kette verletzen und unerwartete Probleme auslösen.

***

#### Nach vielen eigenen Fehlern: zwei Erfahrungen und zwei Fälle

Erstens die eigene Fixierung lösen. Nicht jedes schwierige Problem braucht sofort eine perfekte Erklärung. Wenn bereits ein Vorfall entstanden ist, hat die Entlastung des Umfelds Vorrang. Ein kontrollierbarer Workaround sollte zuerst das Risiko schließen, damit die Aufmerksamkeit weiterziehen kann. Die meisten Menschen interessieren sich nicht für die letzte Ursache. Erst wenn die Lage stabil ist, kann man in Ruhe nach der Wahrheit suchen.

Zweitens beharrlich bleiben und Herausforderungen annehmen. So entsteht technische Tiefe. Viele Probleme lösen sich nach langem Warten plötzlich. Ist eine Sackgasse erreicht, kann man das Problem ruhen lassen, auf Gelegenheit oder einen Einfall warten und fehlendes Wissen ergänzen. Nur aufgeben sollte man nicht.

***

#### Fall eins: unzuverlässige Webpack-Buildartefakte

Das eingangs erwähnte Problem war ein fast dreijähriger Weg von oberflächlichen Beobachtungen zu einem immer tieferen Verständnis.

1. Erscheinungsbild: Webpack erzeugte gelegentlich unbrauchbare Artefakte, die in Produktion sporadisch weiße Seiten verursachten. Anfangs fanden wir keine Ursache. Wir verbesserten aber die Paketverteilung der Pipeline, sodass die Prüfung mit freigegebenen Nutzern und der vollständige Rollout dasselbe Paket verwendeten.
2. Konfigurationsanalyse: Später untersuchte Hongze gezielt die Webpack-Konfiguration. Er fand Buildfehler durch gemischte ESM- und CJS-Abhängigkeiten und passte die Konfiguration an. Fehlerhafte Artefakte entstanden dennoch weiterhin.
3. Gemeinsames Experiment und Kompromiss: Vergangenes Jahr hielt Jianzuan in unserer Grundlagenreihe einen Vortrag dazu. Gemeinsam reproduzierten wir die instabilen Builds. Das vertiefte das Verständnis des Teams. Zugleich fanden wir einen wirksameren Konfigurationsschalter: Ohne asynchrones Bündeln verschwanden die fehlerhaften Artefakte. Der Preis war längere Buildzeit.
4. Abschließende Lösung: Vergangene Woche stellte Jianzuan einen neuen Ansatz vor. Er identifizierte den Wrapper n.n() als entscheidendes Merkmal. Eine Prüfung, ob die CJS-Minifizierung im Artefakt dem erwarteten Muster entspricht, sichert die Richtigkeit der Produktionspakete. Damit lässt sich das Qualitätsrisiko vollständig schließen.

Für mich kann dieser Fall damit abgeschlossen werden. Wenn noch Zeit bleibt, könnten wir Webpack helfen, das asynchrone Bauen von CJS-Modulen grundsätzlich zu reparieren und einen PR einreichen.

***

#### Fall zwei: Überarbeitung des Marketings im Alpha-Projekt

Probleme können gelöst werden, ohne eine vollständige technische Erklärung zu erhalten. Wichtiger ist der Umgang mit ihnen.

Eine Marketingüberarbeitung im Alpha-Projekt senkte einmal die Kontoeröffnungsquote. Die Behebung dauerte über zwei Monate und legte viele Schwächen offen. Die technische Ursache fanden wir nie. Heute fehlen die Bedingungen für eine erneute Reproduktion. Eine vollständige Erklärung wird es nicht mehr geben.

Doch in diesem Prozess verstanden wir Qualität tiefer. Wir ergänzten Echtzeitbeobachtung von Geschäftskennzahlen, A/B-Experimente, einen regelmäßigen Qualitätsbetrieb vor Produktion und eine gründliche Auseinandersetzung mit Rollbackstrategien und Entscheidungen. Der Vorfall führte unmittelbar zur vollständigen Überarbeitung von Alpha im folgenden Jahr und schuf im Team einen guten Maßstab für Wartbarkeit.