我用GLM调试代码快了三倍

那个让人崩溃的早上

周一早上刚到工位，组长就甩来一个bug：Node.js后端接口在生产环境偶发性超时，日志只有“Error: socket hang up”。我是前端转全栈，对这种底层网络问题心里没底。

这个数据中台项目用Vue3、Node+Express和PostgreSQL。接口功能很简单，就是从数据库查用户行为数据聚合返回。但问题在于测试环境正常，生产环境每10次请求就有2-3次超时，偶发问题极难复现。

我先加try-catch、日志和耗时统计，折腾一个多小时，除了“socket hang up”毫无头绪。数据库查询用了连接池，按理说不该出问题。又怀疑网络抖动，运维看服务器监控也一切正常。当时真想砸键盘，对Node底层机制理解不够，遇到实际问题就抓瞎。

传统调试方式的局限

以前前端调试用Chrome DevTools基本能覆盖90%场景。到Node后端，常用就这几招：console.log大法、node --inspect远程调试、看错误堆栈。但这次日志信息不够细，生产环境没法远程调试，堆栈只告诉我是http请求挂了，不知道根因。

旁边的老哥建议用GLM试试，说它擅长底层问题。我之前对AI写代码半信半疑，但死马当活马医，把代码片段、错误日志和连接池配置全丢给了GLM。

GLM上场，思路瞬间打开

GLM没有直接给方案，而是列了几个可能原因让我排查：连接池耗尽导致等待超时、TCP空闲连接被中间网络设备断开、数据库端主动关闭空闲连接。

看到第二条我立刻想到，生产环境前面有阿里云SLB负载均衡，它默认对空闲TCP连接有超时时间。如果连接池里的连接长时间没用，SLB先断开，Node却还以为连接有效，拿来用时就挂了。顺着这个思路查，果然是PostgreSQL连接池默认没开启keepalive，而SLB空闲超时设置为60秒，连接一超时就被切断。

从定位到修复，效率翻倍

根因找到后修复很简单，在数据库连接配置加上keepalive：

const pool = new Pool({
  host: 'xxx',
  database: 'xxx',
  user: 'xxx',
  password: 'xxx',
  max: 20,
  idleTimeoutMillis: 30000,
  keepAlive: true,
  keepAliveInitialDelayMillis: 10000
})

改完上线观察两天，错误再没出现。从接bug到修复不到两小时，以前估计得折腾一整天。AI辅助调试的价值在于“根据现象推断原因”，能从海量数据中找到模式，给出意想不到的排查方向。

关于调试的几个心得

别死磕，善用工具。 很多人闷头硬查，其实别人三秒能看出的问题自己要查三小时。AI就像身边坐了个经验丰富的老司机。

描述问题比解决问题更重要。 用AI辅助调试时，描述质量决定答案质量。要说清环境、频率、错误信息和最近改动，越具体越好。

AI给的是方向，不是答案。 GLM引导我思考连接池和网络层面，验证靠自己。这个思考过程本身就很值。后来面试Node.js候选人，我就问“socket hang up可能是什么原因”，能说出TCP连接池和keepalive的水平都不错。踩过的坑变成筛选标准，这波不亏。

调试是经验活，没踩过的坑永远不知道。但AI让你站在别人经验上，不用自己真掉进去。这才是AI提效的本质——不是替代写代码，而是让你少走弯路。