必须用 Debug 配置启动调试，因其保留完整符号信息和未优化指令流，支持设断点、观察变量及准确步进；Release 配置因优化导致断点失效、变量不可见、逻辑跳转错乱。
直接在 Debug 配置下启动调试，是发现和修复 Bug 的唯一高效路径；Release 配置下无法设断点、看不到变量值、跳转逻辑被优化打乱——别指望它帮你定位问题。
为什么必须用 Debug 配置启动调试
Debug 配置保留完整的符号信息（.pdb 文件）和未优化的指令流，这是调试器能准确停在 Fibonacci 函数第 7 行、观察 n1 和 n2 值的前提。Release 配置会内联函数、删减临时变量、重排循环，导致断点失效或跳转到完全无关的代码行。
- VS 默认新建项目就是 Debug 配置，但务必检查顶部工具栏：确认显示的是
Debug而不是Release - 若误用 Release 启动，按
F5后断点变成空心圆，鼠标悬停提示 “当前上下文不可用” - 生成输出窗口中出现
Skipping generation of debug information就是危险信号
断点设置与分步执行的关键操作
对 Fibonacci 函数第一行设断点（F9），按 F5 启动后程序会在 Console.WriteLine("The output is: "); 暂停。此时不能只看返回值，要逐行验证中间状态：
Visual Studio Professional 18.8.1
下载
Visual Studio 18.8.1 官方固定版本安装引导程序，当前条目使用微软发布历史中的 Professional Web Installer，适合旧项目兼容、环境回退、复现特定构建链和排查版本差异等场景。
-
F10（逐过程）：跳过函数调用，适合跳过Console.WriteLine这类不影响逻辑的语句 -
F11（逐语句）：进入函数内部，比如想查n == 0 ? n1 : n2的判断依据时必须用它 - 当循环变量
i从 2 跑到 4 后，观察n2值是 3 而非预期的 5，立刻知道循环少跑了一次
变量观察与条件断点实战
原 Fibonacci 函数错误在于循环终止条件：i 导致 <code>n=5 时只执行 3 次循环（i=2,3,4），实际需要 4 次（i=2,3,4,5）。靠肉眼读代码极难发现，必须依赖运行时数据：
- 将鼠标悬停在
n2上，实时查看其每次迭代后的值；右键选择 “添加监视” 可固定观察 - 若只关心
n==5时的行为，在断点上右键 → “条件”，填入n == 5，避免其他输入干扰 - 修改循环条件为
i 后，必须重新按 <code>Ctrl+F5（不调试重启）或重建项目，否则旧二进制仍在内存中
异步/多线程场景下容易忽略的陷阱
如果 Bug 出现在 async 方法里，仅看 “调用堆栈” 窗口会漏掉关键线索——它只显示物理线程堆栈，而 await 之后的代码可能在另一个线程继续。这时必须打开 “并行堆栈” 窗口，切换到 “任务” 视图：
- 你会看到类似
HttpClient.GetStringAsync → await → ProcessResult的虚拟调用链，这才是真实逻辑流 - 若某任务状态是 “Scheduled” 但长期不变成 “Running”，大概率是
.Result或.Wait()在同步阻塞 - “任务” 视图里红色标记的异常，比输出窗口里的文字报错更早暴露问题源头
真正卡住人的从来不是语法错误，而是那些在 Debug 下行为正常、一换 Release 就出错的边界情况——它们往往藏在优化引发的内存重排、浮点精度截断或未初始化变量里。动手前先确认配置，动手时紧盯变量，动手后验证所有分支路径，比任何技巧都管用。
