PHPStan 2.3 ist da, und es ist das spannendste Update seit Version 2.0. Die statische Analyse für PHP läuft bis zu 7,5 mal schneller als noch vor zehn Monaten. Gleichzeitig wird sie strenger: Sie findet ungenutzte Variablen, versteht Generics besser und braucht für Closures kein PHPDoc mehr. Hier lest ihr, wie ihr das Update in fünf Schritten sauber in euer Projekt bringt.
Update ohne Fehlerflut: Wir heben PHPStan in eurem Projekt auf 2.3, setzen Baseline und Result Cache in die Pipeline und arbeiten die neuen Meldungen gemeinsam mit eurem Team ab. Zum PHP Refactoring
Was PHPStan 2.3 bringt
Der Maintainer Ondřej Mirtes misst die Analyse des WordPress Quellcodes auf einem MacBook Pro mit M1 Pro. Vor den Optimierungen brauchte PHPStan dafür 60,5 Sekunden. Version 2.3.0 schafft es in 7,9 Sekunden. Den größten Anteil hat PHPStan Turbo: eine Extension, die heiße Teile des Analysers in C++ ausführt, Worker per Fork startet und per OPcache interne Typprüfungen entfernt.
Dazu kommen ein Result Cache, der bei Composer Updates nicht mehr komplett verfällt, fünf neue Regeln für ungenutzte Variablen und eine neu geschriebene Engine im Kern. Alle Details stehen im offiziellen Release Artikel. Die Einordnung für Einsteiger findet ihr in unserem PHPStan Glossar.
Schritt 1: PHPStan und Extensions gemeinsam heben
Zeitgleich mit 2.3.0 sind phpstan-symfony, phpstan-phpunit und phpstan-strict-rules in Version 2.1.0 erschienen. Hebt alles in einem Rutsch, sonst passen Cache Logik und Regeln nicht zusammen:
composer update phpstan/phpstan phpstan/phpstan-symfony phpstan/phpstan-phpunit phpstan/phpstan-strict-rules --with-all-dependenciesFür Symfony Teams lohnt sich das besonders. phpstan-symfony wirft den Cache bei Änderungen am DI Container nicht mehr weg, sondern analysiert nur noch die Dateien, die betroffene Services und Parameter nutzen. Laravel Teams aktualisieren Larastan entsprechend.
Schritt 2: Turbo nutzen, ohne etwas zu installieren
Turbo ist optional, aber ihr müsst nichts einrichten. Die .so und .dll Dateien liegen direkt im Composer Paket phpstan/phpstan. PHPStan sucht die passende Datei für eure PHP Version aus und startet sich mit der Extension neu. Wer PHPStan als Dev Abhängigkeit im Projekt hat, läuft also meist schon mit voller Geschwindigkeit. Laut Release Artikel macht Turbo PHPStan heute fast 60 Prozent schneller.
Schritt 3: Result Cache in die Pipeline bringen
Der eigentliche Gewinn im Alltag steckt im Result Cache. Auf Drupal braucht ein Lauf ohne Änderungen 1,6 Sekunden, mit zehn geänderten Dateien 2,8 Sekunden. Der volle Lauf dauert 22 Sekunden. Damit eure Pipeline davon profitiert, legt ihr den Cache Ordner fest und speichert ihn zwischen den Läufen.
# phpstan.neon
parameters:
tmpDir: var/cache/phpstan
# GitHub Actions
- uses: actions/cache@v4
with:
path: var/cache/phpstan
key: phpstan-${{ github.sha }}
restore-keys: phpstan-In GitLab CI erledigt das der cache Schlüssel. Wie ein kompletter Aufbau mit Docker, Staging und Preview URLs aussieht, zeigt unsere CI CD Pipeline.
Schritt 4: Bleeding Edge einschalten und Baseline neu erzeugen
Tempo und Cache wirken sofort. Die neuen Prüfungen nicht: Unused Variables, die neuen Generics und die Closure Typen laufen nur mit Bleeding Edge.
includes:
- vendor/phpstan/phpstan/conf/bleedingEdge.neonIn gewachsenen Projekten meldet PHPStan danach schnell ein paar hundert neue Stellen. Keine Panik. Erzeugt die Baseline neu, damit die Pipeline grün bleibt und nur neue Fehler anschlagen:
vendor/bin/phpstan analyse --generate-baseline| Neuerung | Wirkt sofort | Braucht Bleeding Edge |
|---|---|---|
| Turbo und schnellere Analyse | Ja | Nein |
| Präziserer Result Cache | Ja | Nein |
| Unused Variables | Nein | Ja |
| Generics ohne Skalar Verallgemeinerung | Nein | Ja |
| Closure und static Typen ohne PHPDoc | Nein | Ja |
Schritt 5: Unused Variables gezielt abarbeiten
Die neuen Regeln finden Werte, die berechnet und dann vergessen werden. Ein Klassiker: Die Cache Dauer steht in einer Variable, landet aber nie im Aufruf.
function cacheReport(Cache $cache, Report $report): void
{
$ttl = 3600;
$cache->save($report->getId(), $report);
}
// variable.unused: Variable $ttl is never read.Arbeitet die Baseline nach Regel ab, nicht nach Datei. Fangt mit variable.unused und assign.overwritten an, denn dort stecken die meisten echten Bugs. assign.redundant ist meist reine Kosmetik. Die Flow Regeln wie assign.unusedFlow folgen dem Data Flow Ansatz von Psalm und brauchen etwas mehr Blick auf den Zusammenhang. Für ungenutzte öffentliche Methoden bleibt Unused Public die Ergänzung.
Warum das Update für KI generierten Code zählt
Coding Agents schreiben schnell. Was sie gern liegen lassen, sind halbe Zuweisungen, überschriebene Werte und Parameter ohne Funktion. Genau das meldet PHPStan 2.3 jetzt. Bei uns gilt: Jede Änderung geht durch dieselben Quality Gates, egal ob Mensch oder Agent sie geschrieben hat. Erst PHPUnit und PHPStan, dann Rector und das eigentliche Aufräumen. Warum diese Reihenfolge so wichtig ist, steht in KI Refactoring zerstört die Applikation. Welche Gates bei jedem Push laufen, zeigt Quality Gates in der Pipeline.
Ein schönes Detail am Rande: Die bidirektionale Typableitung für Generics wurde vom Sovereign Tech Fund finanziert. Öffentliches Geld für Open Source Infrastruktur, das jedes PHP Team direkt spürt. Wer hinter PHPStan und den anderen Werkzeugen steht, zeigt PHP Refactoring Open Source: Die bekanntesten Projekte.
Häufige Fragen zum PHPStan 2.3 Update
Ist das Update auf PHPStan 2.3 im Jahr 2026 riskant?
Nein. Die Extension APIs bleiben kompatibel und ohne Bleeding Edge ändern sich die Regeln kaum. Ihr bekommt vor allem mehr Tempo. Neue Meldungen entstehen erst, wenn ihr Bleeding Edge einschaltet, und die fangt ihr mit einer frischen Baseline ab.
Wie schnell ist PHPStan 2.3 im Jahr 2026 wirklich?
Im Benchmark des Maintainers analysiert PHPStan WordPress in 7,9 Sekunden statt 60,5 Sekunden. Ohne Turbo sind es 19,5 Sekunden. Mit warmem Result Cache dauern Läufe auf großen Projekten oft nur wenige Sekunden.
Muss ich PHPStan Turbo 2026 extra installieren?
Nein. Die Turbo Dateien liegen im Composer Paket. PHPStan wählt die passende Datei für eure PHP Version und startet sich automatisch mit der Extension neu.
Welche Features brauchen 2026 Bleeding Edge?
Unused Variables, die neuen Generics ohne Verallgemeinerung von Skalaren sowie die Typen für Closures und static Variablen. Tempo und Result Cache wirken dagegen sofort nach dem Update.
Was mache ich 2026 mit hunderten neuen Meldungen?
Baseline neu erzeugen und dann nach Regel abarbeiten. Startet mit variable.unused und assign.overwritten, dort stecken die meisten echten Fehler. So bleibt die Pipeline grün und euer Team arbeitet die Liste in kleinen Schritten ab.
PHPStan 2.3 in eurem Projekt
Wir heben PHPStan und Extensions, richten Result Cache und Baseline in eurer Pipeline ein und arbeiten die neuen Meldungen mit eurem Team ab. Kennenlernen kostenlos, danach transparente Minuten Abrechnung.
