编程调试技巧从入门到熟练

编程调试技巧从入门到熟练

刚学编程那会儿，我总在夜里对着报错发呆。屏幕上红色的几行字，像是故意跟我过不去。明明照着教程敲的代码，跑起来却像一匹脱缰的野马，不是这儿少个分号，就是那儿变量找不到。我一度以为，是自己脑子转得慢。后来才明白，编程调试不是天赋，而是一套可以练出来的本事。今天就把这些年踩过的坑、攒下的经验，摊开来讲一讲。

别急着改，先读懂报错。

新手最容易犯的错，是看到报错就慌，立刻删掉几行代码再试。可很多时候，问题根本不在你刚写的那一句，而在它前面的某一行。比如有一次写一个数据处理的脚本，报错说“undefined is not a function”，我盯着最后调用的那一行看了半小时，硬是没看出问题。后来把报错信息往上翻，才发现前面有一行忘记给数组赋值，返回了 undefined，后面的调用自然崩掉。报错其实是系统在给你递纸条，写着“从这里往回看”。学会把报错信息当线索，而不是噪音，是调试的第一步。

把大问题切成小块。

程序越写越长，出问题时就像在一团乱麻里找线头。这时候如果还抱着“跑一遍看看”的心态，往往会浪费大量时间。我后来学到一个笨办法：拆。想验证一个函数对不对，就单独写一段代码，只跑它；想确认数据传得对不对，就在关键位置把内容打出来看。有次做一个小工具，结果总是差几条数据。我没有反复刷新页面，而是在数据进来的时候、中间处理的时候、最后输出的时候，各留一个“检查站”。结果发现，中间那一步过滤条件写得太狠，把正常数据也拦下了。切得够细，问题就藏不住。

别信眼睛，要信证据。

写代码的人，最容易高估自己的记忆力。“我刚才明明赋值了啊”“这个变量不可能是空的”，这些话我对自己说过无数次。可程序不认记忆，只认状态。有一次做页面交互，按钮点下去没反应。我一口咬定是样式挡住了事件。试过调层级、改透明度，甚至怀疑浏览器兼容性。最后在控制台里加了两句打印，才发现点击事件根本没绑定上——昨晚重构的时候，手滑把行删了。从那以后，我逼自己养成习惯：先看事实，再下结论。多一个打印，少一场自我感动。

学会用工具，而不是只靠耐心。

调试不是硬扛。很多时候，环境本身就能告诉你很多事。浏览器开发者工具、IDE 的断点、日志等级设置，这些都不是摆设。有次排查一个偶发的网络请求失败，我在控制台打开网络面板，慢慢刷新，终于发现请求偶尔会带上错误的参数。又用断点把发送前的逻辑走了一遍，发现是异步回调里混进了旧数据。要是只靠肉眼读代码，可能到现在还在猜。工具不是作弊，而是把看不见的过程，拉到台面上来。

别怕回滚，也别怕留痕。

调试到一半改得面目全非，结果发现还不如原来的版本，这种事谁都经历过。我后来学乖了，改一点，跑一次，能跑过再往下改。真跑不过，就退回去。版本控制不只是为了团队协作，更是为了给自己留条退路。另外，调试的过程值得记录下来。同一个问题第二次出现时，往往比第一次解决得快，不是因为变聪明了，而是因为上次的笔记还在。

编程这条路，调试占了不小的一块。刚入门的时候，它像是一道道墙；熟练之后，它更像是一根根探针，帮你把程序里的模糊地带看清楚。错误不会消失，但你会越来越不怕它。调试不是为了证明谁对谁错，而是为了让程序更接近你心里的那个样子。写得越多，错得越多，反而越踏实。因为你知道，只要按步骤来，再乱的线头，也能理清楚。