前端项目上线前，JavaScript代码压缩几乎是必做的工序。一份未压缩的JS文件里充满了注释、换行、空格以及冗长的变量名，这些内容对浏览器执行毫无帮助，却会显著增加文件体积和网络传输时间。UglifyJS是这个领域里最经典的工具之一，它不仅做“去空格”这种表面压缩，还能进行语法层面的等价变换，把代码压缩到接近手工极限的程度。本文围绕Node.js环境，讲解UglifyJS的压缩原理、命令行用法、API调用方式以及常见踩坑点。
UglifyJS的压缩原理是什么
UglifyJS内部实现了一个完整的JavaScript解析器，它先把源码解析成抽象语法树（AST），然后在AST上执行一系列优化变换，最后再重新生成代码。理解这个过程，才能明白它为什么能做很多文本替换工具做不到的事情。
解析阶段会严格按照语言语法构建语法树，每个变量声明、函数调用、运算表达式都成为树上的一个节点。压缩阶段主要包含两类操作：一类是compress，即代码优化，比如删除永远为假的条件分支、把if (a) { b(); }简化成a && b()、常量折叠（直接算出1 + 2的结果）、内联单次使用的变量等；另一类是mangle，即名称压缩，把局部变量和函数名替换成a、b、c这样的短名称，这部分对体积的缩减往往非常可观。
最后输出阶段会重新拼接代码，去掉所有不必要的分号、括号和换行。一个几十KB的文件经过完整压缩后，体积通常能减少50%以上。需要注意的是，mangle默认只会处理局部作用域内的变量，不会碰全局变量和属性名，这也是它能安全运行的前提。如果强行开启属性名混淆，就需要评估代码中是否存在字符串动态访问属性的情况，否则很容易在运行时报错。
命令行方式压缩JS文件
最直接的用法是全局安装后通过命令行调用。先执行npm install -g uglify-js完成安装，注意包名是uglify-js而不是uglifyjs，这是新手常犯的错误。安装完成后就可以使用uglifyjs命令了。
uglifyjs src/app.js -o dist/app.min.js -c -m # -c 开启compress压缩，等价于 --compress # -m 开启mangle变量名混淆，等价于 --mangle # -o 指定输出文件路径
如果需要压缩多个文件并合并成一个文件，直接把多个输入文件依次写在前面即可，UglifyJS会按顺序拼接后再统一压缩，依赖顺序由你自己保证。还可以通过--source-map参数生成source map文件，方便线上报错时定位回源码。
uglifyjs src/a.js src/b.js -o dist/bundle.min.js -c -m \ --source-map "filename='dist/bundle.min.js.map',root='src',url='bundle.min.js.map'"
这里有个容易被忽略的细节：末尾添加//# sourceMappingURL注释是url参数决定的，如果不写url，输出的压缩文件不会引用map文件，需要在浏览器调试时手动加载。另外，如果源码中包含箭头函数、let/const等ES6语法，原版UglifyJS会直接解析失败，因为它只支持ES5语法，ES6及以上的代码需要先经过Babel或swc转译，或者改用支持ES6的terser。
通过Node.js API编写自动化压缩脚本
当压缩任务需要集成到构建流程中，或者要根据文件大小、修改时间做条件处理时，命令行就不够灵活了，这时候用API方式更合适。UglifyJS暴露了minify函数，接收代码字符串或文件数组，返回一个Promise。
const UglifyJS = require('uglify-js');
const fs = require('fs');
const path = require('path');
const srcDir = path.join(__dirname, 'src');
const distDir = path.join(__dirname, 'dist');
// 遍历目录批量压缩所有js文件
const files = fs.readdirSync(srcDir).filter(f => f.endsWith('.js'));
files.forEach(file => {
const result = UglifyJS.minify(fs.readFileSync(path.join(srcDir, file), 'utf8'), {
compress: {
dead_code: true, // 删除不可达代码
drop_console: true, // 移除console语句
drop_debugger: true // 移除debugger语句
},
mangle: true,
output: {
comments: false // 删除所有注释
}
});
if (result.error) {
console.error(`压缩 ${file} 失败:`, result.error);
return;
}
fs.writeFileSync(path.join(distDir, file.replace('.js', '.min.js')), result.code);
console.log(`已压缩: ${file}`);
});配置对象的结构和命令行参数是一一对应的。compress.drop_console在生产环境特别有用，能一次性去掉所有调试输出，避免手动维护删除逻辑。output.comments设为false会删掉全部注释，如果想保留版权声明，可以传一个函数，函数返回true的注释会被保留。
错误处理是API方式的优势所在。命令行遇到语法错误会直接中断整个流程，而API方式下result.error会包含出错的文件名、行号和错误信息，你可以选择跳过问题文件继续处理其余部分，或者收集所有错误一次性上报。这在批量处理遗留代码时非常实用。
常见问题与踩坑记录
第一个坑是保留特定变量名。有些变量被外部脚本引用，混淆后会导致引用失效，比如jQuery插件里的jQuery、$。mangle提供了reserved数组来排除这些名称：
UglifyJS.minify(code, {
mangle: {
reserved: ['jQuery', '$', 'myGlobalAPI']
}
});第二个坑是eval和with。如果压缩的代码中使用了eval，mangle必须格外小心，因为eval内的字符串可能引用外部变量名，一旦变量被改名就会出错。compress选项中有一个unsafe开关，能做一些更激进的变换，但正如名字暗示的那样，非必要不要开启，除非你对代码行为有充分把握并在压缩后做过完整回归测试。
第三个坑是性能。UglifyJS是纯JavaScript实现的，压缩速度不如后来出现的esbuild、swc这类基于原生编译的工具。小型项目感觉不到差别，但项目体积达到数MB时，压缩耗时可能从几百毫秒膨胀到十几秒。如果构建速度成为瓶颈，可以考虑把压缩环节替换为terser（UglifyJS的维护分支，支持ES6+），或直接使用内置压缩的现代打包器。不过对于只需处理ES5代码的存量系统来说，UglifyJS依然稳定可靠，配置简单，依赖极少。
总的来说，UglifyJS把AST分析、等价变换和名称混淆组合成了一套完整的压缩流水线，命令行适合快速处理单个文件，API适合嵌入构建脚本做批量自动化。掌握compress和mangle两组参数的含义，再配合source map做好线上问题排查，就能把代码压缩安全地纳入日常发布流程。