Principais erros de desenvolvedores PHP iniciantes: nível avançado

Principais erros de desenvolvedores PHP iniciantes: nível avançado

Quando você passa de scripts simples para aplicações web complexas em PHP, o número de armadilhas aumenta drasticamente. Muitos desenvolvedores, após dominarem a sintaxe básica, cometem erros sistêmicos que levam a vazamentos de memória, vulnerabilidades e queda de desempenho. Neste artigo, analisaremos 4 erros avançados que são comuns entre desenvolvedores de nível intermediário e mostraremos como corrigi-los.

1. Gerenciamento incorreto de sessões e vazamentos de memória

Um dos erros mais traiçoeiros é o trabalho incorreto com sessões. Muitos desenvolvedores armazenam grandes volumes de dados nas sessões (por exemplo, resultados de consultas ao banco de dados ou objetos serializados). Isso não apenas torna o sistema mais lento, mas também pode causar vazamentos de memória no servidor.

Problema: A sessão é bloqueada durante a execução do script. Se você armazenar 10 MB de dados nela, cada requisição lerá e gravará esse volume e, em requisições paralelas, elas serão enfileiradas.

Exemplo de código ruim:

<?phpsession_start();// Carregamos na sessão um array de 10000 registros$_SESSION['big_data'] = $db->query("SELECT * FROM logs")->fetchAll();?>

Solução: Use sessões apenas para identificação (user_id, token). Todos os outros dados armazene em cache (Redis, Memcached) ou no banco de dados.

<?phpsession_start();$_SESSION['user_id'] = $user->id;// Dados obtidos sob demanda$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. Cache incorreto e ignorância de invalidação

O segundo erro mais comum é o cache "para sempre". Os desenvolvedores definem o tempo de vida do cache (TTL) para 24 horas ou mais e depois se surpreendem por que os usuários veem dados desatualizados. Pior ainda é o cache sem considerar alterações no banco de dados.

Problema: Se você armazenar em cache a lista de produtos por 1 hora e um administrador alterar o preço, os usuários verão o preço antigo por mais 60 minutos.

Exemplo de código ruim:

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

Solução: Use marcação de cache ou invalidação forçada ao alterar dados.

<?php// Ao atualizar um produtofunction updateProduct($id, $data) {    $db->update("products", $data, ["id" => $id]);    // Invalidamos o cache    $cache->delete('product_list');    $cache->delete('product_' . $id);}

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

3. Injeções SQL através de funções "seguras"

Muitos desenvolvedores acreditam que, se usarem mysqli_real_escape_string() ou addslashes(), estão protegidos contra injeções SQL. Este é um equívoco perigoso. Essas funções não protegem contra todos os tipos de ataque, especialmente ao trabalhar com LIKE, ORDER BY e LIMIT.

Problema: A função mysqli_real_escape_string() não escapa caracteres para o operador LIKE (por exemplo, % e _). Se você inserir a entrada do usuário em LIKE, um invasor pode obter acesso a dados que não deveria ver.

Exemplo de vulnerabilidade:

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