直接全局搜索console会漏掉真实调用，因其可能被别名、解构、动态访问或包裹函数隐藏；ESLint基于AST静态检测最可靠，Babel插件可在编译期安全剥离，正则仅作高风险补救。
为什么直接全局搜索 console 会漏掉真实调用？
因为 console 可能被别名、解构、动态访问或包裹函数隐藏。比如：const { log } = console;、const c = console; c.error(...)、eval('console.warn()')，甚至 globalThis['console']?.info()。单纯 grep console. 或正则替换会漏掉这些变体，尤其在 Webpack/Babel 处理后的代码里更难靠字符串匹配覆盖。
用 ESLint 在构建前静态拦截最可靠
ESLint 能识别语法树中的实际调用，不依赖字符串模式，且可集成进 CI 流程。关键不是禁用所有 console，而是只禁用生产环境不该出现的调用。
- 安装插件：
npm install eslint-plugin-no-console --save-dev - 在
.eslintrc.js中配置规则（注意启用allow白名单仅限调试必需项）：module.exports = { plugins: ['no-console'], rules: { 'no-console': ['error', { allow: ['warn', 'error'] }] } }; - 运行检查：
npx eslint src/ --env browser,node。它会报出所有未被allow的console.log、console.debug等调用位置 - ⚠️ 注意：若项目用了自定义 logger 包裹
console（如logger.info()），ESLint 默认不会追踪到内部，需额外配置no-restricted-syntax规则或自定义规则
用 Babel 插件在编译期彻底剥离
ESLint 只报错不删码；真正“移除”得靠编译时处理。Babel 插件比正则替换安全，能精准删除 AST 节点，避免误删字符串或注释里的 console 字样。
- 推荐插件：
@babel/plugin-transform-console（官方维护，支持按环境启用） - 在
babel.config.js中配置：module.exports = { env: { production: { plugins: ['@babel/plugin-transform-console'] } } }; - 它默认只移除
console.log、console.debug、console.info，保留warn和error—— 这符合生产监控需求 - ⚠️ 风险点：若代码里有
console的属性访问但非调用（如typeof console），该插件不会动；但若用了console.table或第三方扩展方法，需手动加exclude配置，否则可能报console.table is not a function
上线前用正则做最后一道防御（谨慎使用）
当无法控制构建流程（比如接手遗留项目、纯 HTML + JS 静态站），才考虑 post-build 正则清理。必须限定作用域，否则极易破坏代码。
- 只处理 JS 文件，跳过
.map、.html、.css - 用 Node 脚本执行（避免 shell 工具跨平台差异）：
const fs = require('fs'); const code = fs.readFileSync('dist/app.js', 'utf8'); // 匹配 console.xxx(...) 形式，排除 // 注释和字符串内 const cleaned = code.replace(/(?<!//[^\n]*|'[^']*|"[^"]*)console.(log|debug|info|table)s*([^)]*)/g, ''); fs.writeFileSync('dist/app.js', cleaned); - ⚠️ 极易踩坑：正则无法处理换行参数、模板字符串、嵌套括号（如
console.log(a(), b(c()))）。一旦匹配失败，可能删半截语句导致语法错误。只建议用于简单脚本，且必须加try/catch + 语法验证
真正健壮的做法是把检测和移除拆成两步：ESLint 报警 + Babel 剥离。正则只是补救手段，而且补救本身就有风险——越想“全自动”，越容易在某个角落留下一个没被识别的 console.dir 调用。
