codeblocks如何调试：找准断点配合监视窗口排查代码问题

大一刚学C语言那段时间，最头疼的就是代码编译成功却跑不出正确结果，翻遍全网都没讲明白codeblocks如何调试，只能靠肉眼逐行抠代码，浪费大把时间还总找不到问题根源。

报错弹窗只能排查语法错误，根本处理不了逻辑漏洞。

那段时间写循环累加的作业代码，全程零编译报错，运行出来的数值永远和标准答案对不上，反复删除重写代码、重启CodeBlocks软件、甚至重新新建项目文件，所有笨办法试了个遍，依旧找不到bug在哪。当时完全摸不清调试的逻辑，天真地觉得代码能编译通过就代表书写无误，从来不知道程序运行的变量变化、执行顺序都会出问题，几十行的代码硬生生排查了两三个小时，越查越烦躁，最后只能对着屏幕干瞪眼。

折腾好久才搞明白，调试的核心操作第一步就是打对断点，不是随便点击标记就行。

最开始踩过最蠢的坑，就是随便在空行、注释行或者单纯的变量定义行打点，标记出来的断点一直是灰色状态，调试完全没反应，一度以为是软件安装包有问题，反复卸载重装了两次，白白耗费一下午的功夫。后来才反应过来，CodeBlocks的断点只对可执行的有效代码行生效，灰色圆点是无效断点，只有亮红色的实心圆点，才是能触发调试暂停的有效标记。

有效断点，是红色实心圆点。

找准正确的代码行打好断点后，点击顶部的调试运行按钮，程序就会自动暂停在标记的位置，这时候调出软件侧边的监视窗口，手动输入需要监测的变量名称，就能实时看见每一次程序执行后变量的数值变化。当时就是靠这个方法，一眼发现累加代码的循环初始参数设置错误，这个细微的逻辑问题，是肉眼绝对很难快速发现的，配合单步执行功能，逐行跟进程序的运行步骤，所有隐藏的逻辑漏洞都会直接暴露出来，比盲目的排查高效太多。

还犯过一个没必要的错，就是贪图全面，一次性在代码里打十几个断点，导致程序调试时频繁暂停，运行节奏被彻底打乱，反而分不清到底哪一步出了问题。其实调试根本不需要这么多标记，每次只在疑似出错的代码模块打上一两个断点就足够，精准锁定范围，排查效率会翻倍。

那天修正完参数，完整跑通调试流程后，关掉了调试面板，鼠标随意悬停在修正后的代码行上，屏幕安静得没有一点弹窗提示。