JS 调试技巧

写 JS 调试的时候，大多数人还停留在 console.log 阶段，但面对异步流或者深层嵌套对象，这种方法效率低得惊人。最近在对比 GPT-4o 和 Claude 3.5 Sonnet 处理复杂 Bug 修复的能力，发现两者的调试逻辑有明显差异。

我扔给它们一段带内存泄漏风险的闭包代码，要求分析问题并给出调试方案。

GPT-4o 的倾向是“方案型”，它会直接告诉你怎么改，并建议你用 Chrome DevTools 的 Memory 面板快照对比。它的强项在于对工具链的熟悉程度，能快速定位到具体的 API，但给出的代码补丁有时过于冗余。

Claude 3.5 Sonnet 则更像个“分析师”，它会先推演代码执行路径，指出哪个变量在哪个时间点失效了。最让我惊喜的是它对 debugger 断点位置的建议极其精准，它会告诉我：在这里打断点，观察作用域链中的闭包引用。

在实际实测中，如果你需要一个能帮你快速定位 Bug 的“眼睛”，Claude 3.5 的逻辑推演能力目前领先；如果你需要快速知道怎么用工具解决问题，GPT-4o 更实用。

分享一个我最近高频使用的调试技巧，当你面对一个巨大的 JSON 对象不知道哪个字段出了问题时，别用 console.log，试着这样写：

// 快速筛选对象中值为 undefined 或 null 的键值对
const checkEmpty = (obj) => {
  return Object.entries(obj).filter(([_, v]) => v == null);
};
console.table(checkEmpty(bigData));

另外，处理异步函数死循环时，建议直接在代码里插入：

debugger;

配合 Chrome 的 Call Stack 堆栈分析，比在控制台打印一百次 step 1, step 2 要高效得多。

对比总结：
Claude 3.5 Sonnet：逻辑推演极强，适合分析深层 Bug 原因，给出的调试路径清晰，代码精简。
GPT-4o：知识面广，擅长推荐调试工具和 API，但有时会跳过分析直接给结果，缺乏推演过程。
DeepSeek：在处理基础语法 Bug 时速度极快，但在处理复杂异步时序问题上，偶尔会出现幻觉，不如前两者稳健。