Qt Creator调试快捷键全解析：断点、单步与变量监视的高效技巧

调试这件事，表面上拼的是对代码逻辑的理解，实际上拼的是手速和心流状态。我在Qt开发这条路上踩过不少坑，调试器里泡了大半天结果发现是变量名拼错的低级问题，也经历过F5按成F10导致跳过关键分支的尴尬。后来我把Qt Creator的调试快捷键系统梳理了一遍，才发现以前多少时间都浪费在鼠标点来点去上了。这篇文章就把我整理和实战验证过的Qt调试快捷键完整拆给你，从基础断点操作到数据查看、从单步跟踪到断点条件设置，再加上我自己踩过的坑和排查心得，照着练能帮你省下一大半的调试时间。

1. 为什么调试快捷键是Qt开发的“隐形效率杠杆”

很多刚入行或者习惯了Visual Studio风格快捷键的开发者，往往低估了Qt Creator调试快捷键的作用。我见过太多人调试时右手握鼠标，一下一下点那个“Continue”按钮，又或者为了看一个变量的值，在代码行上悬停半天等那个tooltip弹出来。这些动作单次看起来没什么，但放在一个需要反复循环“打断点—运行—检查—修代码—重跑”的调试节奏里，累积的时间损耗相当惊人。

1.1 调试场景中的“时间黑洞”到底在哪

调试过程中最常见的“时间黑洞”有四个。

第一个是切换工具：从键盘打代码切到鼠标点调试按钮，再从鼠标切回键盘修代码，每次切换要0.5到1秒的注意力恢复时间。连续调试一小时，这个切换动作至少重复几百次，相当于白白丢掉了5到10分钟。

第二个是无效等待：代码跑到了我们不想看的位置，只能用鼠标去点“Step Over”，结果点错成了“Step Into”，一头扎进库函数内部，又得想半天怎么退出来。

第三个是数据探查效率低：想同时看好几个关键变量的变化趋势，靠鼠标悬停根本不够，必须打开变量监视窗口，但又不知道怎么快速添加变量，只能在调试器窗口里一个字母一个字母地敲。

第四个是断点管理混乱：设了一堆断点之后分不清哪个是核心断点，哪个是临时断点。条件断点设置起来麻烦，调试思路经常被无效中断打乱。

这四个问题，本质上都是快捷键体系没建立起来导致的。我用一个比喻来说明：调试工具本身像一把好用的螺丝刀，快捷键体系则是你的肌肉记忆。遥控器上的按钮就算设计得再合理，你每次找按钮都要低头看，动作快不起来。只有把按钮位置变成肌肉记忆，你才能边盯着电视画面边精准切换频道。

1.2 快捷键背后对应的是“调试思维模式”

其实快捷键不仅仅是快慢的问题，更深一层是思维模式的问题。

Qt Creator的快捷键布局有它内在的逻辑。比如F10和F11这一对，一个“跳过”，一个“进入”，本质上是让你在“宏观追踪”和“微观观察”两种模式间切换。你用F10快速扫描代码主干，遇到可疑函数再用F11钻进去看细节——这对应的是调试的“先主干后分支”思维。

再比如F9设断点、Shift+F5停止调试，这种成体系的快捷键设计，目的就是让你思考不停顿，手指不停顿。我常说，调试时的每分钟都该花在“思考为什么”上，而不是花在“找按钮”上。快捷键用熟了，你的注意力、手部动作、屏幕焦点三者同步，调试效率自然会上一个台阶。

2. 核心调试快捷键的完整分类拆解

很多教程喜欢把Qt Creator的快捷键做成一个大表格，然后扔给你自己背。我不喜欢这种方式。太长太杂的清单，没有场景感，根本记不住。我习惯把调试快捷键按“调试流程中的角色”分类，一类一类地掌握，并且在真实调试场景里反复使用，才能真正形成肌肉记忆。

2.1 构建与运行类：调试前的“启动引擎”

在正式开始调一个bug之前，你得先把程序编译通过、运行起来。这个环节的快捷键和调试息息相关，效率影响同样很大。

我平时最常用的几个：

