Como corrigir YAML inválido

Comece pela indentação

YAML usa espaços para definir hierarquia. Não misture tabulações e espaços, e mantenha itens irmãos no mesmo nível.

Uma chave filha deve ficar mais recuada que a chave pai. Em listas, alinhe o hífen com os demais itens do mesmo nível.

Revise dois-pontos, hífens e aspas

Depois de uma chave, use um espaço após os dois-pontos. Coloque entre aspas textos que começam com caracteres especiais ou que possam ser interpretados como booleanos, datas ou números.

Se o erro apontar para o início de uma linha, verifique também a anterior: uma aspa aberta ou um bloco desalinhado pode deslocar a indicação.

Valide antes de converter

Não repare o documento por suposição. Corrija o primeiro erro, analise novamente e confirme que a árvore mantém a estrutura pretendida.

Depois, converta para JSON e confira especialmente tipos escalares e listas aninhadas.

Fluxo confiável passo a passo

Trate YAML inválido como uma transformação de dados com entrada, estrutura esperada e destino definidos. Trabalhe em uma cópia, valide antes de mudar a representação e isole uma amostra mínima. Isso separa falhas de sintaxe de problemas do modelo de dados ou da aplicação.

Faça uma alteração por vez e repita a mesma validação. Em pipelines automatizados, interrompa o processo diante de um erro do analisador, em vez de publicar um resultado parcial ou presumido. Preserve a entrada original junto do artefato gerado quando precisar de rastreabilidade.

• Corrija primeiro o primeiro erro informado; uma única aspa ausente pode gerar vários avisos secundários.
• Reduza um documento grande ao menor trecho que ainda falha, preservando o aninhamento ao redor do erro.
• Depois que a sintaxe passar, confira chaves obrigatórias, tipos, limites e regras específicas da aplicação.

Exemplo prático e verificação

O exemplo abaixo é pequeno de propósito para permitir inspeção visual. Aplique o mesmo método a um documento real: confirme cada chave, tipo escalar, ordem de lista e limite de aninhamento antes de aceitar a saída.

Uma conversão ou minificação concluída só comprova que a entrada pôde ser analisada. Compare o valor estruturado antes e depois e carregue o resultado com a mesma biblioteca ou plataforma que o consumirá em produção.

service:
  name: api
  retries: 3
  enabled: true

Limites e casos especiais

Os casos difíceis de YAML inválido geralmente surgem quando validade sintática é confundida com validade para a aplicação. Um analisador pode aceitar dados incompletos, ambíguos, grandes demais ou incompatíveis com o esquema de destino.

Não corrija nem normalize às cegas um documento desconhecido. Chaves duplicadas, tipos implícitos, aliases, precisão numérica, Unicode, finais de linha e entradas enormes exigem uma política explícita. Se o destino tiver regras mais rígidas, elas prevalecem.

Checklist para produção

Antes de publicar, teste um documento normal, um valor vazio, dados muito aninhados, texto não ASCII e um exemplo malformado. Registre a versão da ferramenta ou biblioteca se outro sistema precisar reproduzir exatamente a saída.

Inclua a validação no CI quando os dados afetarem builds, implantações, APIs ou configuração. Revise diferenças, mantenha uma cópia para reversão e monitore o primeiro consumidor após a implantação.

• Corrija primeiro o primeiro erro informado; uma única aspa ausente pode gerar vários avisos secundários.
• Reduza um documento grande ao menor trecho que ainda falha, preservando o aninhamento ao redor do erro.
• Depois que a sintaxe passar, confira chaves obrigatórias, tipos, limites e regras específicas da aplicação.