JS 压缩工具
使用 Terser——主流构建工具都在用的同一个引擎——压缩 JavaScript。去除空白和注释，并可选择混淆变量名，完全在你的浏览器中生成更小、依然有效的输出。
- 文件永不离开你的设备
- 免费，无需注册
- 无水印
- 加载后可离线使用
如何JS 压缩工具
- 1
粘贴你的代码
拖入任意有效的 JavaScript 文件或代码片段。
- 2
选择你的选项
保持变量名混淆开启以获得最小的输出，或者关掉它，如果你需要读懂结果的话。
- 3
复制结果
复制压缩后的代码，以及节省的体积。
代码压缩到底在底层做了什么
去除空白和注释是压缩里显而易见、也最简单的一部分——单靠这一步，对写得规范的代码来说几乎起不到多大作用。真正的体积缩减来自两项更深层的转换：一是混淆，把每一个局部变量和函数参数重命名为尽可能短的标识符（`accumulator` 变成 `a`，`temporaryResult` 变成 `t`）；二是死代码消除，去掉那些经过静态分析可以证明永远不会执行、或者永远不会影响输出的分支和表达式。这两者都需要真正理解代码的结构——它的作用域、哪些名字是局部的哪些是导出的、哪些分支是可证明地不可达的——这正是为什么一个像 Terser 这样基于真正解析器的工具，产出的输出比单纯对空白做查找替换要小得多、有意义得多。
为什么大多数开发者如今很少直接接触独立的压缩工具
Webpack、esbuild、Rollup 和 Vite 这类打包工具，会在生产构建过程中自动压缩输出，几乎总是在底层使用 Terser 或一个兼容 Terser 的引擎——所以对于任何在现代 JavaScript 项目里工作的人来说，压缩早已在每次运行构建命令时不知不觉地发生了。像这样一个独立工具，覆盖的是落在那套流程之外的情况：一个没有构建步骤的单独 script 标签，快速查看一段代码能缩小多少，或者一份不想为了这一件事专门配置整套打包工具的一次性文件。
格式化的逆操作，而不是它的替代品
压缩和格式化是同一份代码上相反的两种操作：这个工具去掉的，正是像 Prettier 这样的格式化工具刻意添加回去的空白、结构和可读性。它的姊妹工具 JavaScript 格式化工具，做的正好是相反的事——对于把别人交给你的一份压缩文件，重新变回一份足以真正用来调试的可读代码，这个方向就很有用。
一套真正的构建流程通常会把压缩和一份 source map 配对使用——这是一个单独的文件，把压缩输出里的每一个位置，映射回源代码里对应的原始行，专门是为了让调试器即使在运行的文件本身不可读的情况下，也能在生产环境里显示可读的代码和正确的行号。这个独立工具刻意不生成 source map，因为它是为了一次快速的一次性压缩而设计的，而不是为了生产部署；任何要进入真正构建流程的代码，都应该经过一个能同时输出配套 source map 的打包工具。
常见问题
我的代码会被发送到服务器吗？
不会。Terser 会被下载到你的浏览器并在那里运行——压缩完全在你的设备上完成。专有或内部代码永远不会离开你的机器，这一点并不是每个在线压缩工具都能做到的。
压缩会破坏我的代码吗？
在正常使用下不会——Terser 把你的代码解析成一棵真正的语法树，而不是对文本做模式匹配，所以转换后的输出对绝大多数代码而言，行为和原始代码完全一致。真正的边缘情况只有一种：在运行时检查自身源代码的代码，比如对一个函数调用 `Function.prototype.toString()` 并解析结果，或者依赖某个变量或函数名作为字符串（一些依赖注入模式会这样做）。混淆会重命名各种标识符，所以这类自我检查代码在压缩后可能会看到不同的名字。这种情况很少见，但如果你的代码用到了什么不寻常的反射手段，值得留意。
压缩后的输出依然是有效的、可运行的 JavaScript 吗？
是的。输出是普通的 JavaScript——只是更短。你可以把它直接放进一个 `<script>` 标签，或者原样放进构建产物里，就像使用原始文件一样。
什么时候真的应该用这个工具？
用于生产环境的打包文件、嵌入某个体积受限场景的脚本（浏览器扩展、埋点代码、有大小限制的小组件），或者需要快速缩小、又不想搭建一整套构建流程的一次性文件。不应该压缩你的源代码或开发文件——保持它们可读，只压缩最终的构建产物，就像一个打包工具会做的那样。
为什么输出的代码看起来完全无法阅读？
这正是它的意义所在。空白、注释和长变量名的存在，是为了方便阅读源代码的人，而不是为了执行代码的 JavaScript 引擎。去掉它们（如果开启混淆，再缩短名字），能在不改变代码行为的前提下，减少通过网络发送的字节数。