Os erros de regex que fazem você perder a tarde

A maioria das tardes perdidas com regex vem de um entre três erros. Um quantificador é guloso e pega mais do que você queria. Um ponto se recusa a atravessar uma quebra de linha. Ou uma substituição só mexe na primeira ocorrência porque a flag g está desligada. Nenhum deles dá erro. Cada um devolve um resultado que parece certo no único exemplo que você testou, e é isso que os torna caros: você não sabe que algo está errado até o padrão encontrar dados reais.

Por que meu padrão casa com muito mais do que eu queria?

Porque * e + são gulosos. Eles pegam todos os caracteres que conseguem e os devolvem um de cada vez só até o resto do padrão conseguir casar. Rode <.*> sobre <b>hi</b> and <i>yo</i> e você obtém uma única ocorrência: a string inteira, do primeiro < ao último >. O padrão fez o que você escreveu. Você escreveu "qualquer trecho de caracteres entre um colchete e outro colchete", e o trecho mais longo possível é tudo.

Há duas correções e elas não são iguais. Um ponto de interrogação depois do quantificador o torna preguiçoso: <.*?> para no primeiro > e devolve quatro ocorrências (<b>, </b>, <i>, </i>). Uma classe negada diz o que você realmente quer dizer: <[^>]*> é "um colchete, depois qualquer coisa que não seja um colchete de fechamento, depois um colchete de fechamento". Dá as mesmas quatro ocorrências neste texto. Também é o hábito mais seguro, porque um ponto preguiçoso continua atravessando qualquer caractere de que precise, e uma classe negada não consegue.

O sinal é uma quantidade de ocorrências menor do que a esperada, com uma delas suspeitosamente longa. Cole seu texto no testador de regex e olhe o destaque: um único bloco de cor atravessando várias coisas que você queria separadas é casamento guloso, sempre.

Por que o padrão para no fim de uma linha?

Porque o ponto casa com qualquer caractere exceto uma quebra de linha. Pegue três linhas, Name: Ada, Role: Admin, Name: Grace, e o padrão Name:.*Admin. Ele não encontra nada. O texto está ali, mas o ponto não consegue pular a quebra de linha entre a primeira linha e a segunda.

Este é o que mais tempo custa porque o padrão funcionou quando você o testou em uma linha só. Você colou uma linha na caixa, obteve uma ocorrência e levou o padrão para um código que lê um arquivo inteiro. A causa habitual de "funciona no testador e não devolve nada em produção" é esta, ou a flag logo abaixo.

Há duas saídas. A flag s deixa o ponto casar com uma quebra de linha; o testador de regex tem uma caixa de seleção para isso. Ou escreva [\s\S], que significa "espaço em branco ou não espaço em branco" e portanto qualquer caractere. A ferramenta de localizar e substituir não tem uma opção s, então lá o que funciona é [\s\S].

Corrigir isso pode causar o primeiro erro. Ligue s e um Name: (.*) guloso deixa de parar no fim da sua linha: ele devolve uma única ocorrência que vai do primeiro Name: até o fim do texto, levando as outras duas linhas junto. Com o ponto confinado a uma linha, a gulodice era inofensiva. Com o ponto solto, não é, e quantificadores preguiçosos ou classes negadas passam a ser necessários no mesmo instante.

Uma armadilha relacionada são ^ e $. Sem a flag m eles significam o começo e o fim do texto inteiro, então ^Role não casa com nada no meio de um arquivo. As duas ferramentas daqui se comportam de forma diferente: o testador começa com m desligada, enquanto a ferramenta de localizar e substituir começa com "^ e $ casam em cada linha" ligada. Um padrão copiado de uma para a outra pode mudar de significado sem nenhuma edição.

Por que só a primeira ocorrência foi substituída?

Porque a flag g está desligada. Sem ela o motor para depois da primeira ocorrência, e a substituição para junto. Em JavaScript, substituir - por + em a-b-c dá a+b-c sem g e a+b+c com ela.

A armadilha é que nada parece quebrado. Em um teste de uma linha o resultado está certo. Em um documento de duas mil linhas a primeira ocorrência é corrigida e as outras 1.999 ficam intactas, e a menos que você procure depois o texto antigo, não vai ver. Quando a substituição está errada por exatamente "todas menos uma", olhe primeiro as flags.

A mesma flag tem um segundo efeito no código. Um objeto regex criado com g lembra onde terminou sua última ocorrência, em uma propriedade chamada lastIndex. Chamar .test() duas vezes com a mesma string devolve true e depois false, porque a segunda busca começa depois da primeira ocorrência. Se uma verificação passa com algumas entradas e falha com as mesmas entradas dentro de um laço, uma regex /g compartilhada é uma causa provável. Tire a flag quando você só precisa de um sim ou não. O testador deste site constrói um padrão novo a cada tecla digitada, então não consegue reproduzir isso; só aparece em código que reutiliza um.

Como eu descubro qual dos erros estou vendo?

Conte antes de ler. Calcule quantas ocorrências você espera e compare com o número que a ferramenta informa. A diferença aponta para a causa:

• Menos ocorrências do que o esperado, uma delas muito longa: quantificador guloso.
• Zero ou menos ocorrências, em um texto que ocupa várias linhas: o ponto, ou ^ e $ sem m.
• A quantidade certa de ocorrências, mas a substituição mudou só uma: g está desligada.
• A quantidade está certa e o texto claramente está lá, mas nada casa: algo no texto não é o que parece. Um espaço não separável ou uma aspa curva derrota qualquer padrão, e vale descartar os caracteres invisíveis em um texto antes de reescrever a regex.

Depois reduza o problema. Corte o texto até a menor amostra que ainda dê errado, e corte o padrão até a parte que está errada, acrescentando peças de uma em uma. Uma regex que falha inteira costuma ter uma peça que casou com algo inesperado, e você só vê qual construindo a partir do zero. Ler um padrão longo procurando o erro é mais lento do que reconstruí-lo.

Quando há uma substituição, confira também a saída e não só as ocorrências. Os erros ao localizar e substituir explica como confirmar o que de fato mudou, porque uma lista de ocorrências correta ainda pode produzir um resultado errado se a string de substituição contiver um $.

O que o testador não pega?

Alguns limites, para você não confiar em um resultado verde além do que ele alcança.

• Ele roda o motor JavaScript do seu navegador e mais nada. Lookbehind, grupos nomeados e escapes de propriedade diferem entre JavaScript, Python, PCRE e Go, então um padrão que passa aqui pode falhar em outra linguagem. Teste na linguagem em que você vai publicar.
• Ele testa os primeiros 50.000 caracteres do texto colado e lista as primeiras 50 ocorrências. Um problema que só aparece na página 80 de um log longo não vai aparecer.
• Ele não consegue parar um padrão catastrófico. Quantificadores aninhados como (a+)+$ na entrada errada podem congelar a aba, e nada consegue interromper uma expressão regular depois que ela começou. O limite de 50.000 caracteres faz a maioria dos padrões ruins terminar, e é uma mitigação, não uma garantia.
• Ele mostra o que o seu padrão faz, não se é a ferramenta certa. Analisar HTML com regex falha no próximo arquivo mesmo funcionando neste; as entidades HTML são um dos motivos de o texto não se parecer com o que você casou. O DOMParser embutido no navegador é o caminho melhor.

O padrão, o texto e a substituição são tratados pelo seu navegador. Nada é enviado, e isso importa aqui porque as pessoas testam padrões em trechos de log e registros de clientes.

Última atualização 19 de outubro de 2026