Comparación de bibliotecas de análisis y procesamiento de JSON

En resumen: clasifica primero la necesidad y luego compara implementaciones — usa JSON.parse nativo para valores de solo lectura, jsonc-parser cuando necesites offsets o debas conservar el formato original, y añade bibliotecas de consulta o de parches solo donde haga falta; carga las bibliotecas grandes por página bajo demanda y descarta las que no tengan mantenimiento.

Todas las bibliotecas afirman ser "rápidas, pequeñas y completas". Lo que realmente las distingue es cuánta información te dan cuando algo sale mal.

1. Cuatro categorías por propósito

Identifica primero en qué categoría estás y luego compara implementaciones concretas; de lo contrario es fácil usar una biblioteca de consulta para hacer el trabajo de un parser.

2. Comparación lado a lado

Los mensajes de error de JSON.parse varían mucho entre motores. V8 produce algo como Unexpected token } in JSON at position 42, pero que la posición sea exacta depende de la versión del motor; jsonc-parser, en cambio, devuelve un { error, offset, length } estructurado y estable, adecuado para marcadores de editor.

3. Cuatro puntos clave de decisión

3.1 ¿Necesitas offsets

Si estás construyendo un editor y quieres "haz clic en el error para saltar a la línea correspondiente", necesitas un offset. La prueba es simple: si tu mensaje de error solo puede imprimir "invalid JSON", los usuarios tendrán que buscarlo ellos mismos.

复制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)} at offset ${firstError.offset}`);
}

3.2 ¿Necesitas conservar el texto original

Solo leer valores → cualquier parser sirve. "Cambiar un campo y mantener todo lo demás exactamente como estaba" → debes usar una API de edición, no "parsear → cambiar el objeto → serializar".

Esto último pierde: comentarios, orden de claves (en algunas implementaciones), estilo de indentación, notación de literales numéricos (1e3 se convierte en 1000) y formas de escape (\u4e2d se convierte en el carácter real).

3.3 ¿Están explícitos los comportamientos límite

Antes de elegir una biblioteca, revisa la documentación en busca de tres cosas:

1. Cómo se manejan las claves duplicadas (conservar la última / lanzar un error);
2. Si los enteros grandes pierden precisión (la mayoría de las bibliotecas JS sí, porque todas pasan por Number);
3. El alcance soportado para BOM, comentarios y comas finales.

Si no hay documentación, escribe una pequeña muestra y pruébala tú mismo. Eso es más fiable que leer el README.

3.4 Estado de mantenimiento

El riesgo de una biblioteca JSON no es que le falten funciones, sino el abandono prolongado: ya nadie publicará parches de seguridad (contaminación de prototipos, ReDoS).

4. Comparación con otros lenguajes

Al intercambiar datos entre lenguajes, lo más fácil de tropezar siguen siendo la precisión numérica y los formatos de hora; elegir biblioteca solo puede mitigarlo, no eliminarlo.

5. Combinaciones típicas

Opción 1: Sitio de herramientas (lado navegador)

复制Parsing and error location: jsonc-parser
Editor: CodeMirror 6 + @codemirror/lang-json
Query: jsonpath-plus
Patch: fast-json-patch
Share links: lz-string

El rasgo distintivo de esta combinación es que todo se ejecuta localmente y no se sube ningún dato, lo que encaja con las expectativas de privacidad de un sitio de herramientas.

Opción 2: Gateway de API en el servidor

复制Validation: Ajv (compile the schema once, reuse it)
Parsing: native JSON.parse (together with a body size limit)
Deferred parsing of large fields: keep the raw string, parse only when needed

No introduzcas bibliotecas de consulta o de parches en la capa de gateway para implementar lógica de negocio; eso es trabajo de la capa de negocio.

Opción 3: CLI y scripts

复制Pick fields: jq
Format conversion: yq / dasel
Interactive browsing: jless
Batch validation: ajv-cli

6. El impacto real del tamaño del bundle y el rendimiento

• jsonc-parser es muy pequeño y adecuado para el bundle principal;
• json5 es algo más grande que jsonc-parser porque soporta más sintaxis;
• jsonpath-plus incluye evaluación de expresiones y es notablemente más grande, así que debe cargarse por página bajo demanda;
• fast-json-patch es de tamaño medio y solo se necesita cuando tienes una función de comparación.

La optimización es directa: importación dinámica por página, y no los pongas en el chunk de la primera pantalla.

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

7. Lista de comprobación

• [ ] Elegir bibliotecas por propósito; no usar una biblioteca de consulta para parsear;
• [ ] Usar jsonc-parser cuando necesites localizaciones de error precisas;
• [ ] Usar APIs de edición cuando haya que conservar comentarios y formato;
• [ ] Probar en la práctica los tres comportamientos límite: claves duplicadas, enteros grandes y BOM;
• [ ] Vigilar el estado de mantenimiento de la biblioteca y sus avisos de seguridad;
• [ ] Importar dinámicamente las bibliotecas grandes bajo demanda.

FAQ

¿Cómo elijo una biblioteca JSON según el tamaño de mi proyecto?

Las herramientas pequeñas que solo leen datos de API pueden quedarse con JSON.parse nativo. Los proyectos que necesitan localizaciones de error de nivel editor o que deben conservar el formato original deberían usar jsonc-parser. Un gateway en el servidor solo necesita validación y parseo, dejando las bibliotecas de consulta y parches a la capa de negocio, mientras que los scripts de CLI pueden usar jq, yq y ajv-cli directamente.

¿Por qué importa más el estado de mantenimiento que el número de funciones?

El riesgo real de una biblioteca JSON es el abandono prolongado, no que le falten funciones: nadie publicará parches de seguridad para contaminación de prototipos o ReDoS. Por completa que sea la lista de funciones, una biblioteca estancada te deja parchearla tú mismo. Trata el mantenimiento y los avisos de seguridad como criterios duros en lugar de comparar tablas de funciones.

¿Debo usar JSON.parse para cambiar un campo y conservar comentarios e indentación?

No. Parsear, cambiar el objeto y luego serializar pierde comentarios, orden de claves, estilo de indentación, notación de literales numéricos (1e3 se convierte en 1000) y formas de escape (\u4e2d se convierte en el carácter real). Cambiar un campo manteniendo todo lo demás intacto requiere una API de edición como modify y applyEdits de jsonc-parser.