• Ctrl+B：构建当前项目。注意它是增量编译，只编译修改过的文件，所以速度通常很快。如果你只改了某个类的内部实现，不需要全量重新编译，直接Ctrl+B就够了。
• Ctrl+R：直接运行，不带调试器。适合程序能正常启动、不需要跟进崩溃点的情况。
• F5：开始调试。如果程序没构建，它会自动执行一次构建，然后带着调试器启动。
• Ctrl+Shift+R：全局运行某个可执行文件。用在你改了构建目录配置、想指定运行特定二进制的时候。
• Shift+F5：停止调试。程序被强制终止，调试会话结束。这个在调试卡死场景特别有用。

也许你会问，Ctrl+R和F5有什么区别？Ctrl+R是不带调试器跑，程序如果崩了只会看到崩溃对话框，不会停在你崩溃的那行代码。F5是带调试器跑，崩溃或者断点触发时会切入调试器，停在对应的代码行。日常快速验证逻辑、不想频繁打断点的时候，我用Ctrl+R；一旦要追踪问题，马上F5。

还有两个容易被忽略但很实用的：

• Ctrl+F10：运行到光标所在位置。它相当于临时设了一个隐藏断点，程序会一直执行到光标那一行才停下。这个快捷键的价值在于：你不想在循环里一次次单步踩过去，只想快速跳到某一段代码。我经常用它来跳过比较耗时的初始化过程，直接定位到怀疑的代码段。
• F20：实际上Qt Creator里常用于“运行到指定行”的还有自定义方式，但Ctrl+F10是默认值，这个是核心。

构建这个环节，我提醒一个小点：如果Ctrl+B报错了，不要急着F5。先看编译输出窗口的红色错误信息，双击错误行可以跳到对应代码。编译错误没清理干净就F5，Qt Creator会弹提示，调试会话根本起不来，反而浪费时间。

2.2 断点管理类：精准“设防”的关键

断点是调试的第一道防线。不会高效管理断点，其他都是空谈。

先看基础操作：

• F9：设置或取消断点。光标在哪个代码行，按下F9就在那行打个红点；再按一次取消。这个操作简单但频率极高，我一天能按上百次，所以这个键必须形成肌肉记忆。
• Ctrl+Shift+F9：删除所有断点。我建议谨慎使用，因为Qt Creator不会二次确认。我踩过一次坑：调试一个复杂的多线程问题，设了七八个断点层层排查，结果想取消其中一个时手滑按到这个组合键，一夜回到解放前，重新设断点花了好几分钟。后来我习惯在设断点前先想清楚“这一个断点是用来确认什么的”。
• Ctrl+F9：启用或禁用某个断点，注意和上一个的区别。这个快捷键特别适合“暂时不想触发，但保留断点位置”的场景。我想让某个断点暂时失效，但不想删掉重设，就按Ctrl+F9禁用它。断点图标会从实心红点变成空心红点，一眼就能分辨。

F9右键还能设置更高级的断点属性：

• 条件断点：右键断点红点，选择“Edit Breakpoint”（编辑断点），然后在Condition里写表达式。比如 for (int i=0; i<1000; i++) 这个循环，你想在i==500的时候停，条件就写 i==500。程序每次执行到这一行都会判断条件，满足才停下。
• 断点命中次数：在断点编辑器的Hit Count里设置，比如设成5，意味着这个断点要执行第五次才停。这在排查多次迭代中出现的偶发问题时极有用。
• 日志断点：不中断程序，只在输出窗格打印一条表达式结果。这个我调试那种“崩溃前想看看变量轨迹”的场景经常用，比在代码里临时写qDebug()然后删掉要干净得多。
• 改变断点值或错误条件：如果是变量值改变时中断，也可以配置“When”条件。这类高级断点用法，建议在基本键位练熟练之后再尝试。

我想特别强调一下右键设置断点的路径：Qt Creator里可以在断点红点处直接右键，也可以打开“Debug > Breakpoints”视图统一管理。设置好的所有断点都在这个视图里，可以统一勾选启用/禁用、删除、编辑条件。视图里还能拖拽断点顺序，在有多个断点时非常清爽。

2.3 单步调试类：控制代码执行的“油门和刹车”

单步执行是调试的核心操作。F5把程序启动起来之后，你就进入了“驾驶模式”。

最核心的四个键位：

