Top-Fehler von PHP-Anfängern: Fortgeschrittenes Niveau

Top-Fehler von PHP-Anfängern: Fortgeschrittenes Niveau

Wenn Sie von einfachen Skripten zu komplexen Webanwendungen in PHP übergehen, steigt die Anzahl der Fallstricke drastisch an. Viele Entwickler, die die grundlegende Syntax beherrschen, machen systemische Fehler, die zu Speicherlecks, Sicherheitslücken und Leistungseinbußen führen. In diesem Artikel analysieren wir 4 fortgeschrittene Fehler, die häufig bei Entwicklern mittleren Niveaus auftreten, und zeigen, wie man sie behebt.

1. Falsches Session-Management und Speicherlecks

Einer der tückischsten Fehler ist der falsche Umgang mit Sessions. Viele Entwickler speichern große Datenmengen in Sessions (z. B. Ergebnisse von Datenbankabfragen oder serialisierte Objekte). Dies verlangsamt nicht nur die Arbeit, sondern kann auch zu Speicherlecks auf dem Server führen.

Problem: Die Session wird während der Ausführung des Skripts blockiert. Wenn Sie 10 MB Daten darin speichern, wird jeder Request diese Datenmenge lesen und schreiben, und bei parallelen Requests bildet sich eine Warteschlange.

Beispiel für schlechten Code:

<?phpsession_start();// Laden eines Arrays mit 10000 Einträgen in die Session$_SESSION['big_data'] = $db->query("SELECT * FROM logs")->fetchAll();?>

Lösung: Verwenden Sie Sessions nur zur Identifikation (user_id, Token). Alle anderen Daten speichern Sie im Cache (Redis, Memcached) oder in der Datenbank.

<?phpsession_start();$_SESSION['user_id'] = $user->id;// Daten werden bei Bedarf abgerufen$cache = new RedisCache();$data = $cache->get('user_data_' . $user->id);if (!$data) {    $data = $db->query("SELECT * FROM logs WHERE user_id = ?", [$user->id])->fetchAll();    $cache->set('user_data_' . $user->id, $data, 3600);}?>

2. Falsches Caching und Ignorieren der Invalidierung

Der zweithäufigste Fehler ist das "ewige" Caching. Entwickler setzen die Cache-Lebensdauer (TTL) auf 24 Stunden oder mehr und wundern sich dann, warum Benutzer veraltete Daten sehen. Noch schlimmer ist Caching ohne Berücksichtigung von Änderungen in der Datenbank.

Problem: Wenn Sie eine Produktliste für 1 Stunde cachen und ein Administrator den Preis ändert, sehen die Benutzer den alten Preis noch 60 Minuten lang.

Beispiel für schlechten Code:

<?php$cacheKey = 'product_list';$products = $cache->get($cacheKey);if (!$products) {    $products = $db->query("SELECT * FROM products")->fetchAll();    $cache->set($cacheKey, $products, 86400); // 24 Stunden}?>

Lösung: Verwenden Sie Cache-Tagging oder erzwingen Sie die Invalidierung bei Datenänderungen.

<?php// Beim Aktualisieren eines Produktsfunction updateProduct($id, $data) {    $db->update("products", $data, ["id" => $id]);    // Cache invalidieren    $cache->delete('product_list');    $cache->delete('product_' . $id);}

// Beim Lesen$products = $cache->remember('product_list', 3600, function() use ($db) {    return $db->query("SELECT * FROM products WHERE active = 1")->fetchAll();});?>

3. SQL-Injection durch "sichere" Funktionen

Viele Entwickler glauben, dass sie mit mysqli_real_escape_string() oder addslashes() vor SQL-Injection geschützt sind. Dies ist ein gefährlicher Irrglaube. Diese Funktionen schützen nicht vor allen Angriffsarten, insbesondere bei der Arbeit mit LIKE, ORDER BY und LIMIT.

Problem: Die Funktion mysqli_real_escape_string() escaped keine Zeichen für den LIKE-Operator (z. B. % und _). Wenn Sie Benutzereingaben in LIKE einsetzen, kann ein Angreifer auf Daten zugreifen, die er nicht sehen sollte.

Beispiel für eine Sicherheitslücke:

<?php$search = $_GET['q'];$safe = mysqli_real_escape_string($conn, $search);$query = "SEL