Vite 生产环境优化：Terser 插件配置与实战技巧

1. 为什么需要 Terser 插件优化在 Vite 项目中生产环境的代码优化是一个绕不开的话题。你可能已经注意到开发环境的代码体积往往比生产环境大很多这是因为开发环境保留了完整的代码结构和注释方便调试。但到了生产环境这些冗余信息就会成为性能负担。我接手过一个电商项目未优化的 JS 文件达到了 3MB导致首屏加载时间超过 5 秒。经过 Terser 优化后体积直接缩减到 800KB效果立竿见影。这就是为什么我们需要在生产环境使用 Terser 这样的压缩工具减小文件体积通过删除空格、注释、未使用代码等方式提升执行效率缩短变量名、简化表达式等优化手段保护代码安全混淆处理让代码难以被直接阅读和复制2. Vite 不同版本的 Terser 配置差异2.1 Vite 2.x 的安装与配置在 Vite 2.x 时代Terser 是一个需要单独安装的插件。我记得第一次使用时还纳闷为什么压缩没生效后来才发现是忘记安装插件了。具体安装命令如下npm install vitejs/plugin-terser --save-dev # 或者 yarn add vitejs/plugin-terser -D配置方式也比较直接import { defineConfig } from vite import terser from vitejs/plugin-terser export default defineConfig({ plugins: [terser()] })2.2 Vite 3.0 的内置支持Vite 3.0 开始Terser 被内置到了核心构建流程中。这个改动让很多开发者感到困惑包括我自己。第一次升级到 Vite 3 时我还在找插件安装文档后来才发现已经不需要了。现在直接在vite.config.ts中配置即可export default defineConfig({ build: { minify: terser, terserOptions: { // 具体配置项 } } })3. Terser 核心配置详解3.1 压缩选项compresscompress选项控制着代码的压缩行为这里有几个我经常调整的参数compress: { drop_console: true, // 移除所有console语句 drop_debugger: true, // 移除debugger pure_funcs: [console.log], // 只移除console.log collapse_vars: true, // 合并变量声明 reduce_vars: true, // 提取重复使用的静态值 }有个实际案例项目中有个性能监控模块需要保留console.error但移除其他console。这时就不能用drop_console: true而是要用pure_funcs精确控制pure_funcs: [console.log, console.warn, console.info]3.2 混淆选项mangle混淆处理可以重命名变量和函数提高代码安全性mangle: { toplevel: true, // 混淆顶级作用域变量 keep_classnames: false, // 不保留类名 keep_fnames: false, // 不保留函数名 }但要注意如果你的代码依赖反射机制比如通过类名动态创建实例就需要设置keep_classnames: true。我曾经遇到过这个问题混淆后导致依赖注入系统失效排查了半天才发现是混淆惹的祸。3.3 输出选项output输出选项决定了最终生成的代码格式output: { comments: false, // 移除所有注释 beautify: false, // 不美化输出 ascii_only: true, // 只使用ASCII字符 }这里有个小技巧如果你需要保留版权声明等特定注释可以设置comments: /license|preserve/i使用正则表达式匹配需要保留的注释。4. 实战优化技巧与常见问题4.1 按需压缩策略不是所有代码都需要极致压缩。对于第三方库如果已经预压缩过可以跳过二次压缩build: { minify: terser, terserOptions: { // 排除特定文件 exclude: [/node_modules\/lodash/] } }4.2 Source Map 的权衡压缩后的代码很难调试这时候 source map 就很重要了。但生成 source map 会增加构建时间build: { sourcemap: process.env.NODE_ENV development }我建议在 CI/CD 流水线中只在测试环境生成 source map生产环境则关闭。4.3 性能与效果的平衡Terser 提供了很多优化选项但不是所有都值得开启。经过多次测试我发现这些配置性价比最高terserOptions: { compress: { drop_console: true, collapse_vars: true, reduce_vars: true }, mangle: { toplevel: true } }过度优化不仅收益递减还可能引入难以排查的问题。比如hoist_funs和hoist_vars选项虽然能进一步减小体积但有时会导致作用域问题。5. 进阶配置与自定义插件5.1 自定义压缩逻辑有时候默认配置不能满足需求比如需要保留特定格式的注释。这时可以自定义处理函数output: { comments: function(node, comment) { return /重要警告/.test(comment.value) } }5.2 与其他优化工具配合Terser 可以和其他优化工具链配合使用。比如先用 esbuild 做快速压缩再用 Terser 做深度优化build: { minify: process.env.NODE_ENV production ? terser : esbuild, terserOptions: { // 深度优化配置 } }5.3 监控优化效果为了量化优化效果我通常会记录构建前后的文件大小import fs from fs import { visualizer } from rollup-plugin-visualizer export default defineConfig({ plugins: [ visualizer() // 生成构建分析报告 ], build: { rollupOptions: { output: { manualChunks(id) { if (id.includes(node_modules)) { return vendor } } } } } })这个配置会生成一个可视化的依赖分析图帮助识别优化空间。