Symfony 8 em 2026: Novidades, PHP 8.4 Lazy Objects e Perguntas de Entrevista

O Symfony 8, lançado em novembro de 2025, remove dois anos de depreciações e entrega o mesmo conjunto de funcionalidades do Symfony 7.4 — mas com um requisito estrito de PHP 8.4. Essa exigência desbloqueia os lazy objects nativos, os property hooks e o novo parser HTML5 — três adições no nível da linguagem que o framework agora utiliza internamente. Este artigo detalha as funcionalidades que transformam o desenvolvimento diário, impactam a preparação para entrevistas e merecem atenção em atualizações de produção.

Lazy Objects Nativos Substituem a Geração de Proxies

O PHP 8.4 introduz lazy objects no nível do motor através de ReflectionClass::newLazyGhost() e ReflectionClass::newLazyProxy(). O Symfony 8 aproveita isso diretamente: o componente DependencyInjection não gera mais classes proxy para serviços lazy. Em vez disso, cria ghost objects que se inicializam no primeiro acesso a uma propriedade.

A consequência prática é significativa. Classes final e readonly — anteriormente incompatíveis com o lazy loading baseado em proxies do Symfony — agora funcionam sem soluções alternativas. O Doctrine se beneficia igualmente: os proxies de entidades não requerem mais geração de código, eliminando um fardo de manutenção que persistiu por mais de uma década.

namespace App\Service;

use Symfony\Component\DependencyInjection\Attribute\Lazy;

#[Lazy]
final readonly class HeavyReportGenerator
{
    public function __construct(
        private DatabaseConnection $db,
        private PdfEngine $pdf,
        private CacheInterface $cache,
    ) {
        // Constructor runs only when a method is actually called
    }

    public function generate(int $reportId): string
    {
        $data = $this->db->fetchReport($reportId);
        return $this->pdf->render($data);
    }
}

O atributo #[Lazy] marca o serviço para instanciação como ghost object. O container injeta um invólucro idêntico ao HeavyReportGenerator. O construtor — e as três dependências injetadas — só executam quando generate() é chamado. Para serviços usados condicionalmente (geração de relatórios acionada por uma ação administrativa específica, por exemplo), isso elimina conexões desnecessárias ao banco de dados e alocações de memória em cada requisição.

A variante #[Autowire(lazy: true)] permite a injeção lazy no ponto de chamada sem modificar a classe do serviço:

namespace App\Controller;

use Symfony\Component\DependencyInjection\Attribute\Autowire;

class DashboardController
{
    public function __construct(
        #[Autowire(lazy: true)]
        private HeavyReportGenerator $reportGenerator,
    ) {}
}

Em contextos de entrevista, é esperado encontrar perguntas sobre a diferença entre ghost objects e proxies virtuais. Ghost objects inicializam a instância original no local. Proxies virtuais delegam para uma instância separada totalmente inicializada. O Symfony usa ghosts por padrão, exceto quando uma factory está envolvida — nesse caso, alterna automaticamente para proxies.

Formulários Multi-Step com AbstractFlowType

Antes do Symfony 8, formulários multi-step exigiam bundles de terceiros como o CraueFormFlowBundle. O framework agora disponibiliza o AbstractFlowType — um motor de fluxo de formulários nativo com validação por etapa, ramificação condicional e navegação integrada.

namespace App\Form;

use Symfony\Component\Form\Flow\AbstractFlowType;
use Symfony\Component\Form\Flow\FormFlowBuilderInterface;
use Symfony\Component\OptionsResolver\OptionsResolver;

class UserSignUpType extends AbstractFlowType
{
    public function buildFormFlow(FormFlowBuilderInterface $builder, array $options): void
    {
        $builder->addStep('personal', UserPersonalType::class);
        $builder->addStep('professional', UserProfessionalType::class);
        $builder->addStep('account', UserAccountType::class);

        $builder->add('navigator', NavigatorFlowType::class);
    }

    public function configureOptions(OptionsResolver $resolver): void
    {
        $resolver->setDefaults([
            'data_class' => UserSignUp::class,
            'step_property_path' => 'currentStep',
        ]);
    }
}

Cada nome de etapa também funciona como grupo de validação. A classe de dados UserSignUp usa #[Valid] com constraints de grupo para validar apenas a etapa ativa:

namespace App\DTO;

use Symfony\Component\Validator\Constraints as Assert;

