Se você chegou até aqui, provavelmente já ouviu alguém dizer que "PHP está morto". Talvez tenha lido isso num fórum, num comentário do YouTube ou num artigo sensacionalista. A realidade, porém, conta uma história muito diferente. E é por isso que estudar PHP hoje em dia (2026) pode ser útil e prazeroso.
PHP alimenta mais de 76% de todos os sites com backend conhecido na web. Isso inclui o WordPress, o Facebook (que nasceu em PHP e até hoje mantém o Hack, um dialeto derivado dele), o Wikipedia, o Slack em suas origens, e milhares de sistemas empresariais que movimentam bilhões de reais por dia. Não é uma linguagem moribunda — é uma linguagem madura, battle-tested, e em constante evolução.
Mas o problema real não é o PHP em si.
O problema é a forma como ele é ensinado.
O ciclo vicioso do ensino incompleto
Você provavelmente já viveu isso: começa um curso ou uma série de artigos animado. Aprende variáveis, condicionais, loops. Talvez chegue até funções. Num ponto mais avançado, aparece algo sobre banco de dados com mysqli_connect() e uns echo espalhados no meio do HTML.
E para por aí.
Ninguém te mostra o que vem depois. Ninguém te mostra como um sistema PHP de verdade é estruturado. Você termina o curso sabendo fazer um formulário de contato, mas sem a menor ideia de como construir algo que possa ser mantido, escalado ou entregue num ambiente profissional.
Esse gap entre "aprender PHP" e "trabalhar com PHP" é enorme — e é exatamente ele que esta série quer eliminar.
O que é PHP, afinal?
PHP (Hypertext Preprocessor, originalmente Personal Home Page) é uma linguagem de script interpretada, de tipagem dinâmica, originalmente projetada para desenvolvimento web server-side. Criada por Rasmus Lerdorf em 1994, ela nasceu de uma necessidade prática: rastrear visitas a um currículo online. O que começou como um conjunto de scripts CGI em C virou uma das linguagens mais influentes da história da internet.
Tecnicamente, o PHP roda no servidor, processa a requisição HTTP, interage com banco de dados, aplica lógica de negócio e devolve uma resposta — normalmente HTML, JSON ou XML — ao cliente. Ele pode ser executado como módulo do Apache, via PHP-FPM com Nginx, como CLI para scripts de automação, ou até como processo assíncrono com extensões como Swoole e ReactPHP.
Com o PHP 8.x, a linguagem ganhou recursos que a colocam no mesmo patamar de expressividade de Python e Ruby moderno: JIT compiler, union types, named arguments, fibers para concorrência, match expressions, enums, readonly properties, e muito mais. Não é a linguagem bagunçada dos anos 2000 que muita gente ainda imagina.
Onde e como ele é usado hoje?
E-commerce: Magento, WooCommerce e sistemas customizados em Laravel processam pagamentos, estoques e logística de algumas das maiores lojas virtuais do mundo.
CMS e portais de conteúdo: WordPress, Drupal e Joomla dominam o mercado de gerenciamento de conteúdo. Só o WordPress representa 43% de todos os sites da internet.
SaaS e sistemas empresariais: Ferramentas de gestão, ERPs, plataformas de RH e sistemas financeiros são construídos diariamente com Laravel, Symfony e Slim Framework por equipes que valorizam produtividade e ecossistema maduro.
APIs e microsserviços: Com frameworks modernos e o padrão PSR, PHP é uma escolha legítima e performática para expor APIs REST e GraphQL consumidas por aplicações mobile e frontend desacoplado.
Automação e CLI: Scripts de processamento de dados, pipelines de integração, tarefas agendadas via cron — PHP tem suporte robusto para tudo isso com sua poderosa CLI.
Por que esta série é diferente
A maioria dos conteúdos sobre PHP te ensina o que é a linguagem. Esta série quer te mostrar como pensar com ela.
Você vai acompanhar a evolução natural de um desenvolvedor PHP: partindo dos fundamentos reais da linguagem, passando pela orientação a objetos aplicada com intenção, entendendo bancos de dados além do SELECT *, estruturando projetos com Composer e boas práticas PSR, dominando o Laravel, construindo APIs seguras e testadas — até chegar num projeto completo que conecta todos esses pontos.
Cada módulo foi pensado para que você não apenas entenda o conceito, mas veja ele se transformar em código real, com decisões arquiteturais justificadas, erros comuns apontados, e o caminho de evolução sempre claro à sua frente.
Porque o objetivo não é apenas aprender PHP. É aprender a construir sistemas com PHP — e entender por que cada escolha importa.
O que você vai aprender
| Módulo | Tema |
|---|---|
| 1 | Fundamentos + História do PHP |
| 2 | Funções e Manipulação de Dados |
| 3 | Orientação a Objetos (POO) |
| 4 | Bancos de Dados: MySQL, PostgreSQL, SQLite, MongoDB |
| 5 | Web com PHP (Forms, Sessions, Cookies) |
| 6 | PHP Moderno (Composer, Namespaces, PSR, Boas Práticas) |
| 7 | Laravel |
| 8 | APIs REST |
| 9 | Segurança |
| 10 | Testes e Qualidade |
| 11 | Projeto Final |
Para quem é esta série?
Para quem está começando e quer construir uma base sólida desde o início, sem os vícios que o ensino rápido e fragmentado costuma criar. Para quem já sabe "um pouco de PHP" mas sente que falta o próximo nível — aquele que separa quem faz funcionar de quem faz funcionar direito. E para quem quer ter, ao final, um projeto real no portfólio que demonstre domínio técnico de verdade.
Não existe atalho para competência. Mas existe um caminho bem mapeado.
Fontes e leituras recomendadas
Oficiais
- Manual do PHP — A documentação oficial, boa parte traduzida para português, com os comentários da comunidade em cada função.
- PHP — Histórico de versões — O que mudou em cada versão e, sobretudo, quais ainda recebem correções de segurança — informação que decide o que usar em produção.
Padrões e boas práticas
- PHP: The Right Way — Guia comunitário que separa a prática atual do que ficou para trás. Antídoto direto contra tutorial desatualizado, que é o problema central deste artigo.
- PSRs — PHP-FIG — As recomendações que padronizam autoload, estilo de código, interfaces HTTP e contêiner de dependências — a base da interoperabilidade entre frameworks.
Ferramentas
- Composer — Documentação — O gerenciador de dependências que organizou o ecossistema, com o autoload PSR-4 que tornou obsoleto o include manual.
- Packagist — O repositório central de pacotes, onde se avalia manutenção, downloads e compatibilidade antes de adotar uma biblioteca.
Exercícios
Exercício 1
Você cita em uma reunião que "PHP roda mais de 76% da web" e alguém rebate: "esse número é propaganda". O que ele mede de fato, e o que não mede?
Ver resposta
✓ Resposta: O número vem do W3Techs e mede uma coisa específica: entre os sites cuja linguagem de servidor é detectável, qual fatia responde PHP. Já aí há três limites. Primeiro, só entra site que se deixa identificar — cabeçalho X-Powered-By, cookie de sessão, extensão de arquivo; quem está atrás de CDN ou removeu esses sinais fica de fora da conta. Segundo, a unidade é site, não requisição: um blog parado e um portal com milhões de acessos pesam igual, então o número não diz nada sobre volume de tráfego. Terceiro, a fatia é puxada pelo WordPress, que sozinho responde por perto de 43% de todos os sites — não é que 76% das equipes escolheram PHP, é que a maioria dos sites do mundo é WordPress. E ele não mede o que mais interessa a quem decide: quantos projetos novos estão nascendo em PHP. A leitura honesta do dado é esta: prova longevidade e um mercado gigante de manutenção, não superioridade técnica nem tendência. Usar o número como argumento de qualidade é o erro que dá razão a quem rebateu.
Exercício 2
Você assume a manutenção de um sistema em PHP 7.4 que "funciona bem e ninguém quer mexer". Qual é o primeiro problema a apontar, e por onde se começa?
Ver resposta
✓ Resposta: O problema não é desempenho nem estilo de código: é que o 7.4 não recebe correção de segurança desde novembro de 2022. Toda falha descoberta depois disso continua aberta nesse servidor. Em setembro de 2026, quem recebe correção é só o 8.4 e o 8.5 (suporte ativo) e o 8.2 e o 8.3 (apenas segurança) — o ramo 7 inteiro e o 8.0/8.1 estão fora. "Funciona bem" descreve o comportamento observável, não o risco. E o primeiro passo não é reescrever: é subir a versão, que costuma ser menos trabalhoso do que a lenda sugere, porque as quebras do 8.x são conhecidas e catalogadas. O caminho prático é rodar composer why-not php 8.4 para ver qual dependência trava a subida, apontar o PHPStan no nível mais baixo que passe, usar o Rector com o conjunto de regras da versão-alvo para a parte mecânica, e só então subir em homologação com as extensões conferidas uma a uma — php -m na máquina antiga e na nova, comparando. Reescrever um sistema que funciona é a decisão mais cara que existe; atualizar a versão é a mais barata que resolve o risco real.
Exercício 3
Um script de importação processa 80 mil linhas e leva cerca de 40 minutos. Chamado pelo navegador, ele morre no meio, sem erro claro no log da aplicação. Onde está o problema?
Ver resposta
✓ Resposta: O problema é o caminho escolhido, não o script. Uma requisição HTTP atravessa uma fila de limites de tempo e o menor deles vence: o max_execution_time do PHP (30 segundos por padrão), o request_terminate_timeout do pool do PHP-FPM, o fastcgi_read_timeout do Nginx (ou o ProxyTimeout do Apache), e ainda o tempo que o navegador e qualquer proxy no meio aceitam esperar. Aumentar só o primeiro não resolve — é por isso que o script "morre sem erro": quem cortou a conexão foi uma camada que nem sabe o que é PHP. Há um agravante: enquanto esse processo ocupa um worker do FPM por 40 minutos, ele sai do pool de atendimento, e pm.max_children é um número pequeno. Meia dúzia de importações simultâneas derrubam o site inteiro. A saída é tirar a tarefa longa da requisição: rodar pela CLI, onde o max_execution_time vale 0 por padrão (sem limite), acionada por cron ou por uma fila de jobs. A requisição, então, só enfileira e responde na hora — e o navegador acompanha o progresso consultando o estado, em vez de segurar a conexão aberta.
Exercício 4
Um tutorial popular ensina a listar usuários assim. Aponte o que falta para esse código ser aceitável em produção — e qual dos problemas é o mais grave.
<?php
$con = mysqli_connect("localhost", "root", "", "loja");
$busca = $_GET['busca'];
$sql = "SELECT * FROM usuarios WHERE nome LIKE '%$busca%'";
$res = mysqli_query($con, $sql);
while ($u = mysqli_fetch_assoc($res)) {
echo "<li>" . $u['nome'] . "</li>";
}Ver resposta
✓ Resposta: O mais grave é a injeção de SQL: $_GET['busca'] entra na consulta por interpolação de string, então quem controla a URL controla o SQL. Isso não se resolve com addslashes nem escapando à mão — resolve-se com prepared statement, em que o valor viaja separado do comando: $stmt = $pdo->prepare('SELECT nome FROM usuarios WHERE nome LIKE ?'); $stmt->execute(["%{$busca}%"]);. Em segundo lugar vem o XSS: o nome vindo do banco é impresso cru, e um cadastro com <script> vira código executando no navegador de quem lista — a saída precisa de htmlspecialchars($u['nome'], ENT_QUOTES, 'UTF-8'). Depois, três defeitos silenciosos: o SELECT * traz colunas que ninguém pediu (inclusive o hash da senha, que passa a trafegar sem necessidade); não há tratamento de erro algum, porque o mysqli procedural devolve false em silêncio em vez de lançar exceção; e credencial de banco está escrita no arquivo, com usuário root e senha vazia. Repare no que não está na lista: usar mysqli em vez de PDO não é o problema. O problema é misturar conexão, consulta e apresentação em oito linhas, sem fronteira nenhuma entre entrada do usuário, comando e saída.
Exercício 5
Desafio: pedem que você construa um chat com cinco mil conexões simultâneas. O PHP dá conta? Defenda sua resposta com o modelo de execução da linguagem.
Ver resposta
✓ Resposta: Dá, mas não do jeito clássico — e entender por quê vale mais do que a resposta. O modelo tradicional do PHP é um processo por requisição, que nasce, responde e morre: o estado é descartado no fim, o que simplifica enormemente a vida do programador e é justamente o que torna o modelo inadequado para conexão persistente. Com PHP-FPM, cada conexão aberta ocupa um worker; pm.max_children costuma ficar na casa das dezenas, porque cada worker carrega um interpretador inteiro na memória. Cinco mil conexões simultâneas nesse modelo exigiriam cinco mil processos — não é questão de ajustar configuração, é o modelo errado para o problema. As saídas reais são três. A primeira é usar um runtime de event loop em PHP: Swoole, OpenSwoole ou ReactPHP mantêm o processo vivo e multiplexam milhares de conexões em poucos processos, ao custo de um modelo de memória diferente (estado que sobrevive entre requisições vaza, e vazar em processo longevo é um problema novo para quem vem do PHP clássico). A segunda é Laravel Reverb, servidor WebSocket em PHP que já embrulha isso. A terceira, e a mais comum em produção, é não fazer o WebSocket em PHP: um serviço dedicado cuida das conexões e o PHP continua sendo a API que autentica, autoriza e persiste. A resposta profissional não é "PHP não serve", nem "serve para tudo" — é saber qual parte do problema cabe a qual ferramenta.