• F10：单步跳过（Step Over）。执行当前行，如果当前行是函数调用，不会进入函数内部，而是整行执行完，跳到下一行。这是最常见的操作，适合你不关心被调函数内部细节、只关心当前函数流程的时候。
• F11：单步进入（Step Into）。执行当前行时，如果当前行是函数调用，会钻进那个函数内部，停在函数的第一行。这是排查问题根源的利器。
• Shift+F11：单步跳出（Step Out）。如果在某个函数里面用F11钻太深了，想直接返回到上一级调用处，按Shift+F11，程序会执行完当前函数并回到该函数被调用的那一行。
• Ctrl+Shift+F11：当焦点在汇编代码中时，用于反向调试或汇编级单步，这个进阶场景先不用纠结。

也用生活化类比来理解：F10是你的“巡航模式”，看到路边商店但是不想进去，直接开过去；F11是“进店模式”，想看清店里的细节就开进去看；Shift+F11是“掉头出来”，看完发现店里没你要的东西，一脚油门回到主路上继续开。

实操现场我举个常见的例子：你的程序在某个函数调用之后变量值不对了。你设了断点停在调用前那一行，按F10跳过这个函数调用，然后发现变量值已经错了。这时候你就知道问题藏在被调函数内部。接下来重新运行，按F11钻进那个函数内部，一步步看它内部哪里改动影响了变量。这种“先F10定位嫌疑函数，再F11进函数找根源”的组合策略，比乱按一气高效得多。

还有个细节：Qt Creator在单步调试时，如果你的代码经过优化（Release模式），跳行可能不精确。这是编译器优化导致的映射错位。所以我调试时坚持用Debug模式构建。Qt Creator的Debug和Release区别，本质上是编译参数不同：Debug模式关闭优化、携带调试符号，Release模式开启O2优化、没有完整调试符号。想让F10/F11按预期跳转，先确认左下角的构建配置是不是Debug。

2.4 查看与修改变量类：盯着数据才能定位问题

调试代码，说白了就是把“内存里的变化过程”看清楚。变量值的查看和修改，是直击问题本质的利器。

最直观的操作：

• 鼠标悬停：调试器暂停在某一行时，鼠标悬停在变量名上，会弹出当前值。这个方法非常快速，但不适合对多个变量同时对比追踪。
• Locals窗口：在Debug模式下，Qt Creator左侧面板的“Locals”标签页会自动列出当前函数栈上所有局部变量及其值。我调试时基本一直盯着这个窗口看。
• Watches（监视）窗口：你可以手动添加任意表达式到监视列表里。比如想看某个对象内部的成员变量、某个指针指向的值，或者更复杂的表达式，都可以在Watches窗口的表达式框里输入，按回车添加。
• 直接查看结构体：在Locals或Watches窗口里，复杂的结构体和类对象会以树状结构展开，逐层点开即可看到所有成员变量值。

快捷键相关的是F8和F7。F7用于重新开始调试（在某些版本中用于Debug/Restart的快捷键是Ctrl+Shift+F5，F7在不同配置下可能不同），但有一个键位很重要：在调试模式和各种视图窗口之间的切换。最常用的是Alt+数字键切换侧边栏视图：Alt+1开启/关闭编辑模式，Alt+2是调试模式视图，Alt+3是Help等。这个能让你在“看代码”和“看变量”两个状态里快速切换。我在调试时不希望用鼠标去点侧边栏图标，就用Alt+2快速调出调试模式，面板里同时看到Locals、Watches和调用栈。

对于变量值修改，Qt Creator支持在Locals或Watches窗口里直接双击变量值，输入新值回车。我遇到过一个场景：某个函数的局部变量算出来是负数导致后续逻辑异常，我直接在变量视图里把值改成正数再继续单步执行，用来验证“如果这个值是正常的，后面的逻辑是否恢复”。这种方法在排查逻辑分段的bug时非常高效，不用改代码重新编译一遍，省下大量时间。

记得一个小技巧：监视窗口里支持输入Qt特有的表达式，比如 QString 对象可以展开看到内部 utf16 数据；QList 可以展开看每个元素。可是想直接监视 firstName.toUpper() 这类带函数调用的表达式，监视窗口不一定支持（取决于调试器和Qt版本），要实际测一下才知道。保险做法是先在代码里临时加一个临时变量，把函数返回值存起来，再监视这个临时变量。

2.5 调试模式与窗口切换类：让工具面板服务于你的思路

调试不是一个单一动作，而是一连串动作的组合：设断点、跑起来、看变量、切代码、改代码、再跑起来。在这一串动作里，Qt Creator窗口面板的切换效率直接影响整个调试节奏。

