Kurz gesagt: Verwenden Siepage.locator(selector).fill(value)für schnelle, deterministische Puppeteer-Skripte zum Absenden von Formularen undpage.type(), wenn die Seite auf echte Tastatureingaben achtet (Autocomplete, Anti-Bot, Live-Validierung). Sende das Formular ab, indem du auf die Schaltfläche klickst, die Eingabetaste drückst oderform.requestSubmit()und warte immer auf ein konkretes Erfolgssignal statt auf ein festes Timeout.
Formulare sind das, woran die meisten nützlichen Seiten tatsächlich funktionieren. Anmeldungen, Suchleisten, Checkout-Abläufe, Datei-Uploader, mehrstufige Onboarding-Assistenten: Wenn du das Web für Tests oder Scraping automatisierst, musst du früher oder später ein Formular ausfüllen. Ein Puppeteer-Workflow zum Absenden von Formularen wirkt zunächst täuschend einfach, stößt dann aber auf die Realitäten einer modernen Website: das erneute Rendern von Single-Page-Apps, versteckte Honeypots, Eingabefelder nur mit Beschriftung, in Iframes eingeschlossene Editoren und JavaScript, das Ihre Eingabe stillschweigend verworfen, weil es nie ein echtes keydown Ereignis gesehen hat.
Ein HTML-Formular ist ein <form> Element, das <input>, <select>, <textarea>und ähnliche Steuerelemente mit einem action -Attribut und einem Absende-Trigger, der die gesammelten Daten zur Verarbeitung sendet. Das ist die einfache Hälfte. Die schwierige Hälfte besteht darin, ein Headless-Chrome-Skript so zu gestalten, dass es sich ausreichend wie ein Mensch verhält, damit die Seite die Übermittlung tatsächlich akzeptiert und eine brauchbare Antwort zurückgibt.
Dieser Leitfaden ist das Spickzettel, das ich mir gewünscht hätte, als ich anfing, Puppeteer-Skripte in die Produktion zu bringen. Wir wählen die richtige API für die Typisierung aus, legen stabile Selektoren fest, gehen drei Absendestrategien durch und erklären, wann jede davon fehlschlägt, behandeln jeden gängigen Eingabetyp (einschließlich benutzerdefinierter Dateiauswahlfelder und Rich-Text-Editoren), warten auf das richtige Erfolgssignal, validieren das Ergebnis und schließen mit einer Debugging-Checkliste für den gefürchteten stillen Fehler ab.




