JavaScript 压缩器

JavaScript 压缩工具做的事情，其实非常具体：在不改变脚本运行行为的前提下，把同一段代码改写成尽可能短的文本。它删掉解析器并不需要的换行和空格、去掉注释，并在原本依赖换行的“隐式分号”位置补上显式分号，让代码在传输、内联和缓存时占的字节数更少。压缩前后，脚本输入相同时应该输出相同；变化的只是文件大小，而不是语义。

轻量压缩与打包器深度优化的区别

现实里被叫做“压缩”的其实是两类完全不同的工具。一类是“轻量级”的：只动空白和注释，行为可证、风险极低，适用于任何片段，包括含有 `eval`、模板字符串、特殊字符串边界的代码。另一类是 Terser、esbuild、SWC 这样的“深度优化器”：它们除了删空白，还会重命名变量、剔除死分支、内联函数。这类优化需要一个完整可信的模块作为输入，否则容易在边界处误改。理解工具属于哪一类，是评估压缩结果时最先要做的事。

哪些字符可以删，哪些是“承重”的

JavaScript 大部分位置对空白都是宽容的，但确实有几个地方，空格和换行直接影响语义。任何认真写出来的压缩工具，都是在严格识别“哪些空白可以删、哪些不能删”的基础上工作的。

• 可以删的：表达式或语句内部、两侧 token 已经能自行区分的空白，例如 `a + b` 可以压成 `a+b`。
• 可以删的：独立注释、空行、纯粹为人服务的缩进。
• 承重的：`return` 和后续表达式如果在同一行，它们之间的空格不可缺，否则 ASI（自动分号插入）的结果会变。
• 承重的：字符串字面量、模板字符串、正则字面量里的每一个字符。这些是用户数据，不属于排版。
• 承重的：紧跟在以 `(`、`[`、`/`、`+`、`-` 开头的新语句前的换行，否则前一行可能被解析器误判为继续上一行。

一句话原则：如果删掉某个空格或换行会改变解析器的分词结果，那它就是“承重字符”，必须保留——即便看上去和普通空白完全一样。

如何使用这个工具

1. 先在 JavaScript 压缩器 中准备一份有代表性的需要更紧凑输出的 JavaScript 片段、辅助函数和内联脚本，不要一开始就处理最大或最敏感的真实内容。
2. 执行处理流程并生成更小、更适合嵌入的压缩 JavaScript 文本后，优先检查字符串、注释、分号边界、正则字面量，以及输出是否仍适合目标运行时，再判断结果是否真的可用。
3. 只有当结果已经适合用于内联嵌入、快速构建准备、片段分享和紧凑脚本交接，并且不再触发这条风险提醒时，才复制或下载输出：压缩后的 JavaScript 更难审，所以进入生产前应先以可读版本完成复核。

JavaScript 压缩器 示例

这个 JavaScript 压缩器 示例使用有代表性的需要更紧凑输出的 JavaScript 片段、辅助函数和内联脚本，展示生成后的更小、更适合嵌入的压缩 JavaScript 文本，便于你先确认字符串、注释、分号边界、正则字面量，以及输出是否仍适合目标运行时，再把同样设置用于真实输入。

示例输入

function add(a, b) { return a + b; }

预期输出

function add(a,b){return a+b}

一次安全压缩前后的代码

// 压缩前
function greet(name) {
  // 没有传名字时用一个回退值
  const safe = name || "friend";
  return "Hello, " + safe + "!";
}

// 压缩后
function greet(name){const safe=name||"friend";return"Hello, "+safe+"!"}

什么时候适合做这种轻量压缩

这种“只动空白”的轻量压缩，最适合那些不能或者不需要引入完整打包链路的场景。在以下这些情境里，它的安全性和易用性比深度优化更重要。

• 嵌入在 HTML 邮件、营销落地页、静态模板中的内联脚本：脚本字节随页面一起发出去，压缩直接带来传输收益。
• 存放在 CMS 或标签管理系统里的脚本片段：每条记录都自带一份，临时改动也很频繁，体积小一些每次加载都会更顺。
• 在聊天、工单、文档里分享 JavaScript 片段：紧凑形式比十几行缩进版本更容易快速阅读。
• 在决定“是把它写进内联，还是抽到外部文件”之前，先用压缩看看真实体积有多大，给体积预算一个参考。
• 为博客、幻灯片、演示文稿生成紧凑的代码示例：目标是短小好放，不是极致优化。

轻量压缩特别容易踩的坑

“只动空白”的压缩出问题，往往不在算法本身，而在原始代码依赖了一些压缩工具看不见的上下文。下面这些类别，是当你看到“源代码没事，压缩版崩了”时最值得先怀疑的。

• ASI 自动分号插入：`return` 单独占一行、后面的 `{` 在下一行，等价于 `return undefined;`，不是 `return { ... }`。压缩工具如果把它们合并到一行，就改变了行为。这类问题在调试器里几乎看不到，必须靠代码风格规避。
• 许可证或编译器注解：例如 `/*! ... */`、`// @license`、`/*#__PURE__*/` 这类注释具有法律或编译器层面的含义。一个合格的压缩工具会按惯例保留它们。
• 模板字符串：反引号字符串里的换行是值的一部分，不能当作排版处理。压缩工具不能动反引号内部的任何字符。
• 紧邻除法的正则字面量：`a / b / c` 和 `a / b /c/.test(x)` 形态相似但分词完全不同，`/` 周围的换行或空格有时正是消除歧义的关键。
• 依赖 Source Map 进行线上排错的脚本：激进压缩但不生成 Source Map，会让线上报错的定位代价显著上升。生产链路里建议把这一步交给会同时产出 Source Map 的工具。

轻量压缩与深度优化的对照

使用注意

• 复用更小、更适合嵌入的压缩 JavaScript 文本前，先检查字符串、注释、分号边界、正则字面量，以及输出是否仍适合目标运行时。
• 压缩后的 JavaScript 更难审，所以进入生产前应先以可读版本完成复核。
• 当结果会影响生产工作或客户可见内容时，应保留原始需要更紧凑输出的 JavaScript 片段、辅助函数和内联脚本以便回退和核对。

JavaScript 压缩器 参考说明

JavaScript 压缩器 的参考说明应始终围绕需要更紧凑输出的 JavaScript 片段、辅助函数和内联脚本、生成的更小、更适合嵌入的压缩 JavaScript 文本，以及用于内联嵌入、快速构建准备、片段分享和紧凑脚本交接前必须确认的检查点。

• 输入重点：需要更紧凑输出的 JavaScript 片段、辅助函数和内联脚本。
• 输出重点：更小、更适合嵌入的压缩 JavaScript 文本。
• 复核重点：字符串、注释、分号边界、正则字面量，以及输出是否仍适合目标运行时。

参考资料

• ECMAScript Language Specification
• MDN: JavaScript reference