讲一个我切身的体验：起初我不习惯Alt+2这个键，总觉得鼠标点图标更快。但你真在一个千行级别的大类里排查bug时，代码区、调用栈、变量面板三者焦点频繁切换，每一次鼠标移动都在打断心流。后来我强迫自己一周内所有面板切换都通过Alt键完成，一周之后手就稳了，再也不想摸鼠标。

Qt Creator中还有一个很有用的隐藏技巧：Ctrl+K（某些版本）是搜索定位。输入函数名或者类名可以直接跳转到对应位置。调试中如果你想快速跳到某个函数看看它的定义，在代码区按Ctrl+K，输名字，Enter，就到目标位置了。这个操作在整个调试流里面特别节省时间。

3. 调试快捷键的实战场景演练

前面讲了那么多按键和功能，如果不放在一个完整场景里串一遍，你很难真正理解它们之间的配合。我模拟一个非常典型的Qt程序调试场景，带你走一遍完整的“从崩溃到定位”的实战流程。这个场景我在真实开发中改写过很多次，流程相当具备普适性。

3.1 模拟场景：某个界面按钮点击后程序闪退

假设我们有一个Qt Widgets程序，界面上有一个按钮“加载数据”，点击后程序崩溃。程序启动时运行正常，只要点击那个按钮，就闪退。这种问题在初学者和中级开发者身上天天发生。

我的第一步操作是：Ctrl+R把程序正常跑起来，顺利复现崩溃。虽然崩了，但没停在代码行上，看不到崩溃位置。于是切换到F5的方式，让程序在调试器下运行。

因为崩溃发生在点击按钮之后，我不能让程序一启动就停在main()里，我得手动给按钮对应的槽函数设置断点。打开代码文件，找到按钮点击响应函数，比如叫 onLoadDataClicked()，把光标移到函数内第一行，按F9设一个断点。

然后F5启动调试。程序启动，界面显示出来。我点击那个按钮，程序并没有崩溃，而是停在断点处，编辑器左侧出现黄色箭头，当前暂停在这一行。整个过程此刻暂停了，我可以为所欲为地检查当前状态。

接下来按F10单步跳过函数里的每一行代码，同时在左侧的Locals窗口观察变量的变化，一行一行往下看。我注意到代码里有一行：

QList values = rawData.split(",");

而 rawData 是一个 QString。正常情况下 QString::split 返回的是一个 QList ，不会崩溃。但往下一行：

QString firstValue = values[0];

如果 rawData 是空字符串，split 返回的QList是空的，那 values[0] 会越界访问。在Qt容器里，越界访问不保证会给出友好报错，很多情况下会直接触发断言或崩溃。这就是闪退的根源。

3.2 用快捷键验证“嫌疑代码”的真实路径

这时候我可以按下鼠标在变量上悬停查看 rawData 的值，发现它确实是空字符串。调试器停在这一行时，我可以按F10继续跳到下一行，程序执行完 values[0] 这行后，如果Qt库的断言机制生效，调试器会停下来并弹出一个错误信息框；如果没有断言，程序可能直接崩在库函数内部。

我想继续确认，于是又启动一轮调试F5，这次我在 rawData = ... 赋值那行设断点，单独检查赋值来源，按F10和F11逐行确认。发现这个值是从某个网络请求结果里取的，而网络请求返回的是QVariant，直接toString()得到空串，没做空值校验。

修法也很简单：调用split之前先判断 rawData.isEmpty() ，为空给个默认值。或者用 values.value(0) 替代 values[0]（Qt容器有安全越界访问的value方法），返回默认构造值。

整个排查过程如果用鼠标一步步来，估计最快也得五分钟，还容易误操作。我上面的快捷键流大约一分半钟就能完成从发现到定位的完整一次调试。像这种问题定位，快捷键带来的效率提升是几十倍的。

3.3 在实战中锤炼“手感”：连招的重要性

上面这个场景，其实是用到了几个基础快捷键的“连招”：

F5启动调试 -> F9设断点 -> F10单步 -> 查看Locals -> Alt+2切调试面板 -> Shift+F5停止 -> 改代码 -> Ctrl+B编译 -> F5重新开始调试。

