JSON本身不美化HTML，仅作为存储HTML字符串的容器；美化需先解析JSON提取HTML字段，再用js-beautify等工具单独处理该字符串，确保转义正确并重新序列化。
JSON 格式本身不美化 HTML，但能帮美化工具更可靠地解析结构
HTML 是标签嵌套的标记语言，而 JSON 是纯数据格式；直接把 HTML 当成 JSON 解析会报错——JSON.parse() 遇到 <div> 就立刻抛 SyntaxError: Unexpected token <。所谓“HTML JSON 格式”，实际是指把 HTML 字符串作为 JSON 的某个字段值（比如 { "html": "<div class=\"box\"><p>text</p></div>" }），此时 JSON 只是容器，真正要美化的仍是里面的 HTML 字符串。
美化工具（如 js-beautify、prettier）靠的是 HTML 词法分析器和语法树重建，不是靠 JSON。但如果你的数据源是 JSON API，那 JSON 的结构一致性反而成了优势：字段名稳定、嵌套层级明确、引号/转义规则统一，比拼接字符串或 DOM 序列化更利于自动化处理。
用 js-beautify 处理 JSON 里的 HTML 字段，关键在提取与转义
常见错误是直接对整个 JSON 调用 html_beautify()，结果报错或输出乱码。正确做法是先解析 JSON，再定位 HTML 字段，最后单独美化该字段值。
- 确保 HTML 字符串在 JSON 中已正确转义：双引号用
"，反斜杠用\，换行不能裸写（应为 - 用
JSON.parse()安全读取，捕获解析失败（比如后端返回未转义的 HTML 片段） - 调用
js_beautify(htmlString, { indent_size: 2, html: { end_with_newline: true } })，注意传入的是字符串，不是对象 - 美化后若需塞回 JSON，要用
JSON.stringify()重新序列化，避免手动拼接引入新转义问题
prettier 不原生支持 HTML 字符串美化，但可通过插件或配置绕过
prettier 默认只处理文件，对运行时字符串无接口。强行用 prettier.format(htmlString, { parser: "html" }) 会失败，因为它的 parser 选项不接受字符串输入——它只认文件路径或 AST。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
可行路径只有两条：
- 写临时文件：把 HTML 字符串写入
/tmp/beautify-tmp.html，再调prettier --write命令行，读回内容（适合 Node.js CLI 场景） - 换用
prettier-plugin-xml（它兼容 HTML）+ 自定义 parser，但需额外安装、配置复杂，且对自闭合标签（如<img>）行为可能和浏览器不一致 - 更稳的选择是放弃 prettier，直接用
js-beautify或html5-parser+ 手动缩进逻辑（轻量需求下几行代码就能搞定）
线上 JSON 预览工具美化 HTML 的真实链路
像 JSON Editor Online 或 VS Code 的 JSON 插件，它们显示 HTML 字段时的“高亮+折叠”效果，根本不是美化 HTML，而是：识别字段名是否含 html、template、code 等关键词，然后启用 HTML 模式渲染该字段值的字符串内容。
这带来两个易忽略点：
- 字段名必须匹配规则（例如叫
body_html可能被识别，叫content就不会） - 它不校验 HTML 合法性——哪怕字段里是
"<div <script>alert(1)，也会原样高亮，不报错也不修复 - 这种“美化”纯属前端展示层行为，不影响原始 JSON 数据，也无法导出为格式化后的 HTML 文件
真要生成可交付的 HTML，还是得走解析 → 美化 → 序列化流程，别依赖预览工具的视觉反馈。
