关于 JavaScript 格式化工具
JavaScript 格式化工具帮助你美化或压缩 JS 代码，基于词法分析器逐 token 解析，正确处理函数声明与表达式、箭头函数、for 和 while 循环、if 与 else 条件分支、模板字面量、解构赋值、async 与 await、class 类定义和正则表达式字面量。提供 2 空格、4 空格和 Tab 缩进选项，美化与压缩模式一键切换，压缩模式移除注释和多余空白。正确处理可选链和空值合并等 ES2020 语法，也适用于 TypeScript 类型注解的格式化场景。js 脚本、配置文件和压缩生产环境代码。例如把压缩的 JavaScript 代码按语句与作用域缩进重排，并高亮语法，便于定位报错位置。格式化的另一个典型用途是统一团队代码风格：接入 ESLint 之前先用本工具把历史遗留的压缩/混乱代码规整成一致缩进，能让 diff 更干净、review 更高效。
自动分号插入机制是这类语言里最容易被格式化影响行为的地方，理解它才能避免把格式化变成改 bug。在特定换行位置，解析器会自动补上分号，而补的位置可能与作者意图不同；因此把一行拆成两行、或把某段内容挪到下一行，都可能改变程序的实际语义。因此格式化工具应当以「不改变行为」为前提，遇到这类位置应保持原样或补上显式分号。
换行在少数关键字之后会产生语义差异，这是另一个必须小心处理的位置。当关键字与后续表达式之间出现换行时，解析器可能按自动插入规则提前结束语句，导致返回值或表达式与预期完全不同。因此在整理这类结构时，应当把关键字与其表达式保持在同一行，或显式使用括号与分号把结构写清。
逗号与括号的放置方式会影响解析，这一点在函数参数与数组、对象字面量里都存在。若把逗号放在行首，虽然多数场景下可以解析，但在某些位置会与自动插入规则交互而产生意外结果；而括号若被拆到独立行，也可能被当作独立的表达式容器。因此保守的做法是保持逗号在同一行末尾，并把左括号留在前一行。
注释的保留方式决定了格式化后的代码是否仍然可用，因为部分注释承载着功能性作用。有些注释被工具读取并据此生成代码或改变行为，若格式化时被挪动位置或合并，功能会静默失效；而注释里的格式示例也可能被缩进破坏。因此格式化时应当保留注释位置，尤其是不应把注释从紧邻的语句上方移走。
现代语法特性会给格式化带来额外复杂度，因为它们往往有超出标准语法的规则。模板语法与组件标记混排时缩进规则与普通代码不同，装饰器与类的组合也有特定位置要求，而实验性语法在不同工具支持程度上差异很大。因此面对这类文件时应当选用明确支持该语法的格式化实现，而不是通用解析器。
最后，格式化与语义修复应当分开处理，这是最容易混淆的一对概念。格式化只应改变空白与换行，不应替你补上或删除分号、改变比较运算符或调整表达式求值顺序；一旦格式化工具做了这些，就说明它同时在做代码改写。因此在采用某个工具前，应当先用一段带边界情况的代码验证它是否只动格式。
实现原理
格式化按语法树重排，因此它必须真正解析代码而不是按行处理。这带来的好处是能顺带发现语法错误；代价是自动插入分号（ASI）这类规则会让「去掉换行」改变语义——以 return、throw 等关键字开头的行合并到上一行时，返回值会变成空。格式化前应确认没有依赖换行的写法。
return
{a: 1}保持换行 → 返回 undefined｜合并为一行 → 返回 {a:1}（分号插入规则导致语义不同）本页实测数据
| 修复：行注释吞掉下一行 | // keep me 后不换行，紧跟的 const x = 1; 被拼成 `// keep meconst x = 1;`——**整行语句被注释掉**，而 node --check 依然通过（注释合法），所以这种破坏极难被发现。现在行注释独占一行 |
|---|---|
| 语法有效 | 4 组输出全部通过 node --check，格式化后代码仍可解析 |
| 字面量保真 | 模板字符串 `${1 + 2}`、正则字面量 /a\/b/g 原样保留，没有被转义或拆分 |
| 注释保留 | 行注释与块注释内容不丢，块注释保持原位 |
格式化器的最高优先级是不改变语义，而语义破坏常常不会报错——本页这 1 处缺陷正属此类：行注释后少一个换行，下一行代码就被并进注释里，node --check 仍然通过，运行时却少执行一条语句。这类问题只能靠行为对照发现（格式化前后各跑一次、比较输出），单纯看代码是否「好看」查不出来。另外提醒：本页是轻量美化器而非完整解析器，走 token 扫描 + 缩进重组，对 JSX、装饰器、可选链之类新语法只做保守处理，遇到复杂代码建议用 Prettier 这类完整实现。
使用方法
- 打开「JavaScript 格式化工具」
- 选择源格式与目标格式
- 根据需要调整输出选项
- 点击「转换」按钮，结果实时显示
- 复制或导出结果
使用场景
- 函数/作用域整理 — 把压缩 JS 按函数与作用域层次展开，配合清晰缩进，让闭包和回调链一览无余。
- 项目规范 — 统一项目中 JS 代码的缩进和格式风格，减少 review 时的格式噪声。
- 代码审查 — 在审查前格式化 JS 代码，使逻辑结构和变更更清晰。
- 压缩生产代码 — 一键转压缩模式，移除注释与空白，生成体积更小的产物。
- 调试压缩脚本 — 把 CDN 上下载的一行压缩脚本还原为可读结构，快速定位报错点。
常见问题
格式化会改变代码逻辑吗？
不会。格式化只调整缩进和换行，不会改变 JavaScript 代码的执行逻辑，也不重命名变量或改动代码结构。
支持 ES6+ 语法吗？
支持。正确处理箭头函数、模板字面量、解构赋值、async/await、可选链、空值合并等 ES6+ 乃至 ES2023 语法。
支持压缩模式吗？
支持。切换到压缩模式可以移除注释和多余空格，生成最小化的 JS 代码，适合放生产构建产物。
支持正则表达式字面量吗？
支持。词法分析器能正确区分除法运算符和正则字面量，不会把 /regex/ 误当作除法而破坏格式。
能否处理 TypeScript 代码？
可以。对于类型注解等 TS 语法结构能够正确排版缩进，作为格式化前的基础规整是够用的。
压缩后会改变语义吗？
不会改变执行结果。压缩仅移除注释、空白和换行，变量名与逻辑保持不变；如需更激进的最小化（改名），请用专业的构建混淆工具。
格式化后代码行为变了（比如返回值多了分号）？
安全格式化不改变语义；若出现行为差异，几乎都源于「自动分号插入（ASI）」的边界：原来依赖 return 后换行的写法被合并成一行。格式化前先跑测试，格式化后 diff 一遍 —— 这是唯一可靠的验证方式，工具无法替你判断意图。
压缩过的单行代码能格式化吗？
可以，这正是它的主要用途之一。压缩代码（minified）没有换行与注释，格式化后会恢复成可读的多行结构，变量名仍是混淆后的短名（a、b、c），因为改名需要作用域分析，属于反混淆的范畴。