这一套连招是调试的最底层肌肉记忆，我建议每个Qt开发者每天都能在代码里跑一遍，跑熟为止。我见过很多开发者单个按键会按，但连招总断，按键间隙还要停下来想一想“现在该按哪个”，这个想的过程就是浪费。能形成流畅连招时，你的注意力才真正能集中在逻辑上。

还有一个容易忽略的细节：F5重新开始调试时，如果代码已经被修改且重新构建过，调试会话是直接重启的，它会自动加载新的二进制文件，不需要你先Shift+F5停止再F5启动。Qt Creator会弹一个提示问问是否重启，直接确认就行。这个操作比手动“停止-重新启动”快不少。

4. 常见调试快捷键问题与排查技巧实录

快捷键用多了，会碰到各种稀奇古怪的问题。有些问题看着像是Qt Creator的bug，其实只是配置或使用习惯导致的。我把这些年攒下的常见问题和排查方法整理成一张速查表，再补充几个独家的排查技巧。

4.1 快捷键失效或冲突的排查清单

我重点说两个最常见也最坑的问题。

第一个是“F5没反应”。出现这个情况时，先看当前光标焦点在哪里。如果你在代码区，F5绝对有效；如果你刚在Watches窗口输入了表达式，光标焦点还在那个小输入框里，F5就会被当作普通按键传给输入框，调试自然启动不了。解决方法：鼠标点一下编辑区空白处，俗称“把焦点还给代码”，再按F5。这个坑我踩过无数次，记牢了能省很多无用功。

第二个是“Release模式下断点位置错乱”。Qt的Release模式默认开启O2优化，编译器会把代码重排、内联，甚至把局部变量优化掉。你在某行设了断点，程序可能根本不会精确停在那行，F10跳行的行为也会变得诡异。遇到这种情况，我只做一件事：切回Debug模式重新构建。排查阶段不要用Release，等程序稳定了再切Release做最终验证。

4.2 调试器异常与断点不命中的经验

断点不命中有几种场景，我逐一分析过：

场景一：断点设在头文件里，而这个头文件被多个源文件包含。Qt Creator有时候会把同一行代码当成多个.cpp实例里的不同断点，表现出来就是断点总在源文件a.cpp里命中了，可你想看的是源文件b.cpp里的那一行。解决办法是在断点窗口里把当前断点的“File”属性精确改成你要跟踪的源文件。

场景二：断点设在lambda表达式或槽函数内部。lambda在编译后对应到一个匿名函数，代码行映射有时候不准确。我建议不要在lambda第一行设断点，改在lambda调用处设断点，按F11进入lambda内部，这样反而更稳定。

场景三：多线程程序里，断点停住的是某个工作线程，而不是我们关心的界面线程。这时执行视图会切换到那个线程的调用栈，看起来像“代码乱跳”。解决办法是在断点上右键设置“线程过滤”，只在该线程命中时停下。如果你用的Qt版本比较老，没有线程过滤功能，可以在条件表达式中加上线程ID判断，但这种方式不够优雅，我更倾向于排除而不是硬设条件。

场景四：调试QML与C++混合的程序时，只在C++里设断点，QML里的代码停不住。Qt的QML调试需要额外的调试端口和QML调试模式，必须用Qt Creator的“QML调试”方式启动（具体联系到Ctrl+Shift+F5会重新启动时弹出的选项里选QML调试）。我记得QML断点经常被反馈为灰色，就是因为调试引擎没有真正通过QML调试协议连接上。

4.3 快捷键冲突与其他工具的叠加

最后说一个经常被忽略的问题：快捷键冲突。

我在某次开发中发现F10和F11莫名其妙失效了，怎么按都是“滴滴”声。排查了一圈，发现是输入法的中英文切换快捷键和QT的F10冲突了。中文输入法在切换模式时把F10拦截了。解决办法是改输入法的全局快捷键设置，或者干脆把输入法切换键换成Ctrl+Space等不常用的键。

另外，如果你的系统是Windows，并且在用某些截图软件、窗口管理工具，它们默认会把F9、F11、Ctrl+F5之类截胡。建议排查的第一步：看看这些软件的全局热键设置。第二步：把Qt Creator的快捷键配置导出备份，免得重装后丢失。

Qt Creator本身也支持自定义快捷键配置。在“Tools > Options > Environment > Keyboard”里，你可以搜索“Debug”相关的所有操作，自己修改快捷键映射，甚至可以导入导出配置。我很建议用这个功能把自己常用的一套快捷键固定下来，而不是用别人的“理想配置”。工具服务于习惯，习惯服务于思维，这才是快捷键体系的最高效使用方式。

