js压缩工具怎么用：从代码压缩到文件体积检查

JavaScript 压缩工具通常会删除无用空白和注释、缩短局部变量名，并在安全的前提下改写代码表达式，以减小发布文件的体积。它适用于网站生产构建、脚本分发和体积诊断，但并不能替代打包器、代码审查或安全保护。

实践中，压缩往往只是构建流程的一环：先由打包器处理模块与依赖，再按发布配置压缩，最后检查生成文件及其 gzip、Brotli 体积。本文用 Terser 和 esbuild 演示常见做法，并说明哪些代码不应盲目改写。

一、先分清“压缩”究竟指什么

日常所说的 JavaScript 压缩，可能指几种不同操作：

• 删除空白和注释：减少源码中不影响执行的字符。通常称为压缩或最小化（minification）。
• 缩短变量名：把可安全重命名的局部变量改成较短名称，例如将 customerList 改成 e。这常称为 mangling。
• 代码转换与优化：进行常量折叠、删除不可达代码等优化。具体规则取决于工具与配置。
• 传输压缩：服务器或 CDN 使用 gzip、Brotli 等算法压缩文件内容，在传输时减少字节数。这不是 JavaScript 语法转换。

两类压缩的结果不能混为一谈。minify 后的文件仍是可解析的 JavaScript；gzip 或 Brotli 结果则是压缩数据，需要客户端解压后才能执行。文件检查时，应同时看原始构建文件大小和传输压缩后的大小。

二、什么时候需要使用 JavaScript 压缩工具

• 生产环境发布：减少静态资源体积，配合服务器传输压缩降低下载量。
• 独立脚本分发：例如发布浏览器插件、嵌入式脚本或供其他项目引用的构建产物。
• 定位体积异常：比较压缩前后以及 gzip、Brotli 大小，判断变化来自源码、依赖还是构建配置。
• 构建流程标准化：将压缩设为可重复的生产步骤，而不是每次手动复制粘贴到在线工具。

如果项目使用 Vite、Webpack、Rollup 等构建工具，通常应在构建配置中处理压缩，而不是额外手动压缩构建后的文件。构建工具可能已经做了压缩；重复处理会增加维护成本，也可能影响注释、Source Map 或调试体验。是否默认压缩取决于工具和项目配置，应查看实际构建产物确认。

三、用 Terser 压缩单个 JavaScript 文件

Terser 是常用的 JavaScript 压缩工具，可通过命令行或 Node.js API 使用。下面以本地项目为例。先创建项目并安装 Terser：

mkdir js-minify-demo
cd js-minify-demo
npm init -y
npm install --save-dev terser

创建 src/app.js：

function calculateTotal(items) {
  const taxRate = 0.08;
  let total = 0;

  for (const item of items) {
    total += item.price * item.quantity;
  }

  return total * (1 + taxRate);
}

console.log(calculateTotal([
  { price: 10, quantity: 2 },
  { price: 5, quantity: 3 }
]));

运行命令行压缩：

npx terser src/app.js --compress --mangle --output dist/app.min.js

首次运行前需要创建输出目录，否则工具可能因为目录不存在而报错：

mkdir -p dist
npx terser src/app.js --compress --mangle --output dist/app.min.js

Windows 命令提示符不一定支持 mkdir -p；可先手动建立目录，或使用 Node.js 脚本创建。也可以在项目的 package.json 中添加脚本：

{
  "scripts": {
    "build:min": "terser src/app.js --compress --mangle --output dist/app.min.js"
  }
}

如果 dist 还不存在，需先创建它，或用构建脚本负责建目录。压缩后检查文件内容与运行结果，不要只看命令是否返回成功。

--compress 启用压缩优化，--mangle 启用变量名缩短。两者作用不同：只压缩、不改名可以省去 mangling；只改名也不等于完成全部压缩。压缩选项有默认行为，具体结果受工具版本、输入语法和配置影响，不应假定每个版本都会做完全相同的优化。

四、用 Terser API 控制配置和 Source Map

在自动化构建中，Node.js API 更适合根据环境控制参数。创建 build.mjs：

import { readFile, mkdir, writeFile } from "node:fs/promises";
import { minify } from "terser";

const input = await readFile("src/app.js", "utf8");

const result = await minify(input, {
  compress: true,
  mangle: true,
  format: {
    comments: /@license|@preserve|^!/
  },
  sourceMap: {
    filename: "app.min.js",
    url: "app.min.js.map"
  }
});