class UserSignUp
{
    public function __construct(
        #[Assert\Valid(groups: ['personal'])]
        public Personal $personal = new Personal(),

        #[Assert\Valid(groups: ['professional'])]
        public Professional $professional = new Professional(),

        #[Assert\Valid(groups: ['account'])]
        public Account $account = new Account(),

        public string $currentStep = 'personal',
    ) {}
}

O controller segue o padrão de tratamento de formulários do Symfony. isFinished() retorna true somente após a validação da última etapa:

#[Route('/signup')]
public function __invoke(Request $request): Response
{
    $flow = $this->createForm(UserSignUpType::class, new UserSignUp())
        ->handleRequest($request);

    if ($flow->isSubmitted() && $flow->isValid() && $flow->isFinished()) {
        $this->userService->register($flow->getData());
        return $this->redirectToRoute('app_signup_success');
    }

    return $this->render('signup/flow.html.twig', [
        'form' => $flow->getStepForm(),
    ]);
}

Os botões de navegação (NextFlowType, PreviousFlowType, FinishFlowType, ResetFlowType) suportam renderização condicional via include_if, pular etapas com skip e navegação direta com back_to. Isso cobre a maioria dos padrões de wizards encontrados em produção sem gerenciamento de estado personalizado em JavaScript.

Comandos Invocáveis com Atributos de Entrada

Os comandos de console não precisam mais estender a classe base Command nem sobrescrever configure(). O método __invoke() recebe argumentos e opções diretamente através de atributos PHP.

namespace App\Command;

use Symfony\Component\Console\Attribute\AsCommand;
use Symfony\Component\Console\Attribute\Argument;
use Symfony\Component\Console\Attribute\Option;
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Style\SymfonyStyle;

#[AsCommand(
    name: 'app:create-user',
    description: 'Create a new user account',
)]
class CreateUserCommand
{
    public function __invoke(
        SymfonyStyle $io,
        #[Argument(description: 'The username for the new account')]
        string $username,
        #[Argument(description: 'The email address')]
        string $email,
        #[Option(shortcut: 'r', description: 'Role to assign')]
        string $role = 'ROLE_USER',
        #[Option(description: 'Activate immediately')]
        bool $activate = false,
    ): int {
        // User creation logic
        $io->success(sprintf('User "%s" created with role %s.', $username, $role));
        return Command::SUCCESS;
    }
}

O Symfony 8 adiciona suporte a backed enums para argumentos e opções. A entrada do tipo string é convertida automaticamente para o case correspondente do enum:

enum CloudRegion: string {
    case UsEast = 'us-east';
    case UsWest = 'us-west';
    case EuWest = 'eu-west';
}

// In the command
public function __invoke(
    SymfonyStyle $io,
    #[Argument] CloudRegion $region,
    #[Option] ?ServerSize $size = null,
): int {
    $io->info(sprintf('Deploying to %s', $region->value));
    return Command::SUCCESS;
}

Para comandos com muitos parâmetros, #[MapInput] mapeia a entrada para um DTO:

class DeployInput
{
    #[Argument]
    public CloudRegion $region;

    #[Option]
    public string $branch = 'main';

    #[Option(shortcut: 'f')]
    public bool $force = false;
}

// src/Command/DeployCommand.php
#[AsCommand(name: 'app:deploy')]
class DeployCommand
{
    public function __invoke(
        SymfonyStyle $io,
        #[MapInput] DeployInput $input,
    ): int {
        // Access $input->region, $input->branch, $input->force
        return Command::SUCCESS;
    }
}

Esse padrão elimina a cerimônia de configure() + execute() e torna os comandos testáveis construindo o DTO diretamente.

Componentes JsonStreamer, JsonPath e ObjectMapper

Três novos componentes autônomos são distribuídos com o Symfony 8:

JsonStreamer processa payloads JSON de grande volume sem carregar o documento inteiro na memória. Para APIs que lidam com respostas na escala de megabytes — exportações em massa, feeds de analytics, ingestão de logs — isso evita o limite de memória do json_decode().

JsonPath implementa um subconjunto da RFC 9535 para navegar em estruturas JSON aninhadas. Em vez de decodificar uma resposta inteira e percorrer arrays manualmente, uma expressão de caminho extrai os dados alvo diretamente.

ObjectMapper converte entre DTOs e arrays/JSON usando atributos PHP, substituindo a lógica de hidratação escrita manualmente. Combinado com o componente Serializer, cobre o ciclo completo do mapeamento de requisição/resposta em APIs.

