HTML 中的 JSON 字符串无需美化工具处理，因其仅影响开发阶段可读性，对运行时无任何影响；美化不改变语义，也不解决编码、HTTP 响应类型等根本问题。
HTML 中的 JSON 字符串要不要用美化工具处理
不需要。HTML 本身不解析或执行 JSON，<script></script> 标签里写的 JSON 字符串只是普通文本，浏览器不会自动格式化它；美化工具（如 Prettier、JSON Formatter）只在开发阶段帮你肉眼阅读，对运行时零影响。
常见错误现象：Uncaught SyntaxError: Unexpected token —— 这往往是因为你本想 <code>fetch 一个 JSON 文件，但服务器返回了 HTML（比如 404 页面），和 JSON 是否“美化”完全无关。
- JSON 美化只改变换行、缩进、空格，不改变语义或结构
- 浏览器加载 JSON 资源（如
fetch("/data.json")）时，只认内容是否符合 JSON 语法，不管有没有缩进 - 如果把 JSON 写死在
<script></script>标签里（比如<script>const data = { "name": "a" };</script>），那它本质是 JavaScript 代码，不是 JSON 字符串，更不需要 JSON 美化
什么时候必须用 JSON.stringify() 而不是直接写 HTML 里的 JSON
当你需要把 JS 对象动态转成 JSON 字符串并插入 HTML（比如作为 data- 属性值或 <script type="application/json"></script> 内容）时，JSON.stringify() 是唯一安全方式。
直接拼接字符串或模板字面量极易出错：引号嵌套混乱、特殊字符（如换行、双引号）未转义、中文乱码等都会导致解析失败。
-
JSON.stringify(obj, null, 2)的第三个参数2控制缩进空格数，仅用于可读性，不影响功能 - 不要用
JSON.stringify()处理含函数、undefined、Date对象的原始数据——它们会被忽略或变成null - 服务端返回的 JSON 响应体无需前端再
stringify；只有前端构造 JSON 字符串塞进 HTML 时才需要
Chrome DevTools 里看到的 JSON 是“美化”过的吗
是的，但只是 DevTools 自动做的视图层处理。Network 面板点开一个 application/json 响应，右侧默认显示的是格式化后的树状视图；切换到 “Response” 标签页看到的是原始响应体（无缩进、无换行），和服务器发的一模一样。
这个“美化”不修改数据，也不影响代码行为，纯属调试便利。你写 JSON.parse(xhr.responseText) 时，传进去的始终是原始字符串。
- 如果响应头没设
Content-Type: application/json，DevTools 不会自动当 JSON 解析，也不会美化 - 某些 API 返回 JSONP 或带前缀的 JSON（如
callback({...})），DevTools 无法识别为标准 JSON，美化功能失效 - 用
console.log(JSON.stringify(obj))打印出来的也是单行字符串，除非手动加JSON.stringify(obj, null, 2)
JSON 美化工具对 HTML 文件体积和加载性能有影响吗
有，但通常可以忽略。美化后多出的空格、换行、缩进会让 JSON 字符串体积增大 10%–30%，但如果 JSON 数据本身不大（比如配置项、小列表），这点增量几乎不影响 HTTP 传输或解析速度。
真正要注意的是：别把美化后的 JSON 直接塞进 HTML 源码里长期维护。一旦数据变大（比如内嵌几百条商品信息），HTML 文件会臃肿，首屏加载变慢，且不利于缓存分离。
- 静态 JSON 数据建议单独存为
.json文件，通过fetch异步加载 - 服务端渲染场景下，如果必须内联 JSON，用
JSON.stringify()+ 最小化（不加缩进）更稳妥 - Prettier 等工具默认美化 JSON 文件，但对 HTML 中的 JSON 字符串不生效——它只处理
.json后缀文件或明确标记的代码块
最容易被忽略的一点：JSON 美化解决不了编码问题。UTF-8 BOM、服务器返回的 GBK 编码、HTML meta 声明不匹配，都可能导致 JSON 解析失败，这时候再怎么缩进也没用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