if (!result.code) {
  throw new Error("Terser 没有生成输出代码");
}

await mkdir("dist", { recursive: true });
await writeFile("dist/app.min.js", result.code);

if (result.map) {
  await writeFile("dist/app.min.js.map", result.map);
}

console.log("压缩完成");

此示例保留匹配规则所选中的注释，并生成 Source Map。正则匹配范围应按项目实际注释格式验证；不同构建工具对许可证注释也可能有专门配置。应确认发布文件中保留了项目要求的版权和许可证信息，不要因为追求极小体积而无意删除它们。

在 package.json 中设置模块类型，或将文件扩展名改为 .mjs，然后执行：

{
  "type": "module",
  "scripts": {
    "build:min": "node build.mjs"
  }
}

npm run build:min

Source Map 用于把压缩后代码的位置映射回原始源码，便于调试。它不是压缩代码的解密工具，也不自动保证安全。如果把 Map 文件公开部署，通常意味着浏览器用户或任何拿到文件的人可以查看映射到的源码内容；是否发布应按项目的调试、隐私和发布策略决定。

五、用 esbuild 快速压缩

如果项目已经使用 esbuild，或者只需要快速构建，命令行选项也很直接：

npm install --save-dev esbuild
npx esbuild src/app.js --minify --outfile=dist/app.min.js

--minify 会启用 esbuild 的压缩处理。若要分别控制空白、语法压缩和变量名缩短，可使用相应的独立选项；不过实际项目最好采用一套明确的构建配置，不要一边手动压缩、一边又让其他工具重复压缩。

esbuild 与 Terser 的压缩算法、配置项和输出细节并不完全相同。不能把一个工具的选项名直接套到另一个工具上，也不应期待两者输出字节数一致。选择时应关注项目所需的语法支持、Source Map、许可证注释处理、构建速度和现有工具链，而不是只比较一次压缩的大小。

六、准确检查文件体积

检查体积时至少要区分以下数值：

• 原始源码：开发时的文件大小，受格式和注释影响。
• 压缩产物：构建生成的 .min.js 等文件大小，通常是磁盘字节数。
• gzip 或 Brotli 大小：对产物再次做传输压缩后的字节数，取决于算法、质量设置和文件内容。
• 实际下载情况：还受服务器是否启用压缩、缓存、请求头、响应内容等因素影响，应以浏览器网络面板或服务器响应为准。

下面的 Node.js 脚本同时报告文件原始字节数、gzip 和 Brotli 结果。保存为 check-size.mjs：

import { readFile } from "node:fs/promises";
import { gzipSync, brotliCompressSync } from "node:zlib";

const file = process.argv[2];

if (!file) {
  console.error("用法：node check-size.mjs <文件路径>");
  process.exit(1);
}

try {
  const data = await readFile(file);
  const gzip = gzipSync(data);
  const brotli = brotliCompressSync(data);

  console.log(`文件：${file}`);
  console.log(`原始：${data.length} bytes`);
  console.log(`gzip：${gzip.length} bytes`);
  console.log(`Brotli：${brotli.length} bytes`);
} catch (error) {
  console.error(`读取或压缩失败：${error.message}`);
  process.exit(1);
}

运行方式：

node check-size.mjs dist/app.min.js

这里的 data.length 是字节数，不是字符数；中文、emoji 和其他多字节字符都会影响字节大小。脚本使用 Node.js 内置 zlib 模块，在本机对文件进行压缩，结果适合做一致条件下的比较，但不保证与线上服务器最终返回的字节数完全相同。服务器可能采用不同压缩级别、不同实现，或根本没有启用某种传输压缩。

比较两个版本时，确保输入文件、工具版本和压缩参数一致。只比较源文件大小，无法判断用户实际下载量；只比较 gzip 数值，也无法说明浏览器执行速度或页面性能一定改善。

七、参数边界：哪些代码不能随意改写

压缩器会基于语法和配置推断哪些改写是安全的，但无法自动知道所有运行时约定。以下情形尤其需要测试。

1. 通过名称访问变量或函数

局部变量重命名通常不会影响普通词法引用，但如果代码通过 eval、Function 构造器、字符串约定或外部框架按名称查找变量，改名可能破坏行为。对这类代码，优先改造实现方式；若无法改造，应依据工具文档限制相关压缩或 mangling，并添加覆盖测试。不要把整个项目的压缩都关闭作为第一反应。

2. 依赖函数或类的名称