Melhorias de Segurança e Experiência do Desenvolvedor

A proteção CSRF não requer mais sessões no servidor. A nova implementação CSRF stateless funciona com cache HTTP, tornando-a viável para arquiteturas API-first e páginas cacheadas por CDN.

O componente Messenger suporta assinatura de mensagens — assinaturas criptográficas nos payloads previnem adulteração entre produtor e consumidor. Para sistemas onde a integridade das mensagens importa (processamento de pagamentos, trilhas de auditoria), isso substitui middleware de assinatura personalizado.

Novas constraints de validação cobrem charsets, endereços MAC, números de semana ISO, contagem de palavras, sintaxe YAML, slugs, templates Twig e arquivos de vídeo. A constraint #[Slug] sozinha elimina um validador customizado comum.

Os security voters agora explicam suas decisões no profiler. Depurar a lógica de autorização — anteriormente um processo de adivinhação para identificar qual voter negou o acesso — se torna uma consulta direta na barra do profiler do Symfony.

Property Hooks do PHP 8.4 no Contexto do Symfony

Os property hooks (get e set definidos diretamente nas propriedades de classe) se integram naturalmente com o ecossistema Symfony. Entidades Doctrine podem usar hooks para propriedades calculadas. Tipos de formulário podem aproveitar hooks para transformação de dados. Constraints de validação funcionam em propriedades com hooks sem modificações.

class Product
{
    public string $name {
        set(string $value) {
            $this->name = trim($value);
        }
    }

    public float $price {
        set(float $value) {
            if ($value < 0) {
                throw new \InvalidArgumentException('Price cannot be negative');
            }
            $this->price = $value;
        }
    }

    public float $priceWithTax {
        get => $this->price * 1.20;
    }
}

Os property hooks reduzem a necessidade de pares getter/setter e movem a aplicação de invariantes para a definição da propriedade. Em formulários Symfony, isso significa menos boilerplate de transformadores. Em entidades Doctrine, valores calculados permanecem próximos dos dados dos quais dependem.

Perguntas de Entrevista para Preparar

O Symfony 8 muda o que os entrevistadores avaliam. Os seguintes tópicos aparecem regularmente nas preparações para entrevistas Symfony:

• Lazy objects: Explicar a diferença entre ghost objects e proxies virtuais. Quando o Symfony escolhe um em vez do outro? Por que o PHP 8.4 torna serviços final readonly compatíveis com lazy loading?
• Formulários multi-step: Como o AbstractFlowType lida com a validação por etapa? Qual o papel do step_property_path? Como funcionam as etapas condicionais?
• Comandos invocáveis: O que substitui configure() nos comandos invocáveis? Como funciona o #[MapInput]? Quais são as regras para valores padrão de #[Option]?
• Novos componentes: Quando o JsonStreamer seria preferível ao json_decode()? Qual problema o ObjectMapper resolve que o Serializer não cobre?
• Estratégia de atualização: Por que atualizar para a 7.4 antes da 8.0 é recomendado? O que a remoção de 13.202 linhas de código de depreciação implica para a compatibilidade retroativa?

Estes tópicos devem ser praticados com código real. O módulo de comandos de console do Symfony e o módulo avançado de Doctrine cobrem as áreas mais frequentemente avaliadas.

Conclusão

• O Symfony 8 requer PHP 8.4 e adota totalmente os lazy objects nativos, eliminando a geração de código proxy tanto para o container DI quanto para o Doctrine ORM
• O AbstractFlowType substitui bundles de terceiros para formulários multi-step, com grupos de validação por etapa e botões de navegação integrados
• Comandos invocáveis com #[Argument], #[Option] e #[MapInput] eliminam o boilerplate e suportam backed enums e DTOs
• Três novos componentes (JsonStreamer, JsonPath, ObjectMapper) abordam o processamento JSON e o mapeamento de objetos sem dependências externas
• CSRF stateless, assinatura de mensagens, depuração de security voters e mais de 20 novas constraints de validação fortalecem a superfície de segurança e experiência do desenvolvedor
• Os property hooks do PHP 8.4 se integram de forma transparente com entidades Doctrine, formulários Symfony e constraints de validação
• O caminho de atualização passa pelo Symfony 7.4: corrigir todas as depreciações lá antes de migrar para o 8.0