Comparação de bibliotecas de análise e processamento JSON

Resumo da ópera: classifique primeiro a necessidade e depois compare implementações — use o JSON.parse nativo para valores somente leitura, jsonc-parser quando precisar de offsets ou tiver de preservar a formatação original, e adicione bibliotecas de consulta ou patch apenas onde forem necessárias; carregue bibliotecas grandes sob demanda por página e descarte as sem manutenção.

Toda biblioteca se diz "rápida, pequena e completa". O que realmente as diferencia é quanta informação elas conseguem dar quando algo dá errado.

1. Quatro categorias por finalidade

Identifique primeiro em qual categoria você está e depois compare implementações concretas — caso contrário é fácil usar uma biblioteca de consulta para fazer o trabalho de um analisador.

2. Comparação lado a lado

As mensagens de erro do JSON.parse variam muito entre engines. O V8 produz algo como Unexpected token } in JSON at position 42, mas se a posição é precisa depende da versão da engine; jsonc-parser em vez disso retorna um { error, offset, length } estruturado e estável, adequado para marcadores de editor.

3. Quatro pontos de decisão essenciais

3.1 Você precisa de offsets

Se você está construindo um editor e quer "clicar no erro para pular para a linha correspondente", precisa ter um offset. O teste é simples: se sua mensagem de erro só consegue imprimir "JSON inválido", os usuários terão de procurar por conta própria.

复制import { parse, printParseErrorCode } from 'jsonc-parser';

const errors: Array<{ error: number; offset: number; length: number }> = [];
parse(text, errors, { allowTrailingComma: true, disallowComments: false });

if (errors.length > 0) {
  const firstError = errors[0];
  console.error(`${printParseErrorCode(firstError.error)} no offset ${firstError.offset}`);
}

3.2 Você precisa preservar o texto original

Só ler valores → qualquer analisador serve. "Mudar um campo e manter todo o resto exatamente como estava" → você precisa usar uma API no estilo de edição, não "analisar → alterar o objeto → serializar".

O último perde: comentários, ordem das chaves (em algumas implementações), estilo de indentação, notação de literais numéricos (1e3 vira 1000) e formas de escape (\u4e2d vira o caractere real).

3.3 Os comportamentos de fronteira são explícitos

Antes de escolher uma biblioteca, verifique na documentação três coisas:

1. Como as chaves duplicadas são tratadas (manter a última / gerar erro);
2. Se inteiros grandes perdem precisão (a maioria das bibliotecas JS perde, porque todas passam por Number);
3. O escopo suportado para BOM, comentários e vírgulas finais.

Se não houver documentação, escreva uma pequena amostra e teste você mesmo. Isso é mais confiável do que ler o README.

3.4 Estado de manutenção

O risco de uma biblioteca JSON não é falta de recursos, mas negligência de longo prazo: ninguém mais vai enviar patches de segurança (prototype pollution, ReDoS).

4. Comparação com outras linguagens

Ao trocar dados entre linguagens, as coisas mais fáceis de tropeçar continuam sendo precisão numérica e formatos de hora; a escolha da biblioteca só consegue mitigá-las, não eliminá-las.

5. Combinações típicas

Opção 1: site de ferramentas (lado do navegador)

复制Análise e localização de erros: jsonc-parser
Editor: CodeMirror 6 + @codemirror/lang-json
Consulta: jsonpath-plus
Patch: fast-json-patch
Links de compartilhamento: lz-string

O traço definidor desta combinação é que tudo roda localmente e nenhum dado é enviado, o que corresponde às expectativas de privacidade de um site utilitário.

Opção 2: gateway de API do servidor

复制Validação: Ajv (compilar o schema uma vez, reutilizá-lo)
Análise: JSON.parse nativo (junto com um limite de tamanho de corpo)
Análise adiada de campos grandes: guardar a string crua, analisar só quando necessário

Não introduza bibliotecas de consulta/patch na camada de gateway para implementar lógica de negócio — esse é o trabalho da camada de negócio.

Opção 3: CLI e scripts

复制Selecionar campos: jq
Conversão de formato: yq / dasel
Navegação interativa: jless
Validação em lote: ajv-cli

6. O impacto real do tamanho do bundle e do desempenho

• jsonc-parser é muito pequeno e adequado ao bundle principal;
• json5 é um pouco maior que jsonc-parser porque suporta mais sintaxe;
• jsonpath-plus inclui avaliação de expressões e é notavelmente maior, então deve ser carregado sob demanda por página;
• fast-json-patch tem tamanho médio e só é necessário quando há um recurso de comparação.

A otimização é direta: importe dinamicamente por página e não os coloque no chunk da primeira tela.

复制const { JSONPath } = await import('jsonpath-plus');

7. Lista de verificação

• [ ] Escolha bibliotecas por finalidade; não use uma biblioteca de consulta para analisar;
• [ ] Use jsonc-parser quando precisar de localizações de erro precisas;
• [ ] Use APIs no estilo de edição quando comentários e formatação precisarem ser preservados;
• [ ] Teste na prática os três comportamentos de fronteira: chaves duplicadas, inteiros grandes e BOM;
• [ ] Acompanhe o estado de manutenção e os avisos de segurança da biblioteca;
• [ ] Importe dinamicamente bibliotecas grandes sob demanda.

Perguntas frequentes

Como escolho uma biblioteca JSON conforme o tamanho do meu projeto?

Ferramentas pequenas que só leem dados de API podem continuar com o JSON.parse nativo. Projetos que precisam de localização de erros no nível de editor ou que precisam preservar a formatação original devem usar jsonc-parser. Um gateway de servidor precisa apenas de validação e análise, deixando bibliotecas de consulta e patch para a camada de negócio, enquanto scripts de CLI podem usar jq, yq e ajv-cli diretamente.

Por que o estado de manutenção importa mais do que a quantidade de recursos?

O risco real de uma biblioteca JSON é a negligência de longo prazo, não recursos faltando: ninguém vai enviar patches de segurança para prototype pollution ou ReDoS. Por mais completa que seja a lista de recursos, uma biblioteca parada deixa você mesmo a remendar. Trate manutenção e avisos de segurança como critérios rígidos em vez de comparar tabelas de recursos.

Devo usar JSON.parse para mudar um campo e manter comentários e indentação?

Não. Analisar, alterar o objeto e depois serializar perde comentários, ordem das chaves, estilo de indentação, notação de literais numéricos (1e3 vira 1000) e formas de escape (\u4e2d vira o caractere real). Mudar um campo mantendo todo o resto intacto exige uma API no estilo de edição, como modify e applyEdits do jsonc-parser.