某些框架、序列化逻辑或调试代码会读取函数、类的 name 属性。变量名缩短、转换或打包可能导致名称变化。Terser 提供与保留名称相关的配置，但保留名称会影响压缩效果，而且不等于解决所有基于名称的反射问题。应先确认运行时是否真的依赖该名称，再按需配置并验证。

3. 对象属性名与外部协议

普通属性名通常不会因局部变量 mangling 自动改变，但若启用了属性名压缩或第三方工具相关功能，JSON 字段、后端协议字段、HTML 属性、反射访问等都可能受影响。对于稳定的对外接口，应避免随意压缩属性名，或使用工具提供的保留名单，并对输入输出格式做测试。

4. 条件编译与环境变量

有些优化可以根据“某个全局变量恒为某值”的假设删除分支。假设不成立时，输出行为可能改变。例如开发和生产环境使用不同变量替换方式，必须确认变量是在构建时定义，还是仅在运行时存在。不要为了消除警告就随意把全局变量声明成常量。

5. 老旧运行环境

压缩不等于自动兼容旧浏览器。工具能否解析输入语法、是否转换语法、输出目标是哪种 JavaScript 版本，是不同问题。某些工具主要负责快速压缩或打包，不负责完整的语法降级；需要支持旧环境时，应在工具配置中明确 target，并按项目要求使用转译器和 polyfill。构建成功并不代表目标浏览器一定能执行。

八、在线压缩工具的用途与安全边界

在线工具适合快速验证一小段无敏感代码、比较压缩效果或临时排查问题。使用前要阅读网站关于代码处理、保存和上传的说明；代码一旦提交到第三方服务，就不能仅凭页面上写着“在线压缩”推断其不会留存或被访问。

不要把访问令牌、私钥、用户数据、未公开商业逻辑或含内部路径与配置的代码粘贴到来源不明的网站。更稳妥的做法是在本地项目中安装依赖并离线运行构建工具。即使工具在本地运行，也要从可信渠道安装依赖、锁定版本并审查更新，因为构建依赖本身同样属于软件供应链的一部分。

压缩也不是加密。压缩后的 JavaScript 仍然可以被下载、格式化和分析；变量改名、删除空白或代码混淆都不能可靠地隐藏密钥、阻止逆向，或保护放在客户端的秘密。任何需要保密的凭据都不应写进浏览器代码，应由受控的服务端完成相关操作。

九、常见错误与排查顺序

• 只压缩源码文件，却没有处理模块依赖：一个含 import 或 export 的文件不一定能直接作为传统脚本加载。是否需要打包，要看浏览器加载方式和目标环境。
• 重复压缩：确认构建产物是否已经经过压缩。重复执行通常不会带来明显收益，却可能让调试和问题定位更困难。
• 输出目录不存在：先创建目录，或让构建脚本自动建立目录；检查实际输出路径，不要误把旧文件当成新结果。
• 压缩后运行时报错：先保留未压缩产物和 Source Map，通过错误位置追踪原始代码；再检查名称反射、动态执行、属性名处理和环境变量假设。
• 文件变小但线上下载量没变：确认服务器实际返回的是新文件，检查缓存、CDN 和响应头中的 Content-Encoding，并在浏览器网络面板查看传输数据。
• 只看 gzip，忽略 Brotli 或反之：线上实际采用哪种编码取决于服务端协商；需要关注用户真正获得的响应，而不是本地脚本中最小的那个数字。
• 把代码混淆当作安全防线：压缩的目标是减小文件并优化输出，不应替代鉴权、服务端校验、秘密管理和安全测试。

十、推荐的落地流程

1. 明确发布目标：浏览器、Node.js、插件或库，以及需要支持的运行环境。
2. 先用项目现有打包工具生成生产产物，避免无意重复处理。
3. 选择与工具链匹配的压缩器，记录依赖版本和配置。
4. 按项目要求处理许可证注释与 Source Map，并决定是否公开映射文件。
5. 运行单元测试、构建测试和目标环境测试，重点覆盖动态执行、名称反射和外部数据字段。
6. 同时比较构建文件字节数与 gzip、Brotli 结果；上线后再以真实响应验证传输效果。

简单项目可以从 Terser 的命令行开始；已有 esbuild 或其他构建系统的项目，则优先沿用现有流程。关键不是追求某个工具输出的最小数字，而是让压缩可重复、输出能正确运行、体积统计口径清楚，并且许可证、调试和安全边界都经过确认。