Que Que Significa Psr

O que é PSR no mundo PHP

PSR significa PHP Standard Recommendation. É um conjunto de especificações técnicas criadas pelo PHP Framework Interop Group, que basicamente tenta fazer com que diferentes bibliotecas e frameworks PHP conversem entre si sem brigar. Tem gente que acha que é só "um guia de estilo de código". Não é. PSR define contratos reais que bibliotecas implementam, como autoload, logging, cache, HTTP message e container de dependências. Quando você vê um package no Packagist dizendo que segue PSR-4 ou PSR-11, não é marketing — é uma garantia técnica de compatibilidade.

que que significa psr no dia a dia

No dia a dia, o que importa mesmo são poucos números. PSR-1 cuida do básico: arquivos PHP usam

?php, encoding UTF-8, nomes de classes em StudlyCaps, constantes em maiúsculas. PSR-4 é provavelmente o mais relevante: é o padrão de autoload de classes via Composer. Se seu autoloader não segue PSR-4, composer dump-autoload vai te dar problemas chatos que levam horas pra diagnosticar. PSR-12 define a formatação do código — chaves fechando na própria linha, 4 espaços de indentação, declarações de uso agrupadas. PSR-3 é sobre logging: qualquer lib que siga ele pode receber um logger que você injeta, independente de ser Monolog, Symfony Logger ou outra coisa. PSR-11 define o container de dependências mínimo. PSR-16 é o cache simples. Na prática, isso significa que você pode trocar o cache de Redis para arquivo sem mudar uma linha do seu código, desde que ambos sigam PSR-16. Se não seguissem, cada biblioteca teria sua própria API e você estaria preso a uma implementação.

O problema que eu encontrei uma vez foi específico: atualizei um projeto de PSR-0 para PSR-4 e o autoload quebrou silenciosamente. O Composer não dava erro no dump-autoload, mas as classes simplesmente não eram carregadas em produção. A causa era um namespace mal formatado no arquivo de composer.json — tinha um hífen no namespace que deveria ser underscore, algo que o PSR-4 proíbe explicitamente. A solução foi rodar composer dump-autoload -a (class map) temporariamente e depois corrigir o autoloader. Gastei meia tarde nisso porque o erro só aparecia em produção, não local. Um insight que poucos começam a entender: PSR não é sobre opinião estética. É sobre interop. Isso significa que seguir PSR às vezes te obriga a escrever código que você consideraria feio ou limitado. O PSR-11 por exemplo define apenas get() e has() no container. Bibliotecas avançadas oferecem resolver, factory, alias — mas se você quiser trocar de container, está travado nessas duas interfaces. Vale a pena? Depende. Para projetos pequenos, sim. Para sistemas grandes onde o container é o coração da arquitetura, a limitação dói. A outra nuance que os iniciantes ignoram: seguir PSR não é automático. Você pode configurar o Composer para PSR-4 e mesmo assim ter classes fora do padrão. O autoload só funciona se o arquivo estiver exatamente no caminho esperado pelo namespace. Um arquivo App/Services/UserService.php precisa mapear exatamente para o namespace App\Services\UserService. Espaços extras, letras maiúsculas erradas, diretório com hífen — qualquer desvio e o autoload falha. Ferramentas como Psalm ou PHPStan não validam PSR-4 automaticamente, então você precisa de atenção manual ou criar scripts customizados de verificação.

Se você está começando e quer aplicar isso num projeto novo, a parte prática é simples: use Composer, configure o autoload no composer.json seguindo PSR-4, instale packages que declarem compatibilidade PSR nos metadados e rode composer dump-autoload sempre que alterar namespaces. O tempo economizado evitando erros de autoload é real — perde-se de 20 minutos a 2 horas tentando achar o problema, dependendo do tamanho do projeto. PSR também tem suas falhas. Não abrange teste, performance, segurança ou arquitetura. Existem centenas de PSRs não-oficiais, guias de estilo de pacotes específicos e convenções de equipe que conflitam entre si. O PSR-12 por exemplo foi polêmico quando lançado porque mudava padrões que muitos já tinham adotado. E o mais irritante: o PHP em si não impõe nenhuma dessas regras. Você pode escrever um programa perfeitamente funcional que ignora todos os PSRs e funciona sem problema — até precisar integrar com outra biblioteca. Se o seu projeto é pequeno e autossuficiente, PSR é overkill. Mas assim que precisar conectar pacotes de terceiros ou trocar frameworks, a falta de padronização se transforma em dor de cabeça real. Nesses casos, o básico de PSR-1, PSR-4 e PSR-12 já resolve 90% dos problemas de interoperabilidade que aparecem.