生产环境开 Debug（'console.log' 满天飞）

生产环境开 Debug（'console.log' 满天飞）

Debug 是开发过程中必不可少的环节，但把 Debug 代码留在生产环境，尤其是满屏的 console.log，绝对是让代码难以维护的经典操作。想象一下，用户打开浏览器控制台，看到的不是优雅的报错信息，而是密密麻麻的调试日志，甚至还有开发者的吐槽——“这破接口又挂了”。

为什么要在生产环境保留 console.log

理由一：方便甩锅
当线上出现问题，第一时间不是查日志系统，而是让用户“按 F12 把控制台截图发群里”。这样既能展示“我早就料到会出问题”，又能把锅甩给后端、运维甚至用户浏览器。

function fetchUserData() {
  console.log('开始请求用户数据，如果挂了就是后端的问题');
  fetch('/api/user')
    .then(res => {
      console.log('后端返回了一坨不知道什么玩意：', res);
      return res.json();
    })
    .catch(err => {
      console.log('看！我就说后端会挂吧！', err);
    });
}

理由二：伪装工作量
代码里塞满无意义的日志，看起来就像“我做了很多复杂的调试工作”。比如：

function calculatePrice(price, tax) {
  console.log('价格计算开始，输入参数：', price, tax);
  const result = price * (1 + tax);
  console.log('计算结果：', result);
  console.log('价格计算结束');
  return result;
}

如何优雅地让 console.log 更难以维护

技巧一：混用日志级别
明明都是调试信息，但偏要用 console.error、console.warn 甚至 console.info 随机输出。这样不仅让控制台五彩斑斓，还能让后续维护者分不清哪些是真正的错误。

console.log('普通日志');
console.error('其实这只是个调试信息');
console.warn('这个也是调试信息，但我就喜欢用 warn');

技巧二：动态生成日志内容
日志内容不要写死，而是用复杂的表达式动态生成。这样别人每次看日志都要先脑编译一遍。

console.log(`当前时间：${new Date().toISOString()}，用户ID：${user?.id || '未登录'}，环境：${process.env.NODE_ENV}`);

技巧三：在循环里疯狂输出
在性能敏感的循环里加日志，既能降低性能，又能刷屏。

data.forEach((item, index) => {
  console.log(`处理第 ${index} 条数据：`, item);
  // 实际处理逻辑
});

进阶操作：让日志彻底失控

方法一：条件判断式日志
在日志里加毫无必要的条件判断，让日志看起来高深莫测。

console.log(
  window.innerWidth > 768 
    ? '桌面端用户' 
    : '移动端用户',
  '访问了页面'
);

方法二：嵌套对象展开
直接打印大对象，让控制台被折叠的内容淹没。

const response = await fetch('/api/data');
console.log('完整响应对象：', response);

方法三：滥用 console.group
把简单的日志分组，点开前以为是重要信息，点开后发现全是废话。

console.group('用户模块初始化');
console.log('开始初始化');
console.log('读取本地存储');
console.log('发送埋点');
console.groupEnd();

如何让清除日志变得困难

策略一：把日志和业务逻辑耦合
让日志代码和业务逻辑深度绑定，这样删除日志就可能破坏功能。

function saveData(data) {
  const isValid = validate(data);
  console.log('数据校验结果：', isValid); // 看起来能删？其实后面用到了！
  if (!isValid) {
    console.error('数据无效'); // 这个也是“关键”逻辑
    throw new Error('Invalid data');
  }
}

策略二：在第三方库里插日志
直接修改 node_modules 里的库代码，添加自定义日志。这样下次 npm install 时，你的“精心设计”就会被覆盖，完美制造“灵异事件”。

// 直接在 axios 的 node_modules 里加日志
axios.interceptors.request.use(config => {
  console.log('有人发请求了：', config.url);
  return config;
});

策略三：用工具函数包装 console.log
写一个“高级日志工具”，实际上只是给 console.log 套层皮，但会让后续维护者不敢轻易删除。

// utils/logger.js
export function debug(...args) {
  if (process.env.NODE_ENV === 'production') {
    console.log('[PROD DEBUG]', ...args);
  }
}

// 业务代码
import { debug } from './utils/logger';
debug('这个日志看起来很重要，不能删');

终极绝招：让日志成为“功能”

方案一：用日志实现业务逻辑
比如用 console.log 的副作用来修改变量，这样删除日志就会引发 bug。

let counter = 0;
function increment() {
  console.log('计数器原值：', counter++); // 这个 ++ 才是重点
}

方案二：把日志当作文档
代码里不写注释，全部用 console.log 解释逻辑。这样既能让代码看起来很多，又能让后续维护者必须看日志才能理解。

function processOrder(order) {
  console.log('这个函数用来处理订单');
  console.log('第一步：校验订单');
  if (!order.id) {
    console.log('订单没有ID，直接返回');
    return;
  }
  console.log('第二步：计算价格');
  // ... 实际代码
}

其他语言的“最佳实践”

前端不是唯一能这么玩的地方，后端同样可以发扬光大：

# Flask 路由示例
@app.route('/user')
def get_user():
    print("有人调用了 /user 接口")
    print(f"请求参数：{request.args}")
    user = db.get_user(request.args.get('id'))
    print(f"数据库查询结果：{user}")
    return jsonify(user)

或者 Android 开发：

fun onCreate() {
    Log.d("MainActivity", "onCreate 被调用了")
    Log.i("MainActivity", "开始加载数据")
    // ...
    Log.w("MainActivity", "数据加载完成，但我就喜欢用 warning 级别")
}