5. 从快捷键到调试效率提升的综合建议

快捷键本身并不会让你“更懂代码”，但它能把你的调试动作压缩到最短，从而把更多脑力留给分析问题本身。我见过的优秀Qt开发者，几乎人人都有自己的一套快捷键操作流，且各不相同——有人喜欢用F8（如果设置成Step Over则不同），有人喜欢自定义。这说明什么？适合自己的才是最好的。

5.1 用“快捷键心法”驱动调试节奏

我总结了两个心法。

第一个叫“断点设好再看变量”。很多人习惯设一个断点就F5开始跑，跑完发现变量不对，才想起来“哦，忘了看某个变量”。正确做法是设好断点后，先在脑子里预演一遍“程序停在这里时，我希望看到哪些变量”，然后提前把这些变量加到Watches窗口。这样程序一停下，变量信息就是现成的，不用临时手忙脚乱。

第二个叫“单步一次只做一件事”。不少调试新手按F10时，脑子里想的其实是“走走看”，走到哪算哪。这种随机游走式的调试，效率极低。我建议每次按F10之前先明确一个问题：“我想确认的是这一行执行后a的值是不是预期的？”带着明确问题单步，每次按键都有产出，调试思路也会变得清晰。

5.2 构建“个人调试工具箱”的实践经验

除了Qt Creator内建的快捷键，我还会结合外部命令和工具，做一套组合拳。

比如我经常配合系统级快捷键打开任务管理器（Windows是Ctrl+Shift+Esc）查看进程状态，或者用系统日志查看器跟踪输出。Qt的qDebug()输出在“Application Output”窗格里的查看快捷键是Alt+5（某些版本），也可以自定义。我建议把qDebug输出窗格快捷键固定下来，因为很多崩溃问题可以通过最后一条日志定位现场。

再比如调试网络相关问题时，我会提前把抓包工具的启动快捷键设成全局热键。程序跑起来的同时，按下抓包工具热键，同步捕获网络包。这种方式结合Qt的调试器可以把问题从网络层到业务层一起分析。

还有个进阶玩法：合理利用Qt Creator的“Load GDB Debugger”脚本（在Debug视图右键可以加载GDB脚本），把一些自定义的调试命令通过别名映射成快捷键。这个玩法适合对GDB有一定了解的开发者，能实现一些特别复杂的自动化调试流程。不过这个入门门槛较高，新手可以先跳过。

5.3 建立快捷键使用习惯的周期建议

如果觉得一次性记这么多快捷键有压力，我建议按照下面这个节奏来养成习惯：

第一周：只练最基础的F9设断点、F5启动、F10单步、Shift+F5停止。这四个键构成一个最小的调试闭环。只要这四键形成肌肉记忆，调试效率已经比鼠标流高一截。

第二周：加入F11和Shift+F11，尝试在函数进出之间切换。同时把Ctrl+F10用起来，练习“直接运行到光标处”。

第三周：加入Alt+1和Alt+2的面板切换，以及Watches窗口的变量添加操作，把变量查看这块的效率提上来。

第四周：开始接触条件断点、日志断点，以及Ctrl+Shift+F5的重启调试。到了这个阶段，你已经完全脱离鼠标流了。

很多开发者问我要不要记全部快捷键，我的回答一直是：不用，你只需要把每天用到的20%的快捷键形成肌肉记忆，就足以覆盖80%的调试场景。剩下的那些边角快捷键，用到的时候再查配置表就行。

我个人在实际操作中的体会是：把调试快捷键练成肌肉记忆之后，最大的改变不是“点按钮变快了”，而是“思路不再断了”。调试是一个极度依赖短期记忆和逻辑链的过程，每打断一次焦点切换，你脑子里正在构建的问题模型就会被削弱一点。快捷键解决的是“最小打断”，把工具操作的认知负担降到最低，让全部脑力集中在“为什么这里会崩”这件事上。我自己就是从一周痛苦适应之后，彻底告别了鼠标点调试按钮的习惯。也建议你拿到这篇文章之后别急着背完所有按键，打开你的Qt项目，挑一个真实的小bug，用F9、F5、F10、F11这四个键走一遍完整的调试流程——你会发现，调试这件本来让人头秃的事，变得有点顺手了。