json.stringify(obj, null, 2) 不够用，因仅支持合法js对象，无法处理注释、单引号、尾逗号、非法字符等常见粘贴错误；需结合预处理、json5解析、安全校验与分片解析等策略提升容错性与性能。
直接用 JSON.stringify() 配合缩进参数就能实现基础格式化，但要做出真正可用的在线工具，关键不在“能不能”，而在“容错性”和“边界处理”——比如输入非法 JSON、超大文本、循环引用、注释干扰等场景，浏览器原生 API 会直接抛错或静默失败。
为什么 JSON.stringify(obj, null, 2) 不够用
它只对合法 JavaScript 对象有效，而用户粘贴的往往是带单引号、尾逗号、注释、undefined 或 NaN 的“类 JSON”字符串。一旦调用 JSON.parse() 失败，整个流程就中断了。
- 用户常粘贴含
// 注释或/* ... */的配置片段，原生JSON.parse()直接报SyntaxError: Unexpected token - 输入
{a: 1}（键无双引号）会被拒绝，但很多编辑器实际支持这种写法 - 空字符串、
null、undefined输入时，JSON.stringify()可能返回"null"或空字符串，而非报错提示 - 不处理编码问题：UTF-8 BOM、控制字符（如
\u0000）会导致解析卡死或显示异常
如何安全地 parse 并保留原始结构信息
不能跳过 JSON.parse()，但必须包裹 try/catch，并在失败后尝试轻量预处理——不是全量兼容 JSON5，而是针对高频误粘贴场景做修复。
- 先用正则粗略检测是否含
//或/*，若有，用json5库（轻量，仅 3KB）替代原生解析，它支持注释、单引号、尾逗号 - 对纯字符串输入，先 trim()，再判断是否以
{或[开头，避免把"{...}"当作字符串二次 JSON 化 - 捕获
SyntaxError后，提取error.message中的行号和列号（如Unexpected token a in JSON at position 123），定位到原始字符串位置并高亮显示 - 禁止解析含
__proto__、constructor等原型污染关键词的输入，防止 XSS 风险（即使只是本地运行）
格式化输出时怎么兼顾可读性与准确性
JSON.stringify() 的第三个参数只控制缩进宽度，无法解决长数组截断、日期转字符串、BigInt 报错等问题。真实工具需主动干预序列化过程。
- 用
JSON.stringify(obj, (key, value) => { ... }, 2)的 replacer 函数统一处理：Date→toISOString()，BigInt→.toString()，undefined→null（或过滤掉） - 对长度 > 100 的数组或对象，添加折叠逻辑：只展开前 5 项，其余用
"... (95 more)"占位，避免页面卡死 - 输出 HTML 时，必须对
&、、<code>>做实体转义，否则用户输入{"html": "<div>"} 会导致 DOM 解析错乱<li>启用 <code>white-space: pre-wrap+tab-size: 2CSS，确保缩进对齐且换行正常，不用 - 小于 100KB：直接在主线程处理，加防抖（
setTimeout延迟 300ms），避免每敲一个字符都触发解析 - 100KB–5MB：用
requestIdleCallback()分片解析，每次最多处理 100 行，留出渲染余量 - 大于 5MB：强制移交 Web Worker，主线程只显示“解析中…（可能需要几秒）”，并提供取消按钮（通过
AbortController中断 Worker） - 所有解析结果必须带校验哈希（如
crc32(input)），防止因缓存或状态残留导致“显示旧内容”错觉
用户粘贴后立即响应，但别假死
超过 1MB 的 JSON 字符串会让主线程阻塞数秒，用户看到的是“没反应”，不是“正在处理”。必须拆解为微任务或 Web Worker。
最易被忽略的点是：用户复制格式化后的 JSON 再粘贴回来时，可能带不可见的 Unicode 空格（如 \u200b）或富文本换行符（\r\n 混杂 \n）。这类字符不会影响 JSON.parse()，但会让 diff 工具误判差异——所以输入框的 value 必须经过 .replace(/[\u200b-\u200f\u202a-\u202f\u2066-\u206f]/g, '') 清理。
