在项目开发过程中，console.log 是开发者的好帮手，帮助我们快速调试代码、查看变量值等。然而，当项目进入部署阶段，尤其是生产环境时，console.log 却可能成为 “隐形的坑”。
今天，我们就来聊聊在部署项目时为什么要去掉 console.log，以及如何高效地解决这一问题。
console.log 在生产环境的弊端
（一）性能损耗
尽管现代浏览器和运行环境已经对 console.log 进行了大量优化，但在一些高频触发的场景下（如循环、事件监听等），它仍会占用一定的内存和 CPU 资源。虽然这种损耗相对较小，但对于追求极致性能的项目来说，仍是一种不必要的浪费。例如，在一个高频的 mousemove 事件中，大量日志输出可能会导致页面轻微的卡顿，影响用户体验。
（二）安全隐患
在开发过程中，我们可能会在 console.log 中输出各种信息，包括一些敏感信息，如 API 接口地址、Token、用户数据等。如果不小心将含有这些敏感信息的日志遗漏在生产环境中，就有可能被恶意利用，给项目带来严重的安全风险。一个简单的 console.log(apiUrl) 可能在本地调试时毫无问题，但在生产环境中却可能成为攻击者的突破口。
（三）干扰调试
在生产环境下，过多的日志输出可能会掩盖真正的错误信息，干扰开发者的调试工作。当出现错误时，大量的 console.log 输出可能会淹没关键的错误信息，导致开发者难以快速定位问题。而且，开发者可能会误以为某些 console.log 是正常输出，从而忽视了潜在的 Bug，增加了调试的难度和时间成本。
（四）增加代码体积
虽然每个 console.log 本身可能很小，但大量的日志代码累积起来，会对打包后的文件体积产生一定影响。在项目部署时，较大的文件体积可能会导致首屏加载速度变慢，影响应用的性能和用户体验。尤其是在移动设备等网络环境不稳定的场景下，这种影响更加明显。
如何移除生产环境中的 console.log
（一）使用 Babel 插件
Babel 是一个广泛使用的 JavaScript 编译器，它可以将最新的 JavaScript 代码转换为向后兼容的版本。我们可以通过配置 Babel 插件来移除生产环境中的 console.log。
在项目的 babel.config.js 文件中添加如下配置：
module.exports = {
presets: [
'@vue/cli-plugin-babel/preset',
],
plugins: [
['@babel/plugin-proposal-optional-chaining'],
...process.env.NODE_ENV === 'production' ? [['transform-remove-console', { exclude: ['info', 'error', 'warn'] }]] : []
]
}
这种方式的优点是不影响源码，仅在生产环境生效，开发环境仍可以正常使用 console.log 进行调试。另外，配置相对简单直接，适合快速实现基本需求。不过，它依赖于 Babel 插件，如果项目中没有使用 Babel 或者 Babel 配置较为复杂，可能会遇到一些兼容性问题。
（二）使用 Terser 压缩移除
Terser 是一个广泛使用的 JavaScript 压缩工具，很多现代的打包工具（如 Webpack、Vite 等）都默认支持 Terser 压缩。我们可以通过配置 Terser 的选项来移除生产环境中的 console.log。
在 Webpack 的配置文件中添加如下代码：
module.exports = {
chainWebpack: (config) => {
config.optimization.minimizer("terser").tap((args) => {
args[0].terserOptions.compress = {
...args[0].terserOptions.compress,
drop_console: true, // 移除所有 console
pure_funcs: ["console.log"], // 只移除 console.log，保留其他
};
return args;
});
},
};
在 Vite 的配置文件中，也可以通过类似的配置实现：
import { defineConfig } from 'vite'
export default defineConfig({
build: {
terserOptions: {
compress: {
drop_console: true,
pure_funcs: ['console.log']
}
}
}
})
这种方式的优点同样是不影响源码，且仅在生产环境生效。它还可以避免 Babel 插件可能出现的兼容性问题。但是，这种方式需要根据所使用的打包工具进行额外的配置，对于一些不太熟悉打包工具配置的开发者来说，可能会有一定的学习成本。
（三）自定义 console 包装函数
如果我们想要更精细地控制日志输出，可以自定义一个 console 包装函数。通过这种方式，我们可以在不同环境下对日志输出进行灵活的控制。
创建一个 utils/logger.js 文件，内容如下：
const logger = {
log: (...args) => {
if (process.env.NODE_ENV !== "production") {
console.log("[LOG]", ...args);
}
},
warn: (...args) => {
console.warn("[WARN]", ...args);
},
error: (...args) => {
console.error("[ERROR]", ...args);
},
};
exportdefault logger;
然后在项目中使用这个自定义的 logger 替代原生的 console：
import logger from "./utils/logger";
logger.log("Debug info"); // 生产环境自动不打印
logger.error("Critical error"); // 始终打印
这种方式的优点是可以精细控制日志输出，根据项目的实际需求自定义日志级别。它不会影响 console.warn 和 console.error，避免了在生产环境中遗漏重要错误信息。不过，它需要手动替换项目中的 console.log，对于大型项目来说，可能会有一定的工作量。
总结
在部署项目时，去掉 console.log 是一个重要的优化步骤。它不仅可以避免性能损耗、安全隐患和干扰调试等问题，还可以减少代码体积，提升应用的性能和用户体验。根据项目的实际情况和开发习惯，我们可以选择使用 Babel 插件、Terser 压缩或自定义 console 包装函数等方式来移除生产环境中的 console.log。在实际开发中，建议在开发环境中充分调试和测试代码，确保在部署到生产环境时，代码已经足够稳定和安全，从而减少对 console.log 